分布式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.2亿/s？

RedisChainIdBenchmark-Throughput

MySqlChainIdBenchmark-Throughput

上面的两张图给许多同学带来了困扰，为什么在Step=1000的时候RedisChainIdBenchmark、MySqlChainIdBenchmarkTPS性能几乎一致(TPS=1.2亿/s)。

RedisIdSegmentDistributor应该要比JdbcIdSegmentDistributor性能更高才对啊，为什么都能达到AtomicLong性能上限呢？

如果我说当Step=1时，只要基准测试的时间够长，那么他们依然能够达到AtomicLong性能级别(TPS=1.2亿/s)，你会不会更加困惑。

其实这里的障眼法是PrefetchWorker的饥饿膨胀导致的，SegmentChainId的极限性能跟分发器的TPS性能没有直接关系，因为最终都可以因饥饿膨胀到性能上限，只要给足够的时间膨胀。

而为什么在上图的Step=1时TPS差异还是很明显的，这是因为RedisIdSegmentDistributor膨胀得更快，而基准测试又没有给足测试时间而已。

SegmentChainId基准测试TPS极限性能可以近似使用以下的公式的表示：

TPS(SegmentChainId)极限值=(Step*Expansion)*TPS(IdSegmentDistributor)*T/s<=TPS(AtomicLong)

<=TPS(AtomicLong)：因为SegmentChainId的内部号段就是使用的AtomicLong，所以这是性能上限。
Step*Expansion：Expansion可以理解为饥饿膨胀系数，默认的饥饿膨胀系数是2。在MySqlChainIdBenchmark、MySqlChainIdBenchmark基准测试中这个值是一样的。
TPS(IdSegmentDistributor): 这是公式中唯一的不同。指的是请求号段分发器NextMaxId的TPS。
T: 可以理解为基准测试运行时常。

从上面的公式中不难看出RedisChainIdBenchmark、MySqlChainIdBenchmark主要差异是分发器的TPS性能。

分发器的TPS(IdSegmentDistributor)越大，达到TPS(AtomicLong)所需的T就越少。但只要T足够长，那么任何分发器都可以达到近似TPS(AtomicLong)。

这也就解释了为什么不同TPS性能级别的号段分发器(IdSegmentDistributor)都可以达到TPS=1.2亿/s。

CosId需要部署服务端吗？

CosId是以本地SDK的形式存在的，用户只需要安装一下CosId的依赖包做一些简单配置（快速开始、DEMO）即可。

分布式ID是不适合使用服务端部署模式的(C/S)。使用服务端部署模式，必然会产生网络IO（Client通过远程过程调用Server，获取ID），你想想我们费了那么大劲消除网络IO是为了什么？

PrefetchWorker 是如何维护安全距离的？

定时维护：每隔一段时间PrefetchWorker会主动检测安全距离是否满足配置要求，如果不满足则执行NextMaxId预取，保证安全距离。
被动饥饿唤醒：当获取ID的线程获取ID时没有可用号段，会尝试获取新的号段，并主动唤醒PrefetchWorker并告诉他你太慢了，被唤醒的PrefetchWorker会检测安全距离是否需要膨胀，然后进行安全距离的维护。

本机单调、全局趋势递增-为什么还要尽可能保证单调递增？

从上文的论述中我们不难理解本机单调递增，全局趋势递增是权衡后的设计结果。

但是全局趋势递增的背面是周期内ID乱序，所以尽可能向单调递增优化（降低ID乱序程度）是优化目标，这俩点并不冲突。

如果各位同学还有其他问题请至 Issues 提交你的疑问。