介绍Snowflake算法

SnowFlake算法是国际大公司Twitter的采用的一种生成分布式自增id的策略,这个算法产生的分布式id是足够我们我们中小公司在日常里面的使用了。我也是比较推荐这一种算法产生的分布式id的。

算法snowflake的生成的分布式id结构组成部分

算法snowflake生成id的结果是一个64bit大小的整数,它的结构如下图,

这里我么来讲一下这个结构:首先因为window是64位的,然后整数的时候第一位必须是0,所以最大的数值就是63位的111111111111111111111111111111111111111111111111111111111111111,然后呢Snowflake算法分出来41位作为毫秒值,然后10位作为redis节点的数量,然后12位做成redis节点在每一毫秒的自增序列值

41位的二进制11111111111111111111111111111111111111111转换成10进制的毫秒就是2199023255551,然后我们把 2199023255551转换成时间就是2039-09-07,也就是说可以用20年的(这里在网上会有很多说是可以使用69年的,他们说69年的也对,因为1970年+69年的结果就是2039年,但是如果从今年2019年来说,也就只能用20年了)

然后10位作为节点,所以最多就是12位的1111111111,也就是最多可以支持1023个节点,

然后10位表示每一个节点自增序列值,这里最多就是10位的111111111111,也就是说每一个节点可以每一毫秒可以最多生成4059个不重复id值

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

Java实现Snowflake算法的源码

