背景
实际业务中,往往会用数据库自增
但数据日渐增多的互联网行业,分库分表则成了行业的通用解决方案;
此时数据库自增
雪花算法原理
1 基本构成
雪花算法(Snowflake)是 Twitter 开源的分布式 ID 生成算法,可以基于时间生成全局不重复的、有序的、可自增的 64 Bit 的 ID,适用于分布式系统中的 ID 生成需求。
在标准版本中由以下部分组成:
符号位(1bit)- 时间戳相对值(41bit)- 数据标志(5bit)- 机器标志(5bit)- 递增序号(12bit)
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
1、最高位是符号位,用于区分是正数还是负数,这里始终为
2、41
3、5
2 生成 ID 原理
标准版雪花算法在实例化时,由于支持的时间范围有限制,所以开始的时候需要指定一个开始时间,并指定数据标识和机器标识;
如设定开始时间为 2020-01-01 00:00:00,数据标识设置为:15,机器标识设置为
此时我们想要生成
1、获取时间戳差值
先获取当前时间戳与设定的开始时间的差值
当前时间
2、获取数据标识和机器标识
数据标识:15;机器标识:18
3、获取毫秒内计数
毫秒内计数即是同一毫秒内,获取的第
1024
雪花算法优缺点
1 优点
- 唯一性:雪花算法生成的
ID 是全局唯一的,可以在分布式系统中生成不重复的业务 ID; - 有序性:基于时间戳的特性,使得雪花算法生成的
ID 是顺序增长的; - 高性能:雪花算法的生成过程是基于位运算实现的,性能好,并且标准的雪花算法每毫秒支持
4096 个 ID 生成,满足绝大多数的业务场景; - 独立性:雪花算法不依赖中央系统或数据库,非常方便在业务中落地和进行横向水平扩展;
2 缺点
- 依赖系统时钟:雪花算法依赖系统时钟,如果时钟发生回退,会导致
ID 生成重复,当然这个都有对应的解决方案; - 有限的容量:标准的雪花算法支持每毫秒生成
4096 个 ID,如果超过了容量限制,则需要等待下一毫秒才可以生成新的 ID; - 前端精度丢失:标准雪花算法生成的
ID 在 18 位和 19 位之间(时间差超过 7.56 年,就会达到 19 位),JavaScript 的 number 类型的数值范围是:2 的 53 次方减 1,所以数字位数大于 16 位且大于 9007199254740991 的数,进制转换会存在精度问题,而雪花 ID 生成的数值过大,导致超出 JavaScript 的精度范围,无法直接在前端展示,使用字符串展示雪花 ID 可避免此问题。
定制 16 位雪花 ID
1 雪花算法定制
既然
标准的雪花算法为
1、缩短支持时间
标准雪花算法为
2、只保留机器标识
标准雪花算法支持:5
即最大支持 32 x 32 = 1024 节点部署
实际业务很少有这么大规模的机器部署,一般最多也就
3、缩短毫秒内计数
标准雪花算法同一毫秒支持
实际业务也很少能用到这么多
经过以上定制的雪花算法,最多支持 32 台机器,每台机器每毫秒能够生成最多 256 个 ID,整个集群理论上每秒可以生成 32 1000 256 = 800
2 最大支持 ID
39
8
最大生成
经过定制的雪花算法,完全满足大部分业务使用。
源码
源码发布于:moyu-framework
这篇文章写得深入浅出,让我这个小白也看懂了!