本文来自官方文档的简单总结,非原创!!!
一、改进:
原始方案每次获取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还提供了针对服务的过载保护、一键截流、动态流量分配等对服务的保护措施。