分布式ID的生成器——CosId【设计+实现】

CosId简介

CosId 旨在提供通用、灵活、高性能的分布式 ID 生成器。 目前提供了两类 ID 生成器：

• SnowflakeId : 单机 TPS 性能：409W/s JMH 基准测试 , 主要解决 时钟回拨问题 、机器号分配问题 并且提供更加友好、灵活的使用体验。
• SegmentId: 每次获取一段 (Step) ID，来降低号段分发器的网络IO请求频次提升性能。IdSegmentDistributor: 号段分发器（号段存储器）RedisIdSegmentDistributor: 基于 Redis 的号段分发器。JdbcIdSegmentDistributor: 基于 Jdbc 的号段分发器，支持各种关系型数据库。SegmentChainId(推荐):SegmentChainId (lock-free) 是对 SegmentId 的增强。性能可达到近似 AtomicLong 的 TPS 性能:12743W+/s JMH 基准测试 。PrefetchWorker 维护安全距离(safeDistance), 并且支持基于饥饿状态的动态safeDistance扩容/收缩。

背景（为什么需要分布式ID）

在软件系统演进过程中，随着业务规模的增长，我们需要进行集群化部署来分摊计算、存储压力，应用服务我们可以很轻松做到无状态、弹性伸缩。
但是仅仅增加服务副本数就够了吗？显然不够，因为性能瓶颈往往是在数据库层面，那么这个时候我们就需要考虑如何进行数据库的扩容、伸缩、集群化，通常使用分库、分表的方式来处理。
那么我如何分片(水平分片，当然还有垂直分片不过不是本文需要讨论的内容)呢，分片的前提是我们得先有一个ID，然后才能根据分片算法来分片。（比如比较简单常用的ID取模分片算法，这个跟Hash算法的概念类似，我们得先有key才能进行Hash取得插入槽位。）

当然还有很多分布式场景需要分布式ID，这里不再一一列举。

分布式ID方案的核心指标

• 全局（相同业务）唯一性：唯一性保证是ID的必要条件，假设ID不唯一就会产生主键冲突，这点很容易可以理解。通常所说的全局唯一性并不是指所有业务服务都要唯一，而是相同业务服务不同部署副本唯一。
  比如 Order 服务的多个部署副本在生成t_order这张表的Id时是要求全局唯一的。至于t_order_item生成的ID与t_order是否唯一，并不影响唯一性约束，也不会产生什么副作用。
  不同业务模块间也是同理。即唯一性主要解决的是ID冲突问题。
• 有序性：有序性保证是面向查询的数据结构算法（除了Hash算法）所必须的，是二分查找法(分而治之)的前提。MySq-InnoDB B+树是使用最为广泛的，假设 Id 是无序的，B+ 树 为了维护 ID 的有序性，就会频繁的在索引的中间位置插入而挪动后面节点的位置，甚至导致频繁的页分裂，这对于性能的影响是极大的。那么如果我们能够保证ID的有序性这种情况就完全不同了，只需要进行追加写操作。所以 ID 的有序性是非常重要的，也是ID设计不可避免的特性。
• 吞吐量/性能(ops/time)：即单位时间（每秒）能产生的ID数量。生成ID是非常高频的操作，也是最为基本的。假设ID生成的性能缓慢，那么不管怎么进行系统优化也无法获得更好的性能。一般我们会首先生成ID，然后再执行写入操作，假设ID生成缓慢，那么整体性能上限就会受到限制，这一点应该不难理解。
• 稳定性(time/op)：稳定性指标一般可以采用每个操作的时间进行百分位采样来分析，比如 CosId 百分位采样 P9999=0.208 us/op，即 0% ~ 99.99% 的单位操作时间小于等于 0.208 us/op。百分位数 WIKI ：统计学术语，若将一组数据从小到大排序，并计算相应的累计百分点，则某百分点所对应数据的值，就称为这百分点的百分位数，以Pk表示第k百分位数。百分位数是用来比较个体在群体中的相对的位量数。为什么不用平均每个操作的时间：马老师的身价跟你的身价能平均么？平均后的值有意义不？可以使用最小每个操作的时间、最大每个操作的时间作为参考吗？因为最小、最大值只说明了零界点的情况，虽说可以作为稳定性的参考，但依然不够全面。而且