分布式唯一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个号被消耗完了之后才会去重新读写一次数据库。

架构图:

分布式唯一ID(三)--Leaf-Segment数据库方案

  • 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取号段的过程能够做到无阻塞,即当号段消费到某个阈值时就异步的把下一个号段加载到内存中。

而不是等到号段用尽的时候才去更新号段,这样做可以很大程度上的降低突刺问题。

实现图:

分布式唯一ID(三)--Leaf-Segment数据库方案

每个biz-tag都有消费速度监控,推荐segment长度设置为服务高峰期发号QPS的600倍(10分钟)。

这样即使DB宕机,Leaf仍能持续发号10-20分钟不受影响。

六、高可用:

针对"DB可用性"的问题,采用一主两从且分机房部署,Master和Slave之间采用半同步方式同步数据。

同时使用DBProxy数据库中间件做主从切换。

这种异步模式在非常极端情况下仍然会造成数据不一致的情况,但是出现的概率非常小。

如果系统要保证100%的数据强一致,可以选择使用“类Paxos算法”实现的强一致MySQL方案,如MySQL 5.7的Group Replication。

但是运维成本和精力都会相应的增加,根据实际情况选型即可。

分布式唯一ID(三)--Leaf-Segment数据库方案

同时Leaf服务分IDC部署,内部的服务化框架是“MTthrift RPC”。

服务调用的时候,根据负载均衡算法会优先调用同机房的Leaf服务。

在该IDC内Leaf服务不可用的时候才会选择其他机房的Leaf服务。

同时服务治理平台OCTO还提供了针对服务的过载保护、一键截流、动态流量分配等对服务的保护措施。

上一篇:内网信息收集


下一篇:分页