一. 前言
五一玩得太嗨，无心学习 ，所以找一个很小的点聊一聊，希望能对大家有所帮助。
分布式 ID 是分布式系统里面非常重要的一个组成部分，那么我们在设计分布式ID的时候，需要考虑什么问题呢？文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
- ❓简单结构下是怎么实现 ID 的控制的？
- 单实例系统 ：通过时间戳，系统内自增，上锁等方式保证ID的唯一性
- 单数据库实例 : 通过自增字段（不谈性能）实现ID的唯一
- ❓
微服务 + 分库分表了，又该如何进行控制？- 问题 ： 单个系统没办法
直接感知到其他系统的ID情况，哪怕通信也要付出极大的代价
- 问题 ： 单个系统没办法
二. 来理解分布式ID的原则
2.1 分布式 ID 的本质是什么 ？
- 全局唯一 ： 要保证的是在任何场景下，
任何系统，任何库，同一业务场景中生成的ID一定是唯一的 - 递增 ： 有的文章里面会谈到单调递增和趋势递增，这讲到的是2个维度：
- 一个要求ID是有序增长的（
趋势递增 ，用于排序） - 一个是要求ID是正向增长的（
单调递增 ，下一个一定比上一个大）
- 一个要求ID是有序增长的（
- 无规则 ： 无规则是指不能按照MySQL主键自增这种方式进行 + 1 自增，简单的自增方式会带来安全层面的风险
2.2 有哪些相同性质的问题？
对于分布式 ID 的实现 ，在某些思路上和很多业务是通用的 ，例如 ：文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
- 订单编号的生成逻辑 ：有序 + 反映时间
- 券码的生成逻辑 ： 有序 + 不可推测
- 动态码 ： 付款码，会员动态码等等
这些码的生产一般都会包含上述的2项原则，一定会要求全局唯一 ，同时根据情况来进行有序或者无序的控制。文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
其实无序一般也是看起来无序，在底层逻辑的生成上不可能完全无序，否则总会出现冲突的场景。文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
2.3 分布式 ID 的根本实现方式是什么 ？
ID 的生成本质上只需要关注两个核心 ：文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
- 区域的划分 ：我们需要保证每台机器是一个固定的区域 ，一般称之为机器ID
- 锁的控制 ： 不止是不同服务之间的分布式锁，还包括同一个服务的线程锁
来简单解读下 ，服务之间的通信很消耗资源 ，所以能不通信实现分布式ID的生成效率是最高的 ， 那么一般会在服务启动的时候就计算出对应的工作区间。文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
同时要理解的是 ，锁往往和性能是对立关系，锁越多 ，则性能会相对越差，所以如何控制锁的粒度，则是分布式ID生成的一大核心。文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
三. 来探讨一下实现的思路
3.1 常规的分布式ID 算法
可用但是有限制的方案文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
java
// 简易版 - 基于时间戳的ID算法 ：
- 方案 ： 使用时间戳作为ID的前缀，然后通过机器的IP地址或MAC地址进行哈希计算得到剩余部分
- 问题 ： 过于简单 , 只能实现单机毫秒级的并发
// 低效版 - 数据库自增
- 方案 ： 没有方案 ，交给数据库来
- 问题 ： 性能低 ， 不支持分库分表
// 升级版 - 基于UUID
- 方案 ：
- 基于时间的UUID：主要依赖当前的时间戳及机器mac地址，因此可以保证全球唯一性
- 分布式安全的UUID：将版本1的时间戳前四位换为POSIX的UID或GID
- 基于随机数的UUID：基于随机数或伪随机数生成
- 基于名字空间的UUID（MD5版）：基于指定的名字空间/名字生成MD5散列值得到
- 问题 ： 长度过长 ，无序 ，不可读
常规的方案 ：文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
- ❓ 基于雪花算法的ID算法：
雪花算法是由Twitter开发的一种分布式ID算法，它由几部分组成：时间戳、数据中心ID和机器ID以及序列ID。该算法可以保证ID的唯一性和稳定性，但需要较为复杂的计算和管理。文章源自灵鲨社区-https://www.0s52.com/bcjc/javajc/15345.html
- ❓ 基于LeaseSet的ID算法
LeaseSet是一种分布式ID系统，它通过将ID划分为多个片段，然后将这些片段分配给不同的机器来生成ID。该算法可以实现高可用和可扩展性，但需要较为复杂的实现和管理。
- ❓ 总结一下 ：
雪花ID一般是常见的分布式ID的方案 ，很多厂商都有这种算法的变种，操作灵活性能也比较理想。我生成主键ID时就是这种方案。
而通过分段的方案性能会很高，会在分布式锁的基础上 一次拿多个ID序列 ，然后在本地消耗这些ID序列。
比如生成订单码的时候 ，会一次性取出100个码，然后本地（单机上）逐步使用这些码。
雪花ID比较通用 。分段方式性能会更好，有序性会更强，毕竟都是连着的。
四. 分布式 ID 的简化方案
不同的业务场景对于分布式ID的要求不同 ，所以这里不说业务相关的，只谈实现流程，也没有什么代码
4.1 为你的 ID 定义格式
- 起始位 ： 起始位一般都是 1 ，在日常使用中一般不会变动，除非系统发生了
整体的重做又需要保留之前数据时 ，才可以考虑通过这个来进行扩展 - 总长度 ： 位数一般基于具体的业务场景 ， 和关联的内容以及数据总量息息相关。
- 案例一 ： 内含时间戳 ，一般 ID 里面会包含一个毫秒精度的时间戳，具体看业务
- 案例二 ： 插入随机数 ，在并发比较高的情况下 ，则需要通过随机数减少ID冲突的概率
- 总结 ： 一般情况下都是 64 位的纯数字 ，短了信息少，并发低。 长了浪费空间，浪费性能，库不支持。
- 机器ID ： 用来描述对应的服务器 , 一般支持1024位（也就是 1024台服务器，大多数情况下够用了）
? 来看一下最常见的雪花算法的格式 ：
java
0 41 51 64
+---------------------------------------+------+-----------+
| 时间戳（以毫秒为单位） |机器ID| 递增数 |
+---------------------------------------+------+-----------+
? 来解析下里面的一些具体的细节 ：
❓问题一 ： 关于时间戳从什么时候开始
一般我们看到的雪花算法都会以当前时间减去过去一个纪元时间 （参考时间点）， 有的可能是 1970 年 1 月 1 日 00:00:00 ， 有的可能是上线时间或者一个特殊的时间点。
通过这种方式既可以减少整体的长度，让数据变得紧凑 。又可以混淆 ID 的含义，让ID 没有那么容易被解析。
比如上面那个案例 ， 可以看到最开始还空了4位数 ，所以时间戳的总空间是一定够的
❓问题二 ： 关于机器ID
机器ID 的目的主要是为了区别不同的机器，从而避免在不同机器上面生成的数据冲突，一般都是通过分布式锁的方式来启动时获取 ：
- Redis 原子获取 ： 适用于服务器Pod数不高的场景，启动不频繁，流程比较规范的情况下，用 Redis 完全是足够的
- 数据库自增 ： 一般这些ID的获取都是在系统启动时完成，所以数据库里面通过自增键去做也能实现我们的需求
- Zookeeper ： Zookeeper持久顺序节点的特性也可以实现类似的功能
这3种方式也是传统的分布式锁的获取方式 ，通过自增这种实现保证机器ID每个都不一样。
但是需要避免下面几个问题 ：
集群过大或者不同业务使用了同一个表生成 （机器ID一般就1024 ，超过了需要从 0 开始，一般是取模的方式）- 避免某个节点
长期不重启带来的机器ID冲突 - 避免某个机器
频繁的重启导致机器ID被击穿
❓问题三 ： 关于 sequence 序列ID
重点一 ： sequence ID 是先要比对时间戳的 ，时间戳一样这个值才会增加
重点二 ： 注意并发的影响 ，要么在生成 ID 的方法上添加 synchronized 控制并发 ，要么使用原子变量
❓问题四 ： 时钟回拨 切记切记
由于上述的分布式 ID 是基于时间来实现的，这种方案最大的问题在于时钟回拨，如果服务器的时间回滚了，而机器又没重启 ，就可能会出现ID的冲突。
也有相关的解决方案 ，最常见的就是启动时校验时钟，比较其他的机器上的时间，方案就不详述了。
再一个就是换种思路 ，时间不是依赖的系统时间 ，而是一个自增的时间位。 这个是百度那边的一种算法，下一章单独讲。
最后总结： ❗❗❗❗
位数不是绝对 ，在保持64位总长度的情况下 ，机器ID 和 最后的自增数都可以随便调节。
包括整体的 64 位也不是完全绝对的 ，业务不同比 64 小几位也完全是可以的。
4.2 简单的实现方案
java
// S1 : 不管用什么方案 ，Redis 原子自增什么的，拿到一个 机器ID
public long getMechineId() {
// 伪代码，方案自寻
return redisService.incr("MECHINE_ID:" + prefixName);
}
// S2 : 构建分布式ID
private static Long lastTimestamp;
// 注意并发问题 ，加锁或者原子变量
public static synchronized long buildId(){
long timestamp = System.currentTimeMillis();
// 如果时间一致 ，则需要增加 sequenceID
if (lastTimestamp == timestamp) {
sequence = sequence + 1L & 1023L;
} else {
// 瞎写的 ，目的就是拿到一个 ID ，从 0 开始也可以
sequence = (long)random.nextInt(128);
}
// 设置时间戳为最新时间戳
lastTimestamp = timestamp;
// tenantCode 是初始位 ，可以是0 ，也可以是 1
// 如果为 0 则可能导致 ID 长度不统一 ，所以这里要根据具体的情况去设置
// - 这里偏移多少位取决于后续的 sequence 想要留多少空间 ，只要时间戳偏移不要超过总数就行
// - MechineId 留了 10 位 ，也就是 1024 个机器
// - sequence 留了 12位 ，也就是每毫秒 4095 个
return tenantCode << 60 | timestamp - 1288834974657L << 22 | getMechineId() << 12 | sequence;
}
// S3 : 入库时使用
略 ，这就不用说了吧 ，写数据库的时候设置到ID里面就行了
代码不是正经代码，但是流程大差不差。
总结
本来还想把几个大厂的分布式 ID 方案一起分享出来的，时间有限下一篇再分享吧。
东西不多 ，也不复杂，如果有不对的欢迎指正。
评论