全局惟一iD的生成雪花算法详解及其余用法

时间 2020-05-12

标签全局惟一生成雪花算法详解其余用法繁體版

原文原文链接

1、介绍

雪花算法的原始版本是scala版，用于生成分布式ID（纯数字，时间顺序）,订单编号等。html

自增ID：对于数据敏感场景不宜使用，且不适合于分布式场景。
GUID：采用无心义字符串，数据量增大时形成访问过慢，且不宜排序。java

1git

1bit，不用，由于二进制中最高位是符号位，1表示负数，0表示正数。生成的id通常都是用整数，因此最高位固定为0。github
41bit-时间戳，用来记录时间戳，毫秒级。
- 41位能够表示 $2^{41}-1$ 个数字，
- 若是只用来表示正整数（计算机中正数包含0），能够表示的数值范围是：0 至 $2^{41}-1$ ，减1是由于可表示的数值范围是从0开始算的，而不是1。
- 也就是说41位能够表示 $2^{41}-1$ 个毫秒的值，转化成单位年则是 $(2^{41}-1) / (1000 * 60 * 60 * 24 *365) = 69$ 年算法
10bit-工做机器id，用来记录工做机器id。
- 能够部署在 $2^{10} = 1024$ 个节点，包括5位datacenterId和5位workerId
- 5位（bit）能够表示的最大正整数是 $2^{5}-1 = 31$ ，便可以用0、一、二、三、....31这32个数字，来表示不一样的datecenterId或workerIdspring
12bit-序列号，序列号，用来记录同毫秒内产生的不一样id。
- 12位（bit）能够表示的最大正整数是 $2^{12}-1 = 4095$ ，便可以用0、一、二、三、....4094这4095个数字，来表示同一机器同一时间截（毫秒)内产生的4095个ID序号。docker

因为在Java中64bit的整数是long类型，因此在Java中SnowFlake算法生成的id就是long来存储的。数据库

SnowFlake能够保证：apache

全部生成的id按时间趋势递增

整个分布式系统内不会产生重复id（由于有datacenterId和workerId来作区分）

2、使用建议

一、改进

其实雪花算法就是把id按位打散，而后再分红上面这几块，用位来表示状态，这其实就是一种思想。
因此我们实际在用的时候，也没必要非得按照上面这种分割，只需保证总位数在64位便可安全

若是你的业务不须要69年这么长，或者须要更长时间
用42位存储时间戳，(1L << 42) / (1000L * 60 * 60 * 24 * 365) = 139年
用41位存储时间戳，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
用40位存储时间戳，(1L << 40) / (1000L * 60 * 60 * 24 * 365) = 34年
用39位存储时间戳，(1L << 39) / (1000L * 60 * 60 * 24 * 365) = 17年
用38位存储时间戳，(1L << 38) / (1000L * 60 * 60 * 24 * 365) = 8年
用37位存储时间戳，(1L << 37) / (1000L * 60 * 60 * 24 * 365) = 4年

若是你的机器没有那么1024个这么多，或者比1024还多
用7位存储机器id，(1L << 7) = 128
用8位存储机器id，(1L << 8) = 256
用9位存储机器id，(1L << 9) = 512
用10位存储机器id，(1L << 10) = 1024
用11位存储机器id，(1L << 11) = 2048
用12位存储机器id，(1L << 12) = 4096
用13位存储机器id，(1L << 13) = 8192

若是你的业务，每一个机器，每毫秒最多也不会4096个id要生成，或者比这个还多
用8位存储随机序列，(1L << 8) = 256
用9位存储随机序列，(1L << 9) = 512
用10位存储随机序列，(1L << 10) = 1024
用11位存储随机序列，(1L << 11) = 2048
用12位存储随机序列，(1L << 12) = 4096
用13位存储随机序列，(1L << 13) = 8192
用14位存储随机序列，(1L << 14) = 16384
用15位存储随机序列，(1L << 15) = 32768
注意，随机序列建议不要太大，通常业务，每毫秒要是能产生这么多id，建议在机器id上增长位

若是你的业务量很小，好比通常状况下每毫秒生成不到1个id，此时能够将随机序列设置成随机开始自增
好比从0到48随机开始自增，算是一种优化建议

若是你有多个业务，也能够拿出来几位来表示业务，好比用最后4位，支持16种业务的区分

若是你的业务特别复杂，能够考虑128位存储，不过这样的话，也能够考虑使用uuid了，但uuid无序，这个有序

若是你的业务很简单，甚至能够考虑32位存储，时间戳改为秒为单位…

