雪花算法相关总结

雪花算法相关总结

前言：

说起ID，特性就是唯一，在人的世界里，ID就是身份证，是每个人的唯一的身份标识。在复杂的分布式系统中，往往也需要对大量的数据和消息进行唯一标识。举个例子，数据库的ID字段在单体的情况下可以使用自增来作为ID，但是对数据分库分表后一定需要一个唯一的ID来标识一条数据，这个ID就是分布式ID。对于分布式ID而言，也需要具备分布式系统的特点：高并发，高可用，高性能等特点。

常用方案：

使用自增主键：

优点:

• 数据存储空间小
• 查询效率高

缺点:

• 如果数据量过大,会超出自增长的值范围
• 在分表分库时，id会造成错乱
• 安全性低,因为是有规律的,如果恶意扒取用户信息会很容易,如果是单据编号使用,竞争对手会容易查询出货量

---

使用UUID主键

优点:

• 出现重复的机会少
• 适合大量数据的插入和更新操作,尤其是在高并发和分布式环境下
• 安全性较高

缺点:

• 存储空间大（16 byte）,因此它将会占用更多的磁盘空间, MySQL官方有明确的建议主键要尽量越短越好，36个字符长度的UUID不符合要求
• 性能降低,对MySQL索引不利: 如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。

来个图表对比一下：

因此雪花算法在分布式项目广泛应用，Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条

消息都必须分配一条唯一的id,这些id还需要一些大致的顺序（方便客户端排序）,并且在分布式系统中不同机器产生的id必须不

同。算法核心：时间戳 + 工作机器id + 序列，了解一下：

（1）1 bit：是不用的

因为二进制里第一个 bit 为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。

---

（2）41 bit：表示的是时间戳，单位是毫秒。

41 bit 可以表示的数字多达 2^41 - 1，也就是可以标识 2 ^ 41 - 1 个毫秒值，换算成年就是表示 69 年的时间。

---

（3）10 bit：记录工作机器 id，代表的是这个服务最多可以部署在 2^10 台机器上，也就是 1024 台机器。

但是 10 bit 里 5 个 bit 代表机房 id，5 个 bit 代表机器 id。意思就是最多代表 2 ^ 5 个机房（32 个机房），每个机房里可以代表

2 ^ 5 个机器（32 台机器），也可以根据自己公司的实际情况确定。

---

（4）12 bit：这个是用来记录同一个毫秒内产生的不同 id。

12 bit 可以代表的最大正整数是 2 ^ 12 - 1 = 4096，也就是说可以用这个 12 bit 代表的数字来区分同一个毫秒内的 4096 个不同的 id。

由于在Java中64bit的整数是long类型，所以在Java中SnowFlake算法生成的id就是long来存储的。

---

说明：

当你的某个服务假设要生成一个全局唯一 id，就可以发送一个请求给部署了 SnowFlake 算法的系统，

由 SnowFlake 算法系统来生成唯一 id。

算法系统首先肯定是知道自己所在的机房和机器的，比如机房 id = 17，机器 id = 12。

接着 SnowFlake 算法系统接收到这个请求之后，首先就会用二进制位运算的方式生成一个 64 bit 的 long 型 id，64 个 bit 中的第一个 bit 是无意义的。

接着 41 个 bit，就可以用当前时间戳（单位到毫秒），然后接着 5 个 bit 设置上这个机房 id，还有 5 个 bit 设置上机器 id。

最后再判断一下，当前这台机房的这台机器上这一毫秒内，这是第几个请求，给这次生成 id 的请求累加一个序号，作为最后的 12 个 bit。

最终一个 64 个 bit 的 id 就出来了，类似于：

SnowFlake这样就可以保证：

1.所有生成的id按时间趋势递增；

2.整个分布式系统内不会产生重复id（因为有datacenterId和workerId来做区分）

SnowFlake算法的缺点：

依赖与系统时间的一致性，如果系统时间被回调，或者改变，可能会造成id冲突或者重复。

另外，实际中我们的机房并没有那么多，我们可以改进改算法，将10bit的机器id优化，成业务表或者和我们系统相关的业务。

---

推荐一篇关于分布式id生成方式的文章：
https://zhuanlan.zhihu.com/p/152179727?utm_source=com.tencent.mtt