Leaf——来自美团点评的分布式ID生成系统

背景介绍

在复杂分布式系统中，每每须要对大量的数据和消息进行惟一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增加，对数据分库分表后须要有一个惟一ID来标识一条数据或消息，数据库的自增ID显然不能知足需求；特别一点的如订单、骑手、优惠券也都须要有惟一ID作标识。此时一个可以生成全局惟一ID的系统是很是必要的。归纳下来，那业务系统对ID号的要求有哪些呢？

1. 全局惟一性：不能出现重复的ID号，既然是惟一标识，这是最基本的要求。

2. 趋势递增：在MySQL InnoDB引擎中使用的是汇集索引，因为多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面咱们应该尽可能使用有序的主键保证写入性能。

3. 单调递增：保证下一个ID必定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。

4. 信息安全：若是ID是连续的，恶意用户的扒取工做就很是容易作了，直接按照顺序下载指定URL便可；若是是订单号就更危险了，竞对能够直接知道咱们一天的单量。因此在一些应用场景下，会须要ID无规则、不规则。

上述123对应三类不一样的场景，3和4需求仍是互斥的，没法使用同一个方案知足。

同时除了对ID号码自身的要求，业务还对ID号生成系统的可用性要求极高，想象一下，若是ID生成系统瘫痪，整个美团点评支付、优惠券发券、骑手派单等关键动做都没法执行，这就会带来一场灾难。

由此总结下一个ID生成系统应该作到以下几点：

1. 平均延迟和TP999延迟都要尽量低；

2. 可用性5个9；

3. 高QPS。

常见方法介绍

UUID

UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF发布的UUID规范（http://www.ietf.org/rfc/rfc4122.txt）。

优势：

性能很是高：本地生成，没有网络消耗。

缺点：

• 不易于存储：UUID太长，16字节128位，一般以36长度的字符串表示，不少场景不适用。

• 信息不安全：基于MAC地址生成UUID的算法可能会形成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制做者位置。

• ID做为主键时在特定的环境会存在一些问题，好比作DB主键的场景下，UUID就很是不适用：

  ① MySQL官方有明确的建议主键要尽可能越短越好[4]，36个字符长度的UUID不符合要求。

  ② 对MySQL索引不利：若是做为数据库主键，在InnoDB引擎下，UUID的无序性可能会引发数据位置频繁变更，严重影响性能。

类snowflake方案

这种方案大体来讲是一种以划分命名空间（UUID也算，因为比较常见，因此单独分析）来生成ID的一种算法，这种方案把64-bit分别划分红多段，分开来标示机器、时间等，好比在snowflake中的64-bit分别表示以下图（图片来自网络）所示：

41-bit的时间能够表示（1L<<41）/（1000L*3600*24*365）=69年的时间，10-bit机器能够分别表示1024台机器。若是咱们对IDC划分有需求，还能够将10-bit分5-bit给IDC，分5-bit给工做机器。这样就能够表示32个IDC，每一个IDC下能够有32台机器，能够根据自身需求定义。12个自增序列号能够表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式能够保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不一样的。

这种方式的优缺点是：

优势：

• 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。

• 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是很是高的。

• 能够根据自身业务特性分配bit位，很是灵活。

缺点：

• 强依赖机器时钟，若是机器上时钟回拨，会致使发号重复或者服务会处于不可用状态。

应用举例Mongdb objectID

MongoDB官方文档 ObjectID能够算做是和snowflake相似方法，经过“时间+机器码+pid+inc”共12个字节，经过4+3+2+3的方式最终标识成一个24长度的十六进制字符。

数据库生成

以MySQL举例，利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增，每次业务使用下列SQL读写MySQL获得ID号。

begin;
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
commit;

这种方案的优缺点以下：

优势：

• 很是简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护。

• ID号单调自增，能够实现一些对ID有特殊要求的业务。

缺点：

• 强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制能够尽量的增长可用性，可是数据一致性在特殊状况下难以保证。主从切换时的不一致可能会致使重复发号。

• ID发号性能瓶颈限制在单台MySQL的读写性能。

对于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。

TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2

假设咱们要部署N台机器，步长需设置为N，每台的初始值依次为0,1,2...N-1那么整个架构就变成了以下图所示：

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

• 系统水平扩展比较困难，好比定义好了步长和机器台数以后，若是要添加机器该怎么作？假设如今只有一台机器发号是1,2,3,4,5（步长是1），这个时候须要扩容机器一台。能够这样作：把第二台机器的初始值设置得比第一台超过不少，好比14（假设在扩容时间以内第一台不可能发到14），同时设置步长为2，那么这台机器下发的号码都是14之后的偶数。而后摘掉第一台，把ID值保留为奇数，好比7，而后修改第一台的步长为2。让它符合咱们定义的号段标准，对于这个例子来讲就是让第一台之后只能产生奇数。扩容方案看起来复杂吗？貌似还好，如今想象一下若是咱们线上有100台机器，这个时候要扩容该怎么作？简直是噩梦。因此系统水平扩展方案复杂难以实现。

