• 一、改进：
• 二、数据库表设计：
  • 字段说明：
  • 优势：
  • 架构图：
• 三、优点：
• 四、缺点：
• 五、双buffer优化：
  • 实现图：
• 六、高可用：

本文来自官方文档的简单总结，非原创！！！

一、改进：

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