设计一个分布式ID

为了保证全局唯一性可以用时间作为区分点一部分，时间尽可能细化，可以精确到毫秒，甚至是微秒和纳秒。如果是分布式系统有多态机器，可以根据机器ID再进行以下区分。如哦机器运行的特别快，1毫秒有大量ID生成，可以结合实际限制下实际生成的ID数目。
如果N台机器去ID生成服务器的服务端得到全局ID，很容易保证全局唯一切自增的，但是存在单点失效的问题，不满足高可用。

雪花算法

生成的结果是一个int64的数据。核心思想是：使用41bit作为毫秒数，10bit作为机器的ID(5个bit是数据中心，5个bit的机器ID),12bit作为毫秒内的流水号，意味着每个节点再每毫秒可以产生 4096 个 ID, 最后还有一个符号位，永远是0.

优点： 优点是毫秒书在高位，自增序列在低位，整个ID是趋势递增的。不依赖数据库等第三方系统，一服务的方式部署，稳定性更高，生成ID的性能也是非常高的。可以根据自身业务特性分配bit位，非常灵活。

缺点： 强依赖机器时钟，如果机器上时钟回拨，会导致号重复或者服务会处于不可用状态。

Redis生成ID

因为 Redis 是单线程的，也可以用来生成全局唯一ID。可以用Redis的原子操作INCR和INCRBY来实现。使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis，可以初始化每台Redis的值分别是1，2，3，4，5，步长都是5，各Redis生成的ID如下：A: 1,6,11,16; B: 2,7,12,17; C: 3,8,13,18; D: 4,9,14,19; E: 5,10,15,29。负载到哪台机器提前定好，未来很难做修改。3-5台服务器基本能安祖需求，但步长和初始值一定需要事先确定，使用Redis集群也可以解决单点故障问题。

**优点：**不依赖数据库，灵活方便，且性能优于数据库，数字ID天然排序，对分页或需要排序的结果很有帮助。

**缺点：**如果系统中没有Redis，需要引入新的组件，增加系统复杂度；需要编码和配置的工作量比较大。

UUID

可以利用数据库也可以利用程序生成，一般全球唯一。UUID是由32个16进制数字组成，所以每个UUID的长度是128位（16^32 = 2 ^128)。UUID有多个实现版本，影响它的因素包括时间，网卡MAC地址，自定义Namespace等等。

优点：简单，代码方便；生成ID性能非常好，基本不会有性能问题；全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更情况下，可以从容应对。

缺点：没有排序，无法保证确实递增；UUID往往是使用字符串存储，查询的效率比较低；存储空间比较大，如果是海量数据库，就需要哦考虑存储量的问题；传输数据量大；不可读。

美团Leaf

Leaf-segment

直接用数据库自增ID充当分布式ID，减少对数据库的频繁操作。过程是从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如(1,10000]代表10000个ID，业务服务将号段生成1~10000的自增ID并加载在内存，在当前号段消费到某个点时，就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做很大程度上的降低了系统的风险。Leaf-segment采用双buffer的发过誓，他的服务内部有两个号段缓存qusegment.当前号段已消耗10%时，还没能拿到下一个号段，则会另启一个更新线程去更新下一个号段。Leaf保证了总是会多缓存两个号段，即便那一时刻数据库挂了，也会保证发号服务可以正常工作一段时间。通常推荐号段(segment)长度设置为服务高峰期发号QPS的600倍(10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。

tip biz_tag

针对不同业务需求，用biz_tag字段来隔离，如果以后需要扩容时，只需要对biz_tag分库分表即可

优点： Leaf服务可以很方便的线性扩展，性能完全能够支持大多数业务场景；容灾行=性高；Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。

缺点： ID号码不够随机，能够泄漏发号数量的信息，不太安全；DB宕机会造成整个系统不可用（用到数据库的都有可能）

Leaf-snowflake

Leaf-snowflake基本上就是沿用了snowflake的设计，ID组成结构：正数位（占1比特）+时间戳（占41比特）+机器ID(占5bit)+机房ID(占5 bit) + 自增值（占12bit)， 总共54比特组成的一个int64类型。不同点主要是在workId的生成上，Leaf-snowflake依靠Zookeerper生成workId。Leaf中workId时基于Zookeeper中生成一个顺序Id,相当于一台机器对应一个顺序节点。

启动服务的过程大致如下：启动Leaf-snowflake服务，连接Zookeeper, 在leaf_foever父节点下检查自己是否已经注册过；如果有注册过直接取回自己的workerId(zk顺序节点生成的int类型ID号）。启动服务；如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当作自己的workerID号，启动服务。Leaf-snowflake对Zookeeper是一种弱依赖关系，除了每次会去ZK拿数据以外，也会在本机文件系统上缓存一个workerID文件。一旦Zookeeper出现问题，敲好机器出现故障需重启时，依然能够保证服务正常启动。

优点： ID号码是趋势递增的8 byte的64位数据，满足上述数据库存储的主键要求。

缺点： 依赖Zookeeper, 存在服务不可用风险