分布式系统ID(CosId)之号码段链方式特性(1.2亿/s)分析

上一篇文章《分布式ID生成器（CosId）设计与实现》大家早已简易探讨过CosId的设计方案与完成全景。

可是有很多同学们有一些疑惑：CosId的号码段链方式（SegmentChainId）特性有一些难以想象(TPS最高值特性1.2亿/s)，乃至是不一样特性等级号码段派发器（RedisIdSegmentDistributor、JdbcIdSegmentDistributor）均可以做到那样的特性等级。

因此 这篇文章内容将深层分析CosId的号码段链方式（SegmentChainId）的设计理念与完成提升。

新同学们最好是先查看上一篇文章《分布式ID生成器（CosId）设计与实现》。

情况（为何必须 SegmentChainId）

根据上一篇文章《分布式ID生成器（CosId）设计与实现》我们知道号码段方式（SegmentId）关键有下列难题：

• 可靠性：SegmentId的可靠性难题关键是由于号码段用完以后获得ID的进程必须 同时进行NextMaxId造成的（会造成互联网IO）。
• 步幅（Step）：设定多少的步幅是一个衡量难题，设定过小会危害总体特性，设定太交流会造成全局性ID乱序的水平提升。
• 该设备单调递增、全局性发展趋势增长: 当地单调递增是大家期待见到的，可是怎样看待/考量全局性发展趋势增长呢。下边大家来解释一下什么叫全局性发展趋势增长：

从图中的号码段方式设计方案中我们可以看得出：

• Instance 1每一次获得的NextMaxId，一定比上一次大，代表着下一次的号码段一定比上一次大，即F(T_{n 1})>F(T_n)，因此 从单案例上看来是单调递增的。
• Instance 1、Instance 2案例分别拥有的不一样的号码段，代表着在一个时间范围内不一样案例转化成的ID是乱序的。可是多案例在获得NextMaxId时是单调递增的，因此 总体发展趋势的增长，即全局性发展趋势增长。

全局性发展趋势增长反方向表明的是ID在一个时间周期内是会乱序的，因此 我们要尽量让ID的乱序水平减少。这是一个提升点。

号码段方式转化成的ID，在数据库查询角度能够类似的了解为上边的发展趋势增长图（T_n>T_n-s）。ID乱序的水平遭受步幅（Step）危害，步幅越小ID乱序的水平越小。这儿大家应用边界值（Step=1）作一下表明。

• 当Step=1时，即每一次都获得NextMaxId，将无穷大单调递增（数据库查询角度）。必须 留意的是这儿是无穷大并非相当于单调递增，实际缘故你能思索一下那样一个情景：
  • 号码段派发器T₁時刻给Instance 1派发了ID=1,T₂時刻给Instance 2派发了ID=2。由于设备特性、互联网等缘故，Instance 2互联网IO写要求在于Instance 1抵达。那麼这个时候针对数据库查询而言，ID仍然是乱序的。

因此 不难理解的是危害全局性ID乱序的要素有两个：群集经营规模、Step尺寸。群集经营规模是我们不能操纵的，可是Step是能够调整的。

因此 SegmentChainId便是在那样的情况下问世的。

号码段链方式（SegmentChainId）的优点

根据SegmentChainId设计图纸中我们可以见到，号码段链方式增加了一个人物角色PrefetchWorker。
PrefetchWorker关键的岗位职责是维护保养和确保号码段链头顶部到尾端的间距，还可以类似了解为缓存间距。
拥有间距的确保不会太难得到的结果是全部获得ID的进程只需从过程运行内存的号码段里面获得下一次ID就可以，理想化状况下不用再开展NextMaxId（向号码段派发器要求NextMaxId，互联网IO）的，因此 特性能够做到类似AtomicLong 的 TPS 特性:12743W /s的等级。

SegmentChainId是SegmentId的增强版，对比于SegmentId有下列优点：