Snowflake算法的源码如下所示(这个是我从网上找到的),这里我进行了测试了一波,结果如下所示

  1. package com.hello;
  2. import java.text.SimpleDateFormat;
  3. import java.util.Date;
  4. public class Test {
  5. /**
  6. * 开始时间截 (1970-01-01)
  7. */
  8. private final long twepoch = 0L;
  9. /**
  10. * 机器id所占的位数
  11. */
  12. private final long workerIdBits = 5L;
  13. /**
  14. * 数据标识id所占的位数
  15. */
  16. private final long datacenterIdBits = 5L;
  17. /**
  18. * 支持的最大机器id,结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数)
  19. */
  20. private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
  21. /**
  22. * 支持的最大数据标识id,结果是31
  23. */
  24. private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
  25. /**
  26. * 序列在id中占的位数
  27. */
  28. private final long sequenceBits = 12L;
  29. /**
  30. * 机器ID向左移12位
  31. */
  32. private final long workerIdShift = sequenceBits;
  33. /**
  34. * 数据标识id向左移17位(12+5)
  35. */
  36. private final long datacenterIdShift = sequenceBits + workerIdBits;
  37. /**
  38. * 时间截向左移22位(5+5+12)
  39. */
  40. private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
  41. /**
  42. * 生成序列的掩码,这里为4095 (0b111111111111=0xfff=4095)
  43. */
  44. private final long sequenceMask = -1L ^ (-1L << sequenceBits);
  45. /**
  46. * 工作机器ID(0~31)
  47. */
  48. private long workerId;
  49. /**
  50. * 数据中心ID(0~31)
  51. */
  52. private long datacenterId;
  53. /**
  54. * 毫秒内序列(0~4095)
  55. */
  56. private long sequence = 0L;
  57. /**
  58. * 上次生成ID的时间截
  59. */
  60. private long lastTimestamp = -1L;
  61. public Test(long workerId, long datacenterId) {
  62. if (workerId > maxWorkerId || workerId < 0) {
  63. throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
  64. }
  65. if (datacenterId > maxDatacenterId || datacenterId < 0) {
  66. throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
  67. }
  68. this.workerId = workerId;
  69. this.datacenterId = datacenterId;
  70. }
  71. /**
  72. * 获得下一个ID (该方法是线程安全的)
  73. *
  74. * @return SnowflakeId
  75. */
  76. public synchronized long nextId() {
  77. long timestamp = timeGen();
  78. //如果当前时间小于上一次ID生成的时间戳,说明系统时钟回退过这个时候应当抛出异常
  79. if (timestamp < lastTimestamp) {
  80. throw new RuntimeException(
  81. String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
  82. }
  83. //如果是同一时间生成的,则进行毫秒内序列
  84. if (lastTimestamp == timestamp) {
  85. sequence = (sequence + 1) & sequenceMask;
  86. //毫秒内序列溢出
  87. if (sequence == 0) {
  88. //阻塞到下一个毫秒,获得新的时间戳
  89. timestamp = tilNextMillis(lastTimestamp);
  90. }
  91. }
  92. //时间戳改变,毫秒内序列重置
  93. else {
  94. sequence = 0L;
  95. }
  96. //上次生成ID的时间截
  97. lastTimestamp = timestamp;
  98. //移位并通过或运算拼到一起组成64位的ID
  99. return ((timestamp - twepoch) << timestampLeftShift) //
  100. | (datacenterId << datacenterIdShift) //
  101. | (workerId << workerIdShift) //
  102. | sequence;
  103. }
  104. /**
  105. * 阻塞到下一个毫秒,直到获得新的时间戳
  106. *
  107. * @param lastTimestamp 上次生成ID的时间截
  108. * @return 当前时间戳
  109. */
  110. protected long tilNextMillis(long lastTimestamp) {
  111. long timestamp = timeGen();
  112. while (timestamp <= lastTimestamp) {
  113. timestamp = timeGen();
  114. }
  115. return timestamp;
  116. }
  117. /**
  118. * 返回以毫秒为单位的当前时间
  119. *
  120. * @return 当前时间(毫秒)
  121. */
  122. protected long timeGen() {
  123. return System.currentTimeMillis();
  124. }
  125. public static void parseId(long id) {
  126. long miliSecond = id >>> 22;
  127. long shardId = (id & (0xFFF << 10)) >> 10;
  128. System.err.println("分布式id-"+id+"生成的时间是:"+new SimpleDateFormat("yyyy-MM-dd").format(new Date(miliSecond)));
  129. }
  130. public static void main(String[] args) {
  131. Test idWorker = new Test(0, 0);
  132. for (int i = 0; i < 10; i++) {
  133. long id = idWorker.nextId();
  134. System.out.println(id);
  135. parseId(id);
  136. }
  137. }
  138. }

执行结果如下所示,此时我们可以看到,不仅可以可以把分布式id给创建处理,而且可以把这个创建的时间也打印出来,此时就可以满足我们的分布式id的创建了

  1. 6566884785623400448
  2. 分布式id-6566884785623400448生成的时间是:2019-08-13
  3. 6566884785812144128
  4. 分布式id-6566884785812144128生成的时间是:2019-08-13
  5. 6566884785812144129
  6. 分布式id-6566884785812144129生成的时间是:2019-08-13
  7. 6566884785812144130
  8. 分布式id-6566884785812144130生成的时间是:2019-08-13
  9. 6566884785812144131
  10. 分布式id-6566884785812144131生成的时间是:2019-08-13
  11. 6566884785812144132
  12. 分布式id-6566884785812144132生成的时间是:2019-08-13
  13. 6566884785816338432
  14. 分布式id-6566884785816338432生成的时间是:2019-08-13
  15. 6566884785816338433
  16. 分布式id-6566884785816338433生成的时间是:2019-08-13
  17. 6566884785816338434
  18. 分布式id-6566884785816338434生成的时间是:2019-08-13
  19. 6566884785816338435
  20. 分布式id-6566884785816338435生成的时间是:2019-08-13

缩小版Snowflake算法生成分布式id

因为Snowflake算法的极限是每毫秒的每一个节点生成4059个id值,也就是说每毫秒的极限是生成023*4059=4 152 357个id值,这样生成id值的速度对于twitter公司来说是很符合标准的(毕竟人家公司大嘛),但是对于咱们中小公司来说是不需要的,所以我们可以根据Snowflake算法来修改一下分布式id的创建,让每秒创建的id少一些,但是把可以使用的时间扩大一些

这里我看廖雪峰老师的文章之后,采用了53位作为分布式id值的位数,因为如果后端和前端的JavaScript打交道的话,由于JavaScript支持的最大整型就是53位,超过这个位数,JavaScript将丢失精度。因此,使用53位整数可以直接由JavaScript读取,而超过53位时,就必须转换成字符串才能保证JavaScript处理正确,所以我们的分布式id就用53位来生成

这53位里面,第一位还是0,然后剩下的52位,33位作为秒数,4位作为节点数,15位作为每一个节点在每一秒的生成序列值

33位的二进制111111111111111111111111111111111转换成10进制的秒就是8589934591,然后我们把 8589934591转换成时间就是2242-03-16,也就是说可以用220年的,足够我们的使用了

然后4位节点,所以最多就是4位的1111,也就是最多可以支持15个节点,

然后15位表示每一个节点每一秒自增序列值,这里最多就是10位的11111111111111111,也就是说每一个节点可以每一秒可以最多生成131071个不重复id值

这样算起来,就是说每一秒每一个节点生成131071个不重复的节点,所以极限就是每秒生成15*131071=1 966 065个分布式id,够我们在开发里面的日常使用了

所以代码就可以变成下面这样,这里主要讲一下下面的nextId()方法,

首先蓝色代码是获取当前秒,然后进行校验,就是把当前时间和上一个时间戳进行比较,如果当前时间比上一个时间戳要小,那就说明系统时钟回退,所以此时应该抛出异常

然后是下面的红色代码,首先如果是同一秒生成的,那么就把这一秒的生成序列id值一直增加,一直增加到131071个,如果在增加,那么下面的红色代码里面的sequence = (sequence + 1) & sequenceMask;的值就会是0,那么就会执行红色代码里面的tilNextMillis()方法进行阻塞,直到获取到下一秒继续执行

然后下面的绿色代码表示每一秒过去之后,都要把这个生成序列的id值都变成0,这样在新的一秒里面就可以在继续生成1到131071个分布式id值了

然后下面的黄色代码就是把咱们的秒,节点值,节点每秒生成序列id值加起来组成一个分布式id返回

  1. package com.hello;
  2. import java.text.SimpleDateFormat;
  3. import java.util.Date;
  4. public class Test {
  5. /**
  6. * 开始时间截 (1970-01-01)
  7. */
  8. private final long twepoch = 0L;
  9. /**
  10. * 机器id,范围是1到15
  11. */
  12. private final long workerId;
  13. /**
  14. * 机器id所占的位数,占4位
  15. */
  16. private final long workerIdBits = 4L;
  17. /**
  18. * 支持的最大机器id,结果是15
  19. */
  20. private final long maxWorkerId = ~(-1L << workerIdBits);
  21. /**
  22. * 生成序列占的位数
  23. */
  24. private final long sequenceBits = 15L;
  25. /**
  26. * 机器ID向左移15位
  27. */
  28. private final long workerIdShift = sequenceBits;
  29. /**
  30. * 生成序列的掩码,这里为最大是32767 (1111111111111=32767)
  31. */
  32. private final long sequenceMask = ~(-1L << sequenceBits);
  33. /**
  34. * 时间截向左移19位(4+15)
  35. */
  36. private final long timestampLeftShift = 19L;
  37. /**
  38. * 秒内序列(0~32767)
  39. */
  40. private long sequence = 0L;
  41. /**
  42. * 上次生成ID的时间截
  43. */
  44. private long lastTimestamp = -1L;
  45. public Test(long workerId) {
  46. if (workerId > maxWorkerId || workerId < 0) {
  47. throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
  48. }
  49. this.workerId = workerId;
  50. }
  51. /**
  52. * 获得下一个ID (该方法是线程安全的)
  53. *
  54. * @return SnowflakeId
  55. */
  56. public synchronized long nextId() {
  57. //蓝色代码注释开始
  58. long timestamp = timeGen();
  59. //如果当前时间小于上一次ID生成的时间戳,说明系统时钟回退过这个时候应当抛出异常
  60. if (timestamp < lastTimestamp) {
  61. throw new RuntimeException(
  62. String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
  63. }
  64. //蓝色代码注释结束
  65. //红色代码注释开始
  66. //如果是同一时间生成的,则进行秒内序列
  67. if (lastTimestamp == timestamp) {
  68. sequence = (sequence + 1) & sequenceMask;
  69. //秒内序列溢出
  70. if (sequence == 0) {
  71. //阻塞到下一个秒,获得新的秒值
  72. timestamp = tilNextMillis(lastTimestamp);
  73. }
  74. //时间戳改变,秒内序列重置
  75. }
  76. //红色代码注释结束
  77. //绿色代码注释开始
  78. else {
  79. sequence = 0L;
  80. }
  81. //绿色代码注释结束
  82. //上次生成ID的时间截
  83. lastTimestamp = timestamp;
  84. //黄色代码注释开始
  85. //移位并通过或运算拼到一起组成53 位的ID
  86. return ((timestamp - twepoch) << timestampLeftShift)
  87. | (workerId << workerIdShift)
  88. | sequence;
  89. //黄色代码注释结束
  90. }
  91. /**
  92. * 阻塞到下一个秒,直到获得新的时间戳
  93. *
  94. * @param lastTimestamp 上次生成ID的时间截
  95. * @return 当前时间戳
  96. */
  97. protected long tilNextMillis(long lastTimestamp) {
  98. long timestamp = timeGen();
  99. while (timestamp <= lastTimestamp) {
  100. timestamp = timeGen();
  101. }
  102. return timestamp;
  103. }
  104. /**
  105. * 返回以秒为单位的当前时间
  106. *
  107. * @return 当前时间(秒)
  108. */
  109. protected long timeGen() {
  110. return System.currentTimeMillis()/1000L;
  111. }
  112. public static void parseId(long id) {
  113. long second = id >>> 19;
  114. System.err.println("分布式id-"+id+"生成的时间是:"+new SimpleDateFormat("yyyy-MM-dd").format(new Date(second*1000)));
  115. }
  116. public static void main(String[] args) {
  117. Test idWorker = new Test(0);
  118. for (int i = 0; i < 10; i++) {
  119. long id = idWorker.nextId();
  120. System.out.println(id);
  121. parseId(id);
  122. }
  123. }
  124. }

此时结果如下所示,都是ok的,؏؏☝ᖗ乛◡乛ᖘ☝؏؏

  1. 820870564020224
  2. 分布式id-820870564020224生成的时间是:2019-08-13
  3. 820870564020225
  4. 分布式id-820870564020225生成的时间是:2019-08-13
  5. 820870564020226
  6. 分布式id-820870564020226生成的时间是:2019-08-13
  7. 820870564020227
  8. 分布式id-820870564020227生成的时间是:2019-08-13
  9. 820870564020228
  10. 分布式id-820870564020228生成的时间是:2019-08-13
  11. 820870564020229
  12. 分布式id-820870564020229生成的时间是:2019-08-13
  13. 820870564020230
  14. 分布式id-820870564020230生成的时间是:2019-08-13
  15. 820870564020231
  16. 分布式id-820870564020231生成的时间是:2019-08-13
  17. 820870564020232
  18. 分布式id-820870564020232生成的时间是:2019-08-13
  19. 820870564020233
  20. 分布式id-820870564020233生成的时间是:2019-08-13

时间回拨问题的解决

这里找了好多,终于找出来两个方法:想看的点击这个链接吧:分布式ID系列(5)——Twitter的雪法算法Snowflake适合做分布式ID吗

雪法算法Snowflake适合做分布式ID吗

根据一系列的分布式id讲解,雪法算法Snowflake是目前网上最适合做分布式Id的了,大家如果想用的话,可以根据我上面的缩小版的Snowflake算法来作为我们开发中的使用。؏؏☝ᖗ乛◡乛ᖘ☝؏؏

原文链接

其他分布式ID系列快捷键:

分布式ID系列(1)——为什么需要分布式ID以及分布式ID的业务需求

分布式ID系列(2)——UUID适合做分布式ID吗

分布式ID系列(3)——数据库自增ID机制适合做分布式ID吗

分布式ID系列(4)——Redis集群实现的分布式ID适合做分布式ID吗

分布式ID系列(5)——Twitter的雪法算法Snowflake适合做分布式ID吗

分布式ID系列(5)——Twitter的雪法算法Snowflake适合做分布式ID吗的更多相关文章

  1. 分布式ID系列(2)——UUID适合做分布式ID吗

    UUID的生成策略: UUID的方式能生成一串唯一随机32位长度数据,它是无序的一串数据,按照开放软件基金会(OSF)制定的标准计算,UUID的生成用到了以太网卡地址.纳秒级时间.芯片ID码和许多可能 ...

  2. 分布式ID系列(3)——数据库自增ID机制适合做分布式ID吗

    数据库自增ID机制原理介绍 在分布式里面,数据库的自增ID机制的主要原理是:数据库自增ID和mysql数据库的replace_into()函数实现的.这里的replace数据库自增ID和mysql数据 ...

  3. 分布式ID系列(4)——Redis集群实现的分布式ID适合做分布式ID吗

    首先是项目地址: https://github.com/maqiankun/distributed-id-redis-generator 关于Redis集群生成分布式ID,这里要先了解redis使用l ...

  4. Twitter的分布式自增ID算法snowflake (Java版)

    概述 分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的. 有些时候我们希望能使用一种 ...

  5. Twitter分布式自增ID算法snowflake原理解析

    以JAVA为例 Twitter分布式自增ID算法snowflake,生成的是Long类型的id,一个Long类型占8个字节,每个字节占8比特,也就是说一个Long类型占64个比特(0和1). 那么一个 ...

  6. Twitter的分布式自增ID算法snowflake(雪花算法) - C#版

    概述 分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的.有些时候我们希望能使用一种简 ...

  7. Twitter分布式自增ID算法snowflake原理解析(Long类型)

    Twitter分布式自增ID算法snowflake,生成的是Long类型的id,一个Long类型占8个字节,每个字节占8比特,也就是说一个Long类型占64个比特(0和1). 那么一个Long类型的6 ...

  8. 详解Twitter开源分布式自增ID算法snowflake(附演算验证过程)

    详解Twitter开源分布式自增ID算法snowflake,附演算验证过程 2017年01月22日 14:44:40 url: http://blog.csdn.net/li396864285/art ...

  9. 分布式ID系列之为什么需要分布式ID以及生成分布式ID的业务需求

    为什么需要分布式id生成系统 在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识.如在美团点评的金融.支付.餐饮.酒店.猫眼电影等产品的系统中,数据日渐增长,对数据分库分表后需要有一个唯一ID ...

随机推荐

  1. Oracle数据库----函数

    --大小写控制函数--upperselect * from emp where job = upper('salesman'); --lowerselect * from emp where lowe ...

  2. VS2010 winform开发笔记---combox的SelectedIndexChanged事件及级联问题

    DisplayMember绑定需要显示的数据表字段, 而ValueMember绑定需要获取选择的项的值. 然后通过 combo.SelectedValue就可以取得选中项的值了. DisplayMem ...

  3. springboot快速入门02--Controller编写和测试

    02springboot快速入门--Controller编写和测试 1.新建一个HelloController import org.springframework.boot.SpringApplic ...

  4. Ubuntu搭建hugo博客

    自己搭建了一个博客用hugo,后因自己搭建的博客上传文章,搞一些东西不方便,就创建了现在这个博客,不过还是把如何搭建hugo的过程记录以下. Ubuntu下的操作 1. 下载Git 打开终端 Ctrl ...

  5. STM32-I2C_CheckEvent-标志位自动清除理解

    STM32里I2C_CheckEvent函数我们应该是相当熟悉了,在每次发送数据后我们都需要检验相应的EVx(x = 0,1,2,,,)事件是否有发送. 函数定义如下: ErrorStatus I2C ...

  6. Excel催化剂开源第6波-Clickonce部署之自动升级瘦身之术

    Clickonce无痛自动更新是我最喜欢使用VSTO开发并Clickonce部署的特性之一,但这个自动更新,通常会更新整个程序文件,包含所有的引用dll和一些资源文件等. 一般来说,我们更新的都是主程 ...

  7. 微信小程序post 服务端无法获得参数问题

    header中需要改为 "Content-Type": "application/x-www-form-urlencoded"

  8. [leetcode] #112 Path Sum (easy)

    原题链接 题意: 给定一个值,求出从树顶到某个叶(没有子节点)有没有一条路径等于该值. 思路: DFS Runtime: 4 ms, faster than 100.00% of C++ class ...

  9. 微信小程序开发--页面之间的跳转

    一.navigator--完成页面之间的跳转 1.新建一个页面文件夹 2.在app.json文件中引入页面 "pages": [ "pages/index/index&q ...

  10. sqlserver2014创建数据库时,错误提示如下:尝试打开或创建物理‘c:\数据库\db.mdf’时,Create File遇到操作系统错误5(拒绝访问)

    CREATE DATABASE test1   ON  PRIMARY ( NAME =test1, FILENAME='C:\Program Files\test1.mdf',SIZE=10240K ...