SnowFlake 雪花算法和原理(分布式 id 生成算法)

简介: SnowFlake 雪花算法和原理(分布式 id 生成算法)

一、概述

SnowFlake 算法:是 Twitter 开源的分布式 id 生成算法。

核心思想:使用一个 64 bit 的 long 型的数字作为全局唯一 id。

image.gif编辑

算法原理

    • 最高位是符号位,始终为0,不可用。
      • 41位的时间序列,精确到毫秒级,41位的长度可以使用69年。时间位还有一个很重要的作用是可以根据时间进行排序。
        • 10位的机器标识,10位的长度最多支持部署1024个节点
          • 12位的计数序列号,序列号即一系列的自增id,可以支持同一节点同一毫秒生成多个ID序号,12位的计数序列号支持每个节点每毫秒产生4096个ID序号

          算法优缺点

          优点

            • 高并发分布式环境下生成不重复 id,每秒可生成百万个不重复 id。
              • 基于时间戳,以及同一时间戳下序列号自增,基本保证 id 有序递增。
                • 不依赖第三方库或者中间件。
                  • 算法简单,在内存中进行,效率高。

                  缺点

                  依赖服务器时间,服务器时钟回拨时可能会生成重复 id。算法中可通过记录最后一个生成 id 时的时间戳来解决,每次生成 id 之前比较当前服务器时钟是否被回拨,避免生成重复 id。

                  二、算法实现

                  <dependency>
                  <groupId>cn.hutool</groupId>
                  <artifactId>hutool-all</artifactId>
                  <version>5.8.11</version>
                  </dependency>

                  image.gif

                  public class IdWorker {
                      //下面两个每个5位,加起来就是10位的工作机器id
                      private long workerId;    //工作id
                      private long datacenterId;   //数据id
                      //12位的序列号
                      private long sequence;
                      public IdWorker(long workerId, long datacenterId, long sequence) {
                          // sanity check for workerId
                          if (workerId > maxWorkerId || workerId < 0) {
                              throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
                          }
                          if (datacenterId > maxDatacenterId || datacenterId < 0) {
                              throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
                          }
                          System.out.printf("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
                                  timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);
                          this.workerId = workerId;
                          this.datacenterId = datacenterId;
                          this.sequence = sequence;
                      }
                      //初始时间戳
                      private long twepoch = 1288834974657L;
                      //长度为5位
                      private long workerIdBits = 5L;
                      private long datacenterIdBits = 5L;
                      //最大值
                      private long maxWorkerId = -1L ^ (-1L << workerIdBits);
                      private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
                      //序列号id长度
                      private long sequenceBits = 12L;
                      //序列号最大值
                      private long sequenceMask = -1L ^ (-1L << sequenceBits);
                      //工作id需要左移的位数,12位
                      private long workerIdShift = sequenceBits;
                      //数据id需要左移位数 12+5=17位
                      private long datacenterIdShift = sequenceBits + workerIdBits;
                      //时间戳需要左移位数 12+5+5=22位
                      private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
                      //上次时间戳,初始值为负数
                      private long lastTimestamp = -1L;
                      public long getWorkerId() {
                          return workerId;
                      }
                      public long getDatacenterId() {
                          return datacenterId;
                      }
                      public long getTimestamp() {
                          return System.currentTimeMillis();
                      }
                      //下一个ID生成算法
                      public synchronized long nextId() {
                          long timestamp = timeGen();
                          //获取当前时间戳如果小于上次时间戳,则表示时间戳获取出现异常
                          if (timestamp < lastTimestamp) {
                              System.err.printf("clock is moving backwards.  Rejecting requests until %d.", lastTimestamp);
                              throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds",
                                      lastTimestamp - timestamp));
                          }
                          //获取当前时间戳如果等于上次时间戳(同一毫秒内),则在序列号加一;否则序列号赋值为0,从0开始。
                          if (lastTimestamp == timestamp) {
                              sequence = (sequence + 1) & sequenceMask;
                              if (sequence == 0) {
                                  timestamp = tilNextMillis(lastTimestamp);
                              }
                          } else {
                              sequence = 0;
                          }
                          //将上次时间戳值刷新
                          lastTimestamp = timestamp;
                          /**
                           * 返回结果:
                           * (timestamp - twepoch) << timestampLeftShift) 表示将时间戳减去初始时间戳,再左移相应位数
                           * (datacenterId << datacenterIdShift) 表示将数据id左移相应位数
                           * (workerId << workerIdShift) 表示将工作id左移相应位数
                           * | 是按位或运算符,例如:x | y,只有当x,y都为0的时候结果才为0,其它情况结果都为1。
                           * 因为个部分只有相应位上的值有意义,其它位上都是0,所以将各部分的值进行 | 运算就能得到最终拼接好的id
                           */
                          return ((timestamp - twepoch) << timestampLeftShift) |
                                  (datacenterId << datacenterIdShift) |
                                  (workerId << workerIdShift) |
                                  sequence;
                      }
                      //获取时间戳,并与上次时间戳比较
                      private long tilNextMillis(long lastTimestamp) {
                          long timestamp = timeGen();
                          while (timestamp <= lastTimestamp) {
                              timestamp = timeGen();
                          }
                          return timestamp;
                      }
                      //获取系统时间戳
                      private long timeGen() {
                          return System.currentTimeMillis();
                      }
                      //---------------测试---------------
                      public static void main(String[] args) {
                          IdWorker worker = new IdWorker(1, 1, 1);
                          for (int i = 0; i < 30; i++) {
                              System.out.println(worker.nextId());
                          }
                      }
                  }

                  image.gif

                  解决时间回拨问题

                  原生的 Snowflake 算法是完全依赖于时间的,如果有时钟回拨的情况发生,会生成重复的 ID,市场上的解决方案也是不少。简单粗暴的办法有:

                    • 最简单的方案,就是关闭生成唯一 ID 机器的时间同步。
                      • 使用阿里云的的时间服务器进行同步,2017 年 1 月 1 日的闰秒调整,阿里云服务器 NTP 系统 24 小时“消化”闰秒,完美解决了问题。
                        • 如果发现有时钟回拨,时间很短比如 5 毫秒,就等待,然后再生成。或者就直接报错,交给业务层去处理。也可以采用 SonyFlake 的方案,精确到 10 毫秒,以 10 毫秒为分配单元。

                        twitter的雪花算法:GitHub - twitter-archive/snowflake: Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees.

                        其它全局唯一的分布式ID的方式:如百度的uid-generator美团的Leaf滴滴的TinyId



                        文章下方有交流学习区!一起学习进步!也可以前往官网,加入官方微信交流群你的支持和鼓励是我创作的动力❗❗❗

                        官网:Doker 多克; 官方旗舰店:首页-Doker 多克 多克创新科技企业店-淘宝网 全品优惠

                        目录
                        相关文章
                        |
                        12天前
                        |
                        算法 容器
                        令牌桶算法原理及实现,图文详解
                        本文介绍令牌桶算法,一种常用的限流策略,通过恒定速率放入令牌,控制高并发场景下的流量,确保系统稳定运行。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
                        令牌桶算法原理及实现,图文详解
                        |
                        8天前
                        |
                        算法 关系型数据库 MySQL
                        分布式唯一ID生成:深入理解Snowflake算法在Go中的实现
                        在分布式系统中,确保每个节点生成的 ID 唯一且高效至关重要。Snowflake 算法由 Twitter 开发,通过 64 位 long 型数字生成全局唯一 ID,包括 1 位标识位、41 位时间戳、10 位机器 ID 和 12 位序列号。该算法具备全局唯一性、递增性、高可用性和高性能,适用于高并发场景,如电商促销时的大量订单生成。本文介绍了使用 Go 语言的 `bwmarrin/snowflake` 和 `sony/sonyflake` 库实现 Snowflake 算法的方法。
                        20 1
                        分布式唯一ID生成:深入理解Snowflake算法在Go中的实现
                        |
                        21天前
                        |
                        负载均衡 算法 应用服务中间件
                        5大负载均衡算法及原理,图解易懂!
                        本文详细介绍负载均衡的5大核心算法:轮询、加权轮询、随机、最少连接和源地址散列,帮助你深入理解分布式架构中的关键技术。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
                        5大负载均衡算法及原理,图解易懂!
                        |
                        22天前
                        |
                        NoSQL 算法 关系型数据库
                        分布式 ID 详解 ( 5大分布式 ID 生成方案 )
                        本文详解分布式全局唯一ID及其5种实现方案,关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
                        分布式 ID 详解 ( 5大分布式 ID 生成方案 )
                        |
                        20天前
                        |
                        分布式计算 Java 开发工具
                        阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
                        本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
                        |
                        27天前
                        |
                        算法 数据库 索引
                        HyperLogLog算法的原理是什么
                        【10月更文挑战第19天】HyperLogLog算法的原理是什么
                        42 1
                        |
                        1月前
                        |
                        NoSQL Java Redis
                        太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
                        Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
                        太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
                        |
                        3月前
                        |
                        NoSQL Redis
                        基于Redis的高可用分布式锁——RedLock
                        这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
                        112 2
                        基于Redis的高可用分布式锁——RedLock
                        |
                        3月前
                        |
                        缓存 NoSQL Java
                        SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
                        这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
                        SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
                        |
                        11天前
                        |
                        NoSQL Redis
                        Redis分布式锁如何实现 ?
                        Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
                        47 16