Leaf分布式ID生成方案
之前我们学习过雪花算法，这次我们看下美团的分布式ID服务的解决方案。
简介
Leaf是美团自主研发设计的分布式ID生成方案，经历了美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的大流量考验，让我们看看它是如何做到。
Leaf这个名字是来自德国哲学家、数学家莱布尼茨的一句话： >There are no two identical leaves in the world > “世界上没有两片相同的树叶”，以下是美团对该系统的要求：
- 平均延迟和TP999延迟都要尽可能低；
- 可用性5个9；
- 高QPS
Leaf方案实现
Leaf基于数据库生成和雪花算法实现了两种分布式ID方案：Leaf-segment和Leaf-snowflake。
Leaf-segment数据库方案
通过缓存加数据库的方式生成ID，数据库中存储id的业务类型、已使用最大id、每次获取的长度，Leaf服务通过业务类型向数据库获取固定步长的id，存储在缓存中，使用完再循环向数据库获取。
数据库表设计如下：
+-------------+--------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+-------------------+-----------------------------+
| biz_tag | varchar(128) | NO | PRI | | 业务类型 |
| max_id | bigint(20) | NO | | 1 | 已使用id |
| step | int(11) | NO | | NULL | 每次获取步长 |
| desc | varchar(256) | YES | | NULL | |
| update_time | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
+-------------+--------------+------+-----+-------------------+-----------------------------+同时为了高可用，分布式部署Leaf服务，同时为了降低对数据库的依赖，设计步长，步长内的id未消耗完不会依赖到数据库，步长的大小依据业务最高TPS的600倍，保证在数据库挂掉后，在10分钟内仍能持续提供id。
持续压测下，TP999数据波动大，当号段使用完之后还是会hang在更新数据库的I/O上，TP999数据会出现偶尔的尖刺，为了解决该问题使用双缓存的策略，即第一个缓存达到某个阈值，如号段的80%，则开始向数据库获取下个号段的id存入第二个缓存中，这样就能保证数据库网络抖动时能把请求’尖刺‘抹平，这个设计让我想到JVM垃圾回收机制的from区和to区，当然解决的问题不一样。
设计其实是通俗易懂的，这样的设计有以下优势
- 拓展容易 根据业务类型区分id，每次新增id只需数据库中加条数据即可。
- 高可用、高响应，通过分布式实现高可用，使用缓存实现高响应。
- ID单调递增、长度可控，满足数据库存储的主键要求。
缺点：
- ID号码不够随机，能够泄露发号数量的信息，不太安全。
- DB宕机会造成整个系统不可用。
