- 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
- 趋势递增、单调递增：保证下一个ID一定大于上一个ID。
- 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL 即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID 无规则、不规则。
常见方法
UUID
UUID(Universally Unique Identifier)的标准型式包含 32 个 16 进制数字，以连字号分为五段，形式为 8-4-4-4-12 的 32 个字符，示例：
550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF 发布的UUID 规范 A Universally Unique IDentifier (UUID) URN Namespace。
- 优点：性能非常高，本地生成，没有网络消耗。
- 缺点：
- 不易于存储：UUID 太长，16 字节128 位，通常以36 长度的字符串表示，很多场景不适用。
- 信息不安全：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
- ID 作为主键时在特定的环境会存在一些问题，比如做 DB 主键的场景下，UUID 就非常不适用
- MySQL 官方有明确的建议主键要尽量越短越好，36 个字符长度的 UUID 不符合要求。
- 对 MySQL 索引不利：如果作为数据库主键，在InnoDB 引擎下，UUID 的无序性可能会引起数据位置频繁变动，严重影响性能。在MySQL InnoDB 引擎中使用的是聚集索引，由于多数 RDBMS 使用 B-tree 的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
雪花算法
这种方案大致来说是一种以划分命名空间（UUID 也算，由于比较常见，所以单独分析）来生成ID 的一种算法，Snowflake 是Twitter 开源的分布式 ID 生成算法。Snowflake 把64-bit分别划分成多段
- 第 0 位： 符号位（标识正负），始终为 0，没有用，不用管。
- 第 1~41 位 ：一共41位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41 毫秒（约69 年）
- 第 42~52 位 ：一共10位，一般来说，前5位表示机房 ID，后5位表示机器ID（实际项目中可以根据实际情况调整），这样就可以区分不同集群/机房的节点，这样就可以表示32 个IDC，每个IDC 下可以有32 台机器。
- 第 53~64 位 ：一共12位，用来表示序列号。 序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096),也就是说单台机器每毫秒最多可以生成4096个唯一ID。
理论上snowflake 方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
- 优点：
- 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
- 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
- 可以根据自身业务特性分配bit位，非常灵活。
- 缺点：强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
Mongdb ObjectID
它也可以算作是和snowflake类似方法，通过 “时间+机器码+pid+inc” 共12 个字节，通过4+3+2+3的方式最终标识成一个24长度的十六进制字符。
Seata UUID
Seata 内置了一个分布式 UUID 生成器，用于辅助生成全局事务 ID 和分支事务 ID，我们同样可以拿来使用，完整类名为：io.seata.common.util.IdWorker
数据库生成 (MySQL)
CREATE TABLE `sequence_id` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`stub` char(10) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;stub段无意义，只是为了占位，便于我们插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。
BEGIN;
REPLACE INTO sequence_id (stub) VALUES ('stub');
SELECT LAST_INSERT_ID();
COMMIT;插入数据这里，我们没有使用 insert into 而是使用 replace into 来插入数据。replace 是insert 的增强版，replace into 首先尝试插入数据到表中，
- 如果发现表中已经有此行数据（根据主键或者唯一索引判断）则先删除此行数据，然后插入新的数据。
- 否则，直接插入新数据。
- 优点：非常简单，利用现有数据库系统的功能实现，成本小，有DBA 专业维护。ID号单调自增，存储消耗空间小。
- 缺点：
- 支持的并发量不大
- 存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）
- ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！ ）
- 每次获取 ID 都要访问一次数据库（增加了对数据库的压力，获取速度也慢）
对于MySQL 性能问题，可用如下方案解决：在分布式系统中我们可以多部署几台机器，每台机器设置不同的初始值，且步长和机器数相等。比如有两台机器。设置步长step 为2，TicketServer1 的初始值为1（1，3，5，7，9，11…）、TicketServer2 的初始值为2（2，4，6，8，10…）。这是Flickr（雅虎旗下图片分享网站）团队在2010 年撰文介绍的一种主键生成策略（Ticket Servers: Distributed Unique Primary Keys on the Cheap ）。为了实现上述方案分别设置两台机器对应的参数，TicketServer1 从1 开始发号，TicketServer2 从2 开始发号，两台机器每次发号之后都递增2。假设我们要部署N 台机器，步长需设置为N，每台的初始值依次为0,1,2…N-1。
这种架构貌似能够满足性能的需求，但有以下几个缺点：
- 系统水平扩展比较困难，比如定义好了步长和机器台数之后，如果要添加机器该怎么做？假设现在只有一台机器发号是1,2,3,4,5（步长是1），这个时候需要扩容机器一台。可以这样做：把第二台机器的初始值设置得比第一台超过很多，比如140（假设在扩容时间之内第一台不可能发到140），同时设置步长为2，那么这台机器下发的号码都是140 以后的偶数。然后摘掉第一台，把ID 值保留为奇数，比如7，然后修改第一台的步长为2。让它符合我们定义的号段标准，对于这个例子来说就是让第一台以后只能产生奇数。扩容方案看起来复杂吗？貌似还好，现在想象一下如果我们线上有100 台机器，这个时候要扩容该怎么做？简直是噩梦。所以系统水平扩展方案复杂难以实现。
- ID 没有了单调递增的特性，只能趋势递增，这个缺点对于一般业务需求不是很重要，可以容忍。
- 数据库压力还是很大，每次获取ID 都得读写一次数据库，只能靠堆机器来提高性能。
Redis
通过 Redis 的 incr 命令即可实现对 id 原子顺序递增。为了提高可用性和并发，我们可以使用 Redis Cluster。
除了高可用和并发之外，我们知道 Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。很明显，Redis 方案性能很好并且生成的 ID 是有序递增的。不过，我们也知道，即使 Redis 开启了持久化，不管是快照（snapshotting，RDB）、只追加文件（append-only file, AOF）还是 RDB 和AOF 的混合持久化依然存在着丢失数据的可能，那就意味着产生的 ID 存在着重复的概率。
分布式ID微服务
Leaf-segment
Leaf-segment 方案，在使用数据库的方案上，做了如下改变：
- 原 MySQL 方案每次获取 ID 都得读写一次数据库，造成数据库压力大。改为批量获取，每次获取一个segment(step 决定大小)号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。
- 各个业务不同的发号需求用 biz_tag 字段来区分，每个 biz-tag 的 ID 获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对 biz_tag 分库分表就行。
- biz_tag 用来区分业务，max_id 表示该 biz_tag 目前所被分配的 ID 号段的最大值，step 表示每次分配的号段长度。原来获取ID 每次都需要写数据库，现在只需要把step 设置得足够大，比如1000。那么只有当1000 个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1/step。
Begin
UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
Commit- 优点：
- Leaf 服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。ID 号码是趋势递增的8byte 的64 位数字，满足上述数据库存储的主键要求。
- 容灾性高：Leaf 服务内部有号段缓存，即使DB 宕机，短时间内Leaf 仍能正常对外提供服务。
- 可以自定义 max_id 的大小，非常方便业务从原有的ID方式上迁移过来。
- 缺点：
- ID 号码不够随机，能够泄露发号数量的信息，不太安全。
- TP999 数据波动大，当号段使用完之后还是会在获取新号段时在更新数据库的I/O依然会存在着等待，tg999 数据会出现偶尔的尖刺。
- DB 宕机会造成整个系统不可用。
双buffer优化
Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID 下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。如果请求DB 的网络和DB 的性能稳定，这种情况对系统的影响是不大的，但是假如取DB 的时候网络发生抖动，或者DB 发生慢查询就会导致整个系统的响应时间变慢。为此，希望DB 取号段的过程能够做到无阻塞，不需要在DB 取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的TP999 指标。
采用双buffer 的方式，Leaf 服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。
通常推荐segment长度设置为服务高峰期发号QPS 的600 倍（10 分钟），这样即使DB 宕机，Leaf 仍能持续发号10-20 分钟不受影响。每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新。
Leaf 高可用容灾
对于第三点“DB 可用性”问题，可以采用一主两从的方式，同时分机房部署，Master 和Slave 之间采用半同步方式同步数据。美团内部使用了奇虎360 的Atlas 数据库中间件（已开源，改名为DBProxy）做主从切换。当然这种方案在一些情况会退化成异步模式，甚至在非常极端情况下仍然会造成数据不一致的情况，但是出现的概率非常小。如果要保证100%的数据强一致，可以选择使用“类Paxos算法”实现的强一致MySQL 方案，如MySQL 5.7 中的MySQL Group Replication。但是运维成本和精力都会相应的增加，根据实际情况选型即可。
Leaf-snowflake
Leaf-segment 方案可以生成趋势递增的ID，同时ID 号是可计算的，不适用于订单ID 生成场景，比如竞对在两天中午12 点分别下单，通过订单id 号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，美团提供了Leaf-snowflake 方案。
Leaf-snowflake 方案完全沿用snowflake 方案的bit 位设计，即是“1+41+10+12”的方式组装ID 号。对于workerID 的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf 服务规模较大，动手配置成本太高。所以使用Zookeeper 持久顺序节点的特性自动对snowflake节点配置wokerID。
Leaf-snowflake 是按照下面几个步骤启动的：
- 启动Leaf-snowflake 服务，连接Zookeeper，在leaf_forever 父节点下检查自己是否已经注册过（是否有该顺序子节点）。
- 如果有注册过直接取回自己的workerID（zk 顺序节点生成的int 类型ID 号），启动服务。
- 如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID 号，启动服务。
弱依赖ZooKeeper
除了每次会去ZK 拿数据以外，也会在本机文件系统上缓存一个workerID文件。当ZooKeeper 出现问题，恰好机器出现问题需要重启时，能保证服务能够正常启动。这样做到了对三方组件的弱依赖。
解决时钟问题
首先在启动时，服务会进行检查：
- 新节点通过检查综合对比其余Leaf 节点的系统时间来判断自身系统时间是否准确，具体做法是取所有运行中的Leaf-snowflake 节点的服务IP：Port，然后通过RPC 请求得到所有节点的系统时间，计算sum(time)/nodeSize，然后看本机时间与这个平均值是否在阈值之内来确定当前系统时间是否准确，准确正常启动服务，不准确认为本机系统时间发生大步长偏移，启动失败并报警。
- 在ZooKeeper 中登记过的老节点，同样会比较自身系统时间和ZooKeeper上本节点曾经的记录时间以及所有运行中的Leaf-snowflake节点的时间，不准确同样启动失败并报警。
- 在运行过程中，每隔一段时间节点都会上报自身系统时间写入ZooKeeper。
在服务运行过程中，机器的NTP 同步也会造成秒级别的回退，由于强依赖时钟，对时间的要求比较敏感，美团建议有三种解决方案，
- 可以直接关闭NTP同步；
- 在时钟回拨的时候直接不提供服务直接返回ERROR_CODE，等时钟追上
- 做一层重试，然后上报报警系统，更或者是发现有时钟回拨之后自动摘除本身节点并报警
从美团的实际运行情况来看，在2017 年闰秒出现那一次出现过部分机器回拨，由于Leaf-snowflake 的策略保证，成功避免了对业务造成的影响。
Leaf 在美团点评公司内部服务包含金融、支付交易、餐饮、外卖、酒店旅游猫眼电影等众多业务线。目前Leaf 的性能在4C8G 的机器上QPS 能压测到近5万/s，TP999 1ms，已经能够满足大部分的业务的需求。每天提供亿数量级的调用量。
总结梳理
要求：全局唯一性、单调（趋势）递增、信息安全（不能泄露订单量）
UUID：MAC 地址泄露、无序（数据库主键无序导致B树频繁变动）
雪花算法：时钟回拨
Mongdb ObjectID
Seata UUID：io.seata.common.util.IdWorker
MySQL：泄露发号数量、增加数据库压力
-
多部署几台机器，每台机器设置不同的初始值，且步长和机器数相等
-
水平扩展比较困难
-
没有了单调递增的特性（不同机器只能保证趋势递增）
-
每次只获取一个ID，数据库压力依然很大
-
Redis：持久化数据时存在着丢失数据的可能
Leaf-segment
-
泄露发号数量
-
TP999偶尔的尖刺
-
双buffer优化：
-
下发10%时更新下一个号段，下发完后切换到下个号段
-
segment长度设置为服务高峰期发号QPS的600倍（10 分钟），DB宕机时Leaf 仍能持续发号10-20 分钟
-
-
**Leaf 高可用容灾（一主两从）：**DBProxy(360), Paxos(强一致)
-
Leaf-snowflake
-
使用Zookeeper配置workerid，本地缓存workerid文件
-
解决时钟问题
-
新节点启动时计算sum(time)/nodeSize是否超过阈值
-
老节点每隔一段时间上报自身系统时间
-
老节点比较zookeeper上本节点曾经的记录时间
-
老节点比较所有运行中的节点时间
-
-
出现时钟回拨
-
直接关闭NTP同步
-
直接不提供服务返回ERROR_CODE，等时钟追上
-
做一层重试，然后上报报警系统
-
自动摘除本身节点并报警
-
Leaf 的性能在4C8G 的机器上QPS 能压测到近5万/s，TP999 1ms