• ID没有了单调递增的特性，只能趋势递增，这个缺点对于通常业务需求不是很重要，能够容忍。

• 数据库压力仍是很大，每次获取ID都得读写一次数据库，只能靠堆机器来提升性能。

Leaf 方案实现

Leaf这个名字是来自德国哲学家、数学家莱布尼茨的一句话：

There are no two identical leaves in the world

"世界上没有两片相同的树叶"

综合对比上述几种方案，每种方案都不彻底符合咱们的要求。因此Leaf分别在上述第二种和第三种方案上作了相应的优化，实现了Leaf-segment和Leaf-snowflake方案。

Leaf-segment数据库方案

第一种Leaf-segment方案，在使用数据库的方案上，作了以下改变：

• 原方案每次获取ID都得读写一次数据库，形成数据库压力大。改成利用proxy server批量获取，每次获取一个segment(step决定大小)号段的值。用完以后再去数据库获取新的号段，能够大大的减轻数据库的压力。

• 各个业务不一样的发号需求用biz_tag字段来区分，每一个biz-tag的ID获取相互隔离，互不影响。若是之后有性能需求须要对数据库扩容，不须要上述描述的复杂的扩容操做，只须要对biz_tag分库分表就行。

数据库表设计以下：

重要字段说明：biz_tag用来区分业务，max_id表示该biz_tag目前所被分配的ID号段的最大值，step表示每次分配的号段长度。原来获取ID每次都须要写数据库，如今只须要把step设置得足够大，好比1000。那么只有当1000个号被消耗完了以后才会去从新读写一次数据库。读写数据库的频率从1减少到了1/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宕机会形成整个系统不可用。

双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分钟不受影响。

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

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还提供了针对服务的过载保护、一键截流、动态流量分配等对服务的保护措施。

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是按照下面几个步骤启动的：

1. 启动Leaf-snowflake服务，链接Zookeeper，在leaf_forever父节点下检查本身是否已经注册过（是否有该顺序子节点）。

2. 若是有注册过直接取回本身的workerID（zk顺序节点生成的int类型ID号），启动服务。

3. 若是没有注册过，就在该父节点下面建立一个持久顺序节点，建立成功后取回顺序号当作本身的workerID号，启动服务。

弱依赖ZooKeeper

除了每次会去ZK拿数据之外，也会在本机文件系统上缓存一个workerID文件。当ZooKeeper出现问题，刚好机器出现问题须要重启时，能保证服务可以正常启动，这样作到了对三方组件的弱依赖，必定程度上提升了SLA。

解决时钟问题

由于这种方案依赖时间，若是机器的时钟发生了回拨，那么就会有可能生成重复的ID号，须要解决时钟回退的问题。

参见上图整个启动流程图，服务启动时首先检查本身是否写过ZooKeeper leaf_forever节点：

1. 若写过，则用自身系统时间与leaf_forever/${self}节点记录时间作比较，若小于leaf_forever/${self}时间则认为机器时间发生了大步长回拨，服务启动失败并报警。

2. 若未写过，证实是新服务节点，直接建立持久节点leaf_forever/${self}并写入自身系统时间，接下来综合对比其他Leaf节点的系统时间来判断自身系统时间是否准确，具体作法是取leaf_temporary下的全部临时节点(全部运行中的Leaf-snowflake节点)的服务IP：Port，而后经过RPC请求获得全部节点的系统时间，计算sum(time)/nodeSize。

3. 若abs( 系统时间-sum(time)/nodeSize ) < 阈值，认为当前系统时间准确，正常启动服务，同时写临时节点leaf_temporary/${self} 维持租约。

4. 不然认为本机系统时间发生大步长偏移，启动失败并报警。

5. 每隔一段时间(3s)上报自身系统时间写入leaf_forever/${self}。

因为强依赖时钟，对时间的要求比较敏感，在机器工做时NTP同步也会形成秒级别的回退，建议能够直接关闭NTP同步。要么在时钟回拨的时候直接不提供服务直接返回ERROR_CODE，等时钟追上便可。或者作一层重试，而后上报报警系统，更或者是发现有时钟回拨以后自动摘除自己节点并报警，以下：

从上线状况来看，在2017年闰秒出现那一次出现过部分机器回拨，因为Leaf-snowflake的策略保证，成功避免了对业务形成的影响。

Leaf现状

Leaf在美团点评公司内部服务包含金融、支付交易、餐饮、外卖、酒店旅游、猫眼电影等众多业务线。目前Leaf的性能在4C8G的机器上QPS能压测到近5w/s，TP999 1ms，已经可以知足大部分的业务的需求。天天提供亿数量级的调用量，做为公司内部公共的基础技术设施，必须保证高SLA和高性能的服务，咱们目前还仅仅达到了及格线，还有不少提升的空间。