一. 前言

分布式ID 是分布式系统里面非常重要的一个组成部分,那么我们在设计分布式ID的时候,需要考虑什么问题呢?

  • 简单结构下是怎么实现 ID 的控制的?

  • 单实例系统 :通过时间戳,系统内自增,上锁等方式保证ID的唯一性

  • 单数据库实例 : 通过自增字段(不谈性能)实现ID的唯一

  • 微服务 + 分库分表了 ,又该如何进行控制?

  • 问题 : 单个系统没办法直接感知到其他系统的ID情况,哪怕通信也要付出极大的代价

二. 来理解分布式ID的原则

2.1 分布式 ID 的本质是什么 ?

  • 全局唯一 : 要保证的是在任何场景下,任何系统,任何库,同一业务场景中生成的ID一定是唯一的

  • 递增 : 有的文章里面会谈到单调递增和趋势递增,这讲到的是2个维度:

  • 一个要求ID是有序增长的(趋势递增 ,用于排序

  • 一个是要求ID是正向增长的(单调递增 ,下一个一定比上一个大

  • 无规则 : 无规则是指不能按照MySQL主键自增这种方式进行 + 1 自增,简单的自增方式会带来安全层面的风险

最近无意间获得一份阿里大佬写的刷题笔记,一下子打通了我的任督二脉,进大厂原来没那么难。这是大佬写的,7701页的BAT大佬写的刷题笔记,让我offer拿到手软

2.2 有哪些相同性质的问题?

对于分布式 ID 的实现 ,在某些思路上和很多业务是通用的 ,例如 :

  • 订单编号的生成逻辑 :有序 + 反映时间
  • 券码的生成逻辑 : 有序 + 不可推测
  • 动态码 : 付款码,会员动态码等等

这些码的生产一般都会包含上述的2项原则,一定会要求全局唯一 ,同时根据情况来进行有序或者无序的控制。

其实无序一般也是看起来无序,在底层逻辑的生成上不可能完全无序,否则总会出现冲突的场景。

2.3 分布式 ID 的根本实现方式是什么 ?

ID的生成本质上只需要关注两个核心 :

  • 区域的划分 :我们需要保证每台机器是一个固定的区域 ,一般称之为机器ID
  • 锁的控制 : 不止是不同服务之间的分布式锁,还包括同一个服务的线程锁

来简单解读下 ,服务之间的通信很消耗资源 ,所以能不通信实现分布式ID的生成效率是最高的 , 那么一般会在服务启动的时候就计算出对应的工作区间。

同时要理解的是 ,锁往往和性能是对立关系,锁越多 ,则性能会相对越差,所以如何控制锁的粒度,则是分布式ID生成的一大核心。

三. 来探讨一下实现的思路

3.1 常规的分布式ID 算法

可用但是有限制的方案

// 简易版 - 基于时间戳的ID算法 :
- 方案 : 使用时间戳作为ID的前缀,然后通过机器的IP地址或MAC地址进行哈希计算得到剩余部分
- 问题 : 过于简单 , 只能实现单机毫秒级的并发
// 低效版 - 数据库自增
- 方案 : 没有方案 ,交给数据库来
- 问题 : 性能低 , 不支持分库分表
// 升级版 - 基于UUID
- 方案 :
    - 基于时间的UUID:主要依赖当前的时间戳及机器mac地址,因此可以保证全球唯一性
    - 分布式安全的UUID:将版本1的时间戳前四位换为POSIXUIDGID
    - 基于随机数的UUID:基于随机数或伪随机数生成
    - 基于名字空间的UUIDMD5版):基于指定的名字空间/名字生成MD5散列值得到
- 问题 : 长度过长 ,无序 ,不可读

常规的方案 :

  • 基于雪花算法的ID算法

雪花算法是由Twitter开发的一种分布式ID算法,它由几部分组成:时间戳、数据中心ID和机器ID以及序列ID。该算法可以保证ID的唯一性和稳定性,但需要较为复杂的计算和管理。

  • 基于LeaseSet的ID算法

LeaseSet是一种分布式ID系统,它通过将ID划分为多个片段,然后将这些片段分配给不同的机器来生成ID。该算法可以实现高可用和可扩展性,但需要较为复杂的实现和管理。

  • 总结一下

雪花ID一般是常见的分布式ID的方案 ,很多厂商都有这种算法的变种,操作灵活性能也比较理想。我生成主键ID时就是这种方案。

而通过分段的方案性能会很高,会在分布式锁的基础上 一次拿多个ID序列 ,然后在本地消耗这些ID序列。

比如生成订单码的时候 ,会一次性取出100个码,然后本地(单机上)逐步使用这些码。

雪花ID比较通用 。分段方式性能会更好,有序性会更强,毕竟都是连着的。

最近无意间获得一份阿里大佬写的刷题笔记,一下子打通了我的任督二脉,进大厂原来没那么难。这是大佬写的,7701页的BAT大佬写的刷题笔记,让我offer拿到手软

四. 分布式 ID 的简化方案

不同的业务场景对于分布式ID的要求不同 ,所以这里不说业务相关的,只谈实现流程,也没有什么代码

4.1 为你的 ID 定义格式

  • 起始位 : 起始位一般都是 1 ,在日常使用中一般不会变动,除非系统发生了整体的重做又需要保留之前数据时 ,才可以考虑通过这个来进行扩展

  • 总长度 : 位数一般基于具体的业务场景 , 和关联的内容以及数据总量息息相关。

  • 案例一 : 内含时间戳 ,一般 ID 里面会包含一个毫秒精度的时间戳,具体看业务

  • 案例二 : 插入随机数 ,在并发比较高的情况下 ,则需要通过随机数减少ID冲突的概率

  • 总结 : 一般情况下都是 64 位的纯数字 ,短了信息少,并发低。 长了浪费空间,浪费性能,库不支持。

  • 机器ID : 用来描述对应的服务器 , 一般支持1024位(也就是 1024台服务器,大多数情况下够用了)

来看一下最常见的雪花算法的格式 :

0                                       41     51         64
+---------------------------------------+------+-----------+
| 时间戳(以毫秒为单位)                  |机器ID|    递增数  |
+---------------------------------------+------+-----------+

最近无意间获得一份阿里大佬写的刷题笔记,一下子打通了我的任督二脉,进大厂原来没那么难。这是大佬写的,7701页的BAT大佬写的刷题笔记,让我offer拿到手软

来解析下里面的一些具体的细节 :

问题一 : 关于时间戳从什么时候开始

一般我们看到的雪花算法都会以当前时间减去过去一个纪元时间 (参考时间点), 有的可能是 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 简单的实现方案

// 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里面就行了

最近无意间获得一份阿里大佬写的刷题笔记,一下子打通了我的任督二脉,进大厂原来没那么难。这是大佬写的,7701页的BAT大佬写的刷题笔记,让我offer拿到手软

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部