分布式ID系统设计(2)-Toy模板网

这篇具有很好参考价值的文章主要介绍了分布式ID系统设计(2)。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

接上文

https://editor.csdn.net/md/?articleId=133988963

类snowFlake 方案

应用举例 mongoDB ObjectID 就是一个典型的实现。

数据库生成

以MySQL举例利用给字段设置AUTO-INCREMENT来保证ID自增,每次业务使用SQL拿到MySQL的ID
这种方案的优缺点:

优点
1 简单。利用数据库实现成本小，有专业的DBA维护
2 ID单调递增。用来实现一些对于ID有特殊要求的业务
缺点
1 强依赖DB,当整个DB异常整个系统不可用，属于致命问题
2 ID发号性能瓶颈在于单台DB的读写性能

对于MySQL的性能问题，可以考虑多部署几台机器。然后设置不同的初始值，步数长和机器数相等。
Flickr论文
但是这玩意看起来能满足。但是存在的问题:

系统基本属于无法水平拓展。因为你定义好了步长都写死了。如果后续发现性能不够要加机器怎么处理？
ID没有单调递增。只能趋势递增。当然对于一般业务也没什么。可以忍受
数据库压力大。毕竟都读写一次DB
当然也可以用redis 但是还是一样的问题

id-service 方案

id-service-segment数据库方案

第一种id-service-segment 方案:

在使用数据库的方案上做如下改变:

每次获取ID读写DB -> 获取一个segment大小的数据量用完之后再去获取新的可以大大减少数据库压力。
各个业务用biz_tag区分每个biz-tag的Id获取相互隔离。后续再扩容

优点:
1 id-service可以方便的线性扩展。性能满足大多数业务场景
2 ID是递增的满足PK的要求
3 容灾好。id-service有缓存即使DB宕机也不影响业务不过不能太久
缺点：
1 ID号码不够随机,能够泄漏发号数量的信息,不安全。
2 因为也是获取segment 容易出现尖刺
3 DB宕机的问题

双buffer优化

对于第二个缺点，id-service-segment做了一些优化。
在取号段的时间是在号段消耗完之后进行。也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞。如果请求DB的网络和DB的性能稳定，这种情况对系统的影响是不大的，但是假如取DB的时候网络发生抖动，或者DB发生慢查询就会导致整个系统的响应时间变慢。

为此，我们希望DB取号段的过程能够做到无阻塞，不需要在DB取号段的时候阻塞请求线程，即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的延迟指标