分布式id生成器

分布式id生成器在稍微规模大一点的公司，基本上都会有的，网上的样例也比较多，本编主要讲的是公司内的一些使用吧，大家影响可能更深刻一点。

分布式id有哪些要求呢？

1. 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
2. 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
3. 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
4. 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。

上述1必须满足，其他的系统根据情况不一样，限定的场景也不一致，根据情况而定吧。但是对于线上的生产系统，还必须满足以下的场景：

1. 平均延迟和TP999延迟都要尽可能低；
2. 可用性5个9；
3. 高QPS。

1：snowfaker

雪花算法是twitter的开源分布式id生成算法，生成一个long类型的64位id。

1bit标识：符号位，基本不使用。

41bit时间截：41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截) 得到的值，41位的时间截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69

10bit的机器id：可以部署在1024个节点，如果不分机房idc的话，10位可以直接都编码id，如果区分idc的话，可以5位代表机房idc，5位标识机器id。

12bit的序列号：毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号。12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。

存在的问题：时间戳强依赖于机器时钟，时钟回拨的话，对系统影响很大，所以一般需要解决时钟回拨的问题，一般的处理就是定时上报时钟数据，这样机器启动的时候就能判断时钟是否回拨，防止时钟回拨。

2：数据库生成

2.1：单数据库

• auto_increment_offset表示自增长字段从那个数开始，他的取值范围是1 .. 65535
• auto_increment_increment表示自增长字段每次递增的量，其默认值是1，取值范围是1 .. 65535

这种方案的优缺点如下：

优点：

• 非常简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护。
• ID号单调自增，可以实现一些对ID有特殊要求的业务。

缺点：

• 强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。
• ID发号性能瓶颈限制在单台MySQL的读写性能。

2.2：多分片

 

这种架构貌似能够满足性能的需求，但有以下几个缺点：

• 系统水平扩展比较困难，比如定义好了步长和机器台数之后，如果要添加机器该怎么做？假设现在只有一台机器发号是1,2,3,4,5（步长是1），这个时候需要扩容机器一台。可以这样做：把第二台机器的初始值设置得比第一台超过很多，比如14（假设在扩容时间之内第一台不可能发到14），同时设置步长为2，那么这台机器下发的号码都是14以后的偶数。然后摘掉第一台，把ID值保留为奇数，比如7，然后修改第一台的步长为2。让它符合我们定义的号段标准，对于这个例子来说就是让第一台以后只能产生奇数。扩容方案看起来复杂吗？貌似还好，现在想象一下如果我们线上有100台机器，这个时候要扩容该怎么做？简直是噩梦。所以系统水平扩展方案复杂难以实现。
• ID没有了单调递增的特性，只能趋势递增，这个缺点对于一般业务需求不是很重要，可以容忍。
• 数据库压力还是很大，每次获取ID都得读写一次数据库，只能靠堆机器来提高性能。

在一定的环境下，这种架构师非常符合预期的，虽然存在问题，但是利大于弊，还可以解决单机所不能解决的可用性问题。

3：美团的Leaf-segment

第一种Leaf-segment方案，在使用数据库的方案上，做了如下改变： - 原方案每次获取ID都得读写一次数据库，造成数据库压力大。改为利用proxy server批量获取，每次获取一个segment(step决定大小)号段的值。用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。 - 各个业务不同的发号需求用biz_tag字段来区分，每个biz-tag的ID获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对biz_tag分库分表就行。

+-------------+--------------+------+-----+-------------------+-----------------------------+
| Field       | Type         | Null | Key | Default           | Extra                       |
+-------------+--------------+------+-----+-------------------+-----------------------------+
| biz_tag     | varchar(128) | NO   | PRI |                   |                             |
| max_id      | bigint(20)   | NO   |     | 1                 |                             |
| step        | int(11)      | NO   |     | NULL              |                             |
| desc        | varchar(256) | YES  |     | NULL              |                             |
| update_time | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
+-------------+--------------+------+-----+-------------------+-----------------------------+

 biz_tag就是你的业务名字，比如订单业务，优惠券业务，如果数据量太大的话，根据biz_tag分库就可以。

max_id表示该biz_tag目前所被分配的ID号段的最大值，比如我们分配2001-3000，这个max_id就是3000。

step表示步长，分配2001-3000，step就是1000，如果业务量太大，就调整step的大小。

test_tag在第一台Leaf机器上是1~1000的号段，当这个号段用完时，会去加载另一个长度为step=1000的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是3001~4000。同时数据库对应的biz_tag这条数据的max_id会从3000被更新成4000，更新号段的SQL语句如下：

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数据波动大，当号段使用完之后还是会hang在更新数据库的I/O上，tg999数据会出现偶尔的尖刺。
• DB宕机会造成整个系统不可用。

