分布式唯一ID（三）--Leaf-Segment数据库方案
本文来自官方文档的简单总结，非原创！！！
一、改进：
原始方案每次获取ID都要读写数据库，数据库压力比较大。
每次获取一个号段的值(step决定大小)，用完之后再去数据库获取新的号段，很大减轻数据库的压力。
各个业务不同的需求用biz_tag字段来区分。
如果以后因为性能等原因需要分库分表，只需要对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：区分业务。
max_id：表示该biz_tag目前所被分配的ID号段的最大值。
step：表示每次分配的号段长度。
优势：
原来获取ID每次都需要写数据库，现在只需要把step设置得足够大，比如1000。
那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。
架构图：
- test_tag在第一台Leaf机器上的号段为1~1000，当号段用完时，会去加载另一个号段。
- 假设另外两台机器号段都没有更新，这个时候第一台机器重新加载的号段应该是3001~4000。
- 同时数据库对应的biz_tag这条数据的max_id会从3000被更新成4000。
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服务方便拓展，性能方便是OK的。
- ID号码是趋势递增的64位数字，满足数据库存储的主键要求。
- Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。
- 自定义max_id，非常方便业务从原有的ID方式上迁移过来。
四、缺点：
- ID号码不够随机，可以被竞对根据ID号码得到一些信息。
- 当号段使用完之后会hang在更新数据库的I/O上，TP99数据会出现偶尔的尖刺。
- DB一段时间宕机会造成整个系统不可用。
五、双buffer优化：
针对第二个缺点，Leaf做了双buffer优化。
希望DB取号段的过程能够做到无阻塞，即当号段消费到某个阈值时就异步的把下一个号段加载到内存中。
而不是等到号段用尽的时候才去更新号段，这样做可以很大程度上的降低突刺问题。
实现图：
每个biz-tag都有消费速度监控，推荐segment长度设置为服务高峰期发号QPS的600倍（10分钟）。
这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。
六、高可用：
针对"DB可用性"的问题，采用一主两从且分机房部署，Master和Slave之间采用半同步方式同步数据。
同时使用DBProxy数据库中间件做主从切换。
这种异步模式在非常极端情况下仍然会造成数据不一致的情况，但是出现的概率非常小。
如果系统要保证100%的数据强一致，可以选择使用“类Paxos算法”实现的强一致MySQL方案，如MySQL 5.7的Group Replication。
但是运维成本和精力都会相应的增加，根据实际情况选型即可。
同时Leaf服务分IDC部署，内部的服务化框架是“MTthrift RPC”。
服务调用的时候，根据负载均衡算法会优先调用同机房的Leaf服务。
在该IDC内Leaf服务不可用的时候才会选择其他机房的Leaf服务。
同时服务治理平台OCTO还提供了针对服务的过载保护、一键截流、动态流量分配等对服务的保护措施。