二、总结：

合理的根据本身的实际状况去设计各个惟一条件的组合，雪花算法只是提供了一种相对合理的方式。
雪花算法这种用位来表示状态的，咱们还能够用在其余方面，好比数据库存储，能够用更小的空间去表示不一样的状态位
包括各类底层的好比序列化，也是有用到拆解位，充分利用存储

3、算法实现

/** * Twitter_Snowflake<br> * SnowFlake的结构以下(每部分用-分开):<br> * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br> * 1位标识，因为long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，因此id通常是正数，最高位是0<br> * 41位时间截(毫秒级)，注意，41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截) * 获得的值），这里的的开始时间截，通常是咱们的id生成器开始使用的时间，由咱们程序来指定的（以下下面程序IdWorker类的startTime属性）。41位的时间截，可使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br> * 10位的数据机器位，能够部署在1024个节点，包括5位datacenterId和5位workerId<br> * 12位序列，毫秒内的计数，12位的计数顺序号支持每一个节点每毫秒(同一机器，同一时间截)产生4096个ID序号<br> * 加起来恰好64位，为一个Long型。<br> * SnowFlake的优势是，总体上按照时间自增排序，而且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID做区分)，而且效率较高，经测试，SnowFlake每秒可以产生26万ID左右。 */
public class SnowflakeIdWorker { // ==============================Fields===========================================
    /** * 开始时间截 (2015-01-01) */
    private final long twepoch = 1420041600000L; /** * 机器id所占的位数 */
    private final long workerIdBits = 5L; /** * 数据标识id所占的位数 */
    private final long datacenterIdBits = 5L; /** * 支持的最大机器id，结果是31 (这个移位算法能够很快的计算出几位二进制数所能表示的最大十进制数) */
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits); /** * 支持的最大数据标识id，结果是31 */
    private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); /** * 序列在id中占的位数 */
    private final long sequenceBits = 12L; /** * 机器ID向左移12位 */
    private final long workerIdShift = sequenceBits; /** * 数据标识id向左移17位(12+5) */
    private final long datacenterIdShift = sequenceBits + workerIdBits; /** * 时间截向左移22位(5+5+12) */
    private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; /** * 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095) */
    private final long sequenceMask = -1L ^ (-1L << sequenceBits); /** * 工做机器ID(0~31) */
    private long workerId; /** * 数据中心ID(0~31) */
    private long datacenterId; /** * 毫秒内序列(0~4095) */
    private long sequence = 0L; /** * 上次生成ID的时间截 */
    private long lastTimestamp = -1L; //==============================Constructors=====================================

    /** * 构造函数 * * @param workerId 工做ID (0~31) * @param datacenterId 数据中心ID (0~31) */
    public SnowflakeIdWorker(long workerId, long datacenterId) { 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)); } this.workerId = workerId; this.datacenterId = datacenterId; } // ==============================Methods==========================================

    /** * 得到下一个ID (该方法是线程安全的) * * @return SnowflakeId */
    public synchronized long nextId() { long timestamp = timeGen(); //若是当前时间小于上一次ID生成的时间戳，说明系统时钟回退过这个时候应当抛出异常
        if (timestamp < lastTimestamp) { throw new RuntimeException( String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp)); } //若是是同一时间生成的，则进行毫秒内序列
        if (lastTimestamp == timestamp) { sequence = (sequence + 1) & sequenceMask; //毫秒内序列溢出
            if (sequence == 0) { //阻塞到下一个毫秒,得到新的时间戳
                timestamp = tilNextMillis(lastTimestamp); } } //时间戳改变，毫秒内序列重置
        else { sequence = 0L; } //上次生成ID的时间截
        lastTimestamp = timestamp; //移位并经过或运算拼到一块儿组成64位的ID
        return ((timestamp - twepoch) << timestampLeftShift) //                 | (datacenterId << datacenterIdShift) //                 | (workerId << workerIdShift) //                 | sequence; } /** * 阻塞到下一个毫秒，直到得到新的时间戳 * * @param lastTimestamp 上次生成ID的时间截 * @return 当前时间戳 */
    protected long tilNextMillis(long lastTimestamp) { long timestamp = timeGen(); while (timestamp <= lastTimestamp) { timestamp = timeGen(); } return timestamp; } /** * 返回以毫秒为单位的当前时间 * * @return 当前时间(毫秒) */
    protected long timeGen() { return System.currentTimeMillis(); } //==============================Test=============================================

    /** * 测试 */
    public static void main(String[] args) { long start = System.currentTimeMillis(); SnowflakeIdWorker idWorker = new SnowflakeIdWorker(1, 3); for (int i = 0; i < 50; i++) { long id = idWorker.nextId(); System.out.println(Long.toBinaryString(id)); System.out.println(id); } long end = System.currentTimeMillis(); System.out.println(end - start); } }