3.1：provider缓存段

公司内部使用的是类似leaf的生成器，其中的异类是provider提供缓存服务，生成的端保存在provider端，如果服务端不重启的话，id段就不会丢失。

3.2：client缓存段

公司内部还有一种id段缓存在client端，这种的话，应用一重启，id段就会丢失，如果应用频繁上线的话，那么id的增长会很快，另外client端如果机器很多，更会加速消耗id段，但是也是有好处的，节省了一次网络的io，有弊就有利，无所谓好坏，这二种在内部都有用。

4：双buffer优化

对于第二个缺点，Leaf-segment做了一些优化，简单的说就是：

Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。如果请求DB的网络和DB的性能稳定，这种情况对系统的影响是不大的，但是假如取DB的时候网络发生抖动，或者DB发生慢查询就会导致整个系统的响应时间变慢。

为此，我们希望DB取号段的过程能够做到无阻塞，不需要在DB取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的TP999指标。详细实现如下图所示：

采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。

• 每个biz-tag都有消费速度监控，通常推荐segment长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。

• 每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新。

5：Leaf高可用容灾 

对于第三点“DB可用性”问题，我们目前采用一主两从的方式，同时分机房部署，Master和Slave之间采用半同步方式[5]同步数据。同时使用公司Atlas数据库中间件(已开源，改名为DBProxy)做主从切换。当然这种方案在一些情况会退化成异步模式，甚至在非常极端情况下仍然会造成数据不一致的情况，但是出现的概率非常小。如果你的系统要保证100%的数据强一致，可以选择使用“类Paxos算法”实现的强一致MySQL方案，如MySQL 5.7前段时间刚刚GA的MySQL Group Replication。但是运维成本和精力都会相应的增加，根据实际情况选型即可。

 同时Leaf服务分IDC部署，内部的服务化框架是“MTthrift RPC”。服务调用的时候，根据负载均衡算法会优先调用同机房的Leaf服务。在该IDC内Leaf服务不可用的时候才会选择其他机房的Leaf服务。同时服务治理平台OCTO还提供了针对服务的过载保护、一键截流、动态流量分配等对服务的保护措施。

6：Leaf动态调整Step

假设服务QPS为Q，号段长度为L，号段更新周期为T，那么Q * T = L。最开始L长度是固定的，导致随着Q的增长，T会越来越小。但是Leaf本质的需求是希望T是固定的。那么如果L可以和Q正相关的话，T就可以趋近一个定值了。所以Leaf每次更新号段的时候，根据上一次更新号段的周期T和号段长度step，来决定下一次的号段长度nextStep：

• T < 15min，nextStep = step * 2
• 15min < T < 30min，nextStep = step
• T > 30min，nextStep = step / 2

至此，满足了号段消耗稳定趋于某个时间区间的需求。当然，面对瞬时流量几十、几百倍的暴增，该种方案仍不能满足可以容忍数据库在一段时间不可用、系统仍能稳定运行的需求。因为本质上来讲，Leaf虽然在DB层做了些容错方案，但是号段方式的ID下发，最终还是需要强依赖DB。

说了那么多了，还没有进入到正题，下面才是正题，实际的场景，订单号生成。

 7：订单号生成策略

7.1：多分片

上面也说了更高可用的策略，但是无论你做的再好，在集团的核心应用的场景中，一主多从的场景是不会被采用的，一个最主要的问题就是单点，如果你的mysql现在单个系统就是因为流量太大，重启了就死，那你怎么办？比如订单号这种场景，用户长时间不能下单，这种问题是不允许发生的，所以在这种技术环境下，公司内部还是有一种变种的。

虽然不利于扩展，但是这种架构是一种必然的选择，因为业务区域稳定，这种基本上是不会再进行扩展了，扩展的时候回麻烦一点，根据上面数据库的分片规则，就是步长都乘了1000，分片规则这块自由发挥吧。

7.2：队列优化

为了应对机房db突然出问题，还有就是流量突然的暴增，内部有四个queue，会保存一部分的id端，也就是idx4，应对突然的流量的暴增，有一个缓冲，内部有一个task，一直是while（true），只要不满，就一直往里面塞，动态扩展和收缩分段是没有的，这一块不太好，估计后续会优化。也许不会，毕竟已经很稳定了。

8：小结

其他的还有redis生成等，就不介绍了，基本上写完这篇，所有想写的基本上都已经写完了，本来还想写下spring，网上已经很多了，我就不写了，如果下面还写的话，我会写单篇介绍的功能，详细的分析源码的过程了，不知道什么时候了，到此为止，还是想勉励自己喝读到帖子的人，持续学习，让自己始终处于进步的状态吧。