首页 > 数据库> 文章详细

分布式唯一ID（三）--Leaf-Segment数据库方案

2022-03-01 20:31:50 阅读：276 来源： 互联网

一、改进：
二、数据库表设计：
三、优点：
四、缺点：
五、双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还提供了针对服务的过载保护、一键截流、动态流量分配等对服务的保护措施。

标签：Leaf,--,数据库,号段,tag,biz,Segment,ID
来源： https://www.cnblogs.com/huigelaile/p/15951066.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9