源码实现

可能的输出

长度：60 value：100001101111110101000011111010101010110101001010000000001000
         长度：18 value：607937840337428488
         25

4、优化

 1 import org.apache.commons.lang3.RandomUtils;  2 import org.apache.commons.lang3.StringUtils;  3 import org.apache.commons.lang3.SystemUtils;  4 import org.apache.logging.log4j.Logger;  5 import org.apache.logging.log4j.LogManager;  6 import org.springframework.beans.factory.annotation.Value;  7 import org.springframework.context.annotation.Bean;  8 import org.springframework.context.annotation.Configuration;  9 import org.springframework.context.annotation.Primary; 10 import spring.cloud.common.util.id.SnowflakeIdWorker; 11 import java.net.Inet4Address; 12 import java.net.UnknownHostException; 13  
14 /**
15  * 网上的教程通常存在两个问题： 16  * 1. 机器ID（5位）和数据中心ID（5位）配置没有解决，分布式部署的时候会使用相同的配置，任然有ID重复的风险。 17  * 2. 使用的时候须要实例化对象，没有造成开箱即用的工具类。 18  * 19  * 本文针对上面两个问题进行解决，笔者的解决方案是，workId使用服务器hostName生成， 20  * dataCenterId使用IP生成，这样能够最大限度防止10位机器码重复，可是因为两个ID都不能超过32， 21  * 只能取余数，仍是不免产生重复，可是实际使用中，hostName和IP的配置通常连续或相近， 22  * 只要不是恰好相隔32位，就不会有问题，何况，hostName和IP同时相隔32的状况更加是几乎不可能 23  * 的事，平时作的分布式部署，通常也不会超过10台容器。使用上面的方法能够零配置使用雪花算法， 24  * 雪花算法10位机器码的设定理论上能够有1024个节点，生产上使用docker配置通常是一次编译， 25  * 而后分布式部署到不一样容器，不会有不一样的配置，这里不知道其余公司是如何解决的，即便有方法 26  * 使用一套配置，而后运行时根据不一样容器读取不一样的配置，可是给每一个容器编配ID，1024个 27  * （大部分状况下没有这么多），彷佛也不太可能，此问题留待往后解决后再行补充。 28  */
29 @Configuration 30 public class IdWorkerConfiguration { 31     Logger logger = LogManager.getLogger(); 32  
33     @Value("${id.work:noWorkId}") 34     private String workId; 35     @Value("${id.dateSource:noDateSource}") 36     private String dateSource; 37  @Bean 38  @Primary 39     public SnowflakeIdWorker idWorker(){ 40         return new SnowflakeIdWorker(getWorkFromConfig(),getDateFromConfig()); 41  } 42  
43     private Long getWorkFromConfig() { 44         if ("noWorkId".equals(workId)) { 45             return getWorkId(); 46         } else { 47             //将workId转换为Long
48             return 2L; 49  } 50  } 51  
52     private Long getDateFromConfig() { 53         if ("noDateSource".equals(dateSource)) { 54             return getDataCenterId(); 55         } else { 56             //将workId转换为Long
57             return 2L; 58  } 59  } 60  
61     private Long getWorkId(){ 62         try { 63             String hostAddress = Inet4Address.getLocalHost().getHostAddress(); 64             int[] ints = StringUtils.toCodePoints(hostAddress); 65             int sums = 0; 66             for(int b : ints){ 67                 sums += b; 68  } 69             return (long)(sums % 32); 70         } catch (UnknownHostException e) { 71             // 若是获取失败，则使用随机数备用
72             return RandomUtils.nextLong(0,31); 73  } 74  } 75  
76     private Long getDataCenterId(){ 77         int[] ints = StringUtils.toCodePoints(SystemUtils.getHostName()); 78         int sums = 0; 79         for (int i: ints) { 80             sums += i; 81  } 82         return (long)(sums % 32); 83  } 84  
85 }

交给Ioc容器管理

参考文章：

https://blog.csdn.net/java_zhangshuai/article/details/86668974

https://www.cnblogs.com/domi22/p/10629704.html

其余版本：

https://www.cnblogs.com/Hollson/p/9116218.html