• TPS特性：可做到类似 AtomicLong 的 TPS 特性:12743W /s JMH 标准检测。根据引进了新的人物角色PrefetchWorker用于维护保养和确保间距，理想化状况下促使获得ID的进程基本上彻底不用开展同歩的等候NextMaxId获得。
• 可靠性：P9999=0.208(us/op)，根据上边的TPS特性叙述中我们可以见到，SegmentChainId清除了同歩等候的难题，因此 可靠性难题也因而得到解决。
• 适应能力：从SegmentId详细介绍中大家知道危害ID乱序的要素有两个：群集经营规模、Step尺寸。群集经营规模是我们不能操纵的，可是Step是能够调整的。
  • Step应当尽量小才可以促使ID单调递增的概率扩大。
  • Step过小会危害货运量，那麼大家怎样有效设定Step呢？回答是我们无法精确预计全部时段的货运量要求，那麼最好是的方法是货运量要求高时，Step全自动扩大，货运量低时Step全自动收拢。
  • SegmentChainId引进了挨饿情况的定义，PrefetchWorker会依据挨饿情况检验当今间距是不是必须 澎涨或是收拢，便于得到货运量与有序化中间的衡量，这就是SegmentChainId的自适应性。
  • 因此 在应用SegmentChainId时我们可以配备一个较为小的Step步幅，随后由PrefetchWorker依据货运量要求自动调节间距，来全自动伸缩式步幅。

疑难问题

RedisIdSegmentDistributor、JdbcIdSegmentDistributor 均可以做到TPS=1.两亿/s？

RedisChainIdBenchmark-Throughput

MySqlChainIdBenchmark-Throughput

上边的二张图给很多同学们产生了困惑，为啥Step=1000的情况下RedisChainIdBenchmark、MySqlChainIdBenchmarkTPS特性基本上一致(TPS=1.两亿/s)。
RedisIdSegmentDistributor应当要比JdbcIdSegmentDistributor特性高些才对呀，为何都能做到AtomicLong特性限制呢？
如果是这样当Step=1时，只需标准检测的時间够长，那麼她们仍然可以做到AtomicLong特性等级(TPS=1.两亿/s)，你是否会更为疑惑。
实际上这儿的借口是PrefetchWorker的挨饿澎涨造成的，SegmentChainId的極限特性跟派发器的TPS特性沒有立即关联，由于最后都能够因挨饿澎涨到特性限制，只需给充足的时间膨胀。
而为啥图中的Step=1时TPS差别或是很显著的，这是由于RedisIdSegmentDistributor澎涨得迅速，而标准检测又沒有给足检测時间罢了。

SegmentChainId标准检测TPS極限特性能够类似应用下列的公式计算的表明：

TPS(SegmentChainId)规定值=(Step*Expansion)*TPS(IdSegmentDistributor)*T/s<=TPS(AtomicLong)

1. <=TPS(AtomicLong)：由于SegmentChainId的內部号码段便是应用的AtomicLong，因此 它是特性限制。
2. Step*Expansion：Expansion能够了解为挨饿热膨胀系数，默认设置的挨饿热膨胀系数是2。在MySqlChainIdBenchmark、MySqlChainIdBenchmark标准检测中这一值是一样的。
3. TPS(IdSegmentDistributor): 它是公式计算中唯一的不一样。指的是要求号码段派发器NextMaxId的TPS。
4. T: 能够了解为标准稳定性测试常常。

从上边的公式计算中可以看出RedisChainIdBenchmark、MySqlChainIdBenchmark关键差别是派发器的TPS特性。
派发器的TPS(IdSegmentDistributor)越大，做到TPS(AtomicLong)需要的T就越低。但只需T充足长，那麼一切派发器都能够做到类似TPS(AtomicLong)。
这也就表述了为何不一样TPS特性等级的号码段派发器(IdSegmentDistributor)都能够做到TPS=1.两亿/s。

CosId必须 布署服务器端吗？

CosId是以当地SDK的方式存有的，客户只必须 安裝一下CosId的依赖包做一些简易配备（快速开始、DEMO）就可以。

分布式系统ID是不宜应用服务器端布署方式的(C/S)。应用服务器端布署方式，必定会造成互联网IO（Client根据远程控制全过程启用Server，获得ID），你想一想大家费了那么大劲清除互联网IO是为了什么？

PrefetchWorker 是怎样维护保养间距的？

• 按时维护保养：每过一段时间PrefetchWorker会积极检验间距是不是达到配备规定，假如不符合则实行NextMaxId预取，确保间距。
• 处于被动挨饿唤起：当获得ID的进程获得ID时沒有可以用号码段，会试着获得新的号码段，并积极唤起PrefetchWorker并对他说你太慢了，被唤起的PrefetchWorker会检验间距是不是必须 澎涨，随后开展间距的维护保养。

该设备简单、全局性发展趋势增长-为何还需要尽量确保单调递增？

从前文的阐述中大家不难理解该设备单调递增，全局性发展趋势增长是衡量后的设计方案結果。
可是全局性发展趋势增长的反面是周期时间内ID乱序，因此 尽量向单调递增提升（减少ID乱序水平）是提升总体目标，这个点并不矛盾。

假如诸位同学们也有别的难题请至 Issues 递交你的疑惑。