雪花算法snowflake分布式id生成原理详解，以及对解决时钟回拨问题几种方案讨论

最新推荐文章于 2024-08-03 14:41:33 发布
置顶 最新推荐文章于 2024-08-03 14:41:33 发布
阅读量6.8k 收藏 53
点赞数
分类专栏： 日常积累 数据结构与算法 Java进阶 文章标签： 雪花算法 时钟回拨 发号器
本文为博主原创文章，转载请注明本人源链接。微信公众号搜索：徐同学呀，愿与你共同进步！
本文链接：https://blog.csdn.net/weixin_36586120/article/details/118018414
版权

文章目录

一、前言

在日趋复杂的分布式系统中，数据量越来越大，数据库分库分表是一贯的垂直水平做法，但是需要一个全局唯一ID标识一条数据或者MQ消息，数据库id自增就显然不能满足要求了。因为场景不同，分布式ID需要满足以下几个条件：

  1. 全局唯一性，不能出现重复的ID。
  2. 趋势递增，在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上应该尽量使用有序的主键保证写入性能。
  3. 单调递增，保证下一个ID一定大于上一个ID。例如分布式事务版本号、IM增量消息、排序等特殊需求。
  4. 信息安全，对于特殊业务，如订单等，分布式ID生成应该是无规则的，不能从ID上反解析出流量等敏感信息。

市面上对分布式ID生成大致有几种算法（一些开源项目都是围着这几种算法进行实现和优化）：

  1. UUID：因为是本地生成，性能极高，但是生成的ID太长，16字节128位，通常需要字符串类型存储，且无序，所以很多场景不适用，也不适用于作为MySQL数据库的主键和索引（MySql官方建议，主键越短越好；对于InnoDB引擎，索引的无序性可能会引起数据位置频繁变动，严重影响性能）。
  2. 数据库自增ID：每次获取ID都需要DB的IO操作，DB压力大，性能低。数据库宕机对外依赖服务就是毁灭性打击，不过可以部署数据库集群保证高可用。
  3. 数据库号段算法：对数据库自增ID的优化，每次获取一个号段的值。用完之后再去数据库获取新的号段，可以大大减轻数据库的压力。号段越长，性能越高，同时如果数据库宕机，号段没有用完，短时间还可以对外提供服务。（美团的Leaf、滴滴的TinyId）
  4. 雪花算法：Twitter开源的snowflake，以时间戳+机器+递增序列组成，基本趋势递增，且性能很高，因为强依赖机器时钟，所以需要考虑时钟回拨问题，即机器上的时间可能因为校正出现倒退，导致生成的ID重复。（百度的uid-generator、美团的Leaf）

雪花算法和数据库号段算法用的最多，本篇主要对雪花算法原理剖析和解决时钟回拨问题讨论。

二、雪花算法snowflake

1、基本定义

全网都在用这个图-yyds

snowflake原理其实很简单，生成一个64bit（long）的全局唯一ID，标准元素以1bit无用符号位+41bit时间戳+10bit机器ID+12bit序列化组成，其中除1bit符号位不可调整外，其他三个标识的bit都可以根据实际情况调整：

  1. 41bit-时间可以表示（1L<<41）/(1000L360024*365)=69年的时间。
  2. 10bit-机器可以表示1024台机器。如果对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器。
  3. 12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s。

注：都是从0开始计数。

2、snowflake的优缺点

优点：

  • 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
  • 可以不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也非常高。
  • 可以根据自身业务特性分配bit位，非常灵活。

缺点：

  • 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务处于不可用状态。

三、Java代码实现snowflake

如下示例，41bit给时间戳，5bit给IDC，5bit给工作机器，12bit给序列号，代码中是写死的，如果某些bit需要动态调整，可在成员属性定义。计算过程需要一些位运算基础。

public class SnowflakeIdGenerator {

    public static final int TOTAL_BITS = 1 << 6;

    private static final long SIGN_BITS = 1;

    private static final long TIME_STAMP_BITS = 41L;

    private static final long DATA_CENTER_ID_BITS = 5L;

    private static final long WORKER_ID_BITS = 5L;

    private static final long SEQUENCE_BITS = 12L;

    /**
     * 时间向左位移位数 22位
     */
    private static final long TIMESTAMP_LEFT_SHIFT = WORKER_ID_BITS + DATA_CENTER_ID_BITS + SEQUENCE_BITS;

    /**
     * IDC向左位移位数 17位
     */
    private static final long DATA_CENTER_ID_SHIFT = WORKER_ID_BITS + SEQUENCE_BITS;

    /**
     * 机器ID 向左位移位数 12位
     */
    private static final long WORKER_ID_SHIFT = SEQUENCE_BITS;

    /**
     * 序列掩码，用于限定序列最大值为4095
     */
    private static final long SEQUENCE_MASK =  -1L ^ (-1L << SEQUENCE_BITS);

    /**
     * 最大支持机器节点数0~31，一共32个
     */
    private static final long MAX_WORKER_ID = -1L ^ (-1L << WORKER_ID_BITS);
    /**
     * 最大支持数据中心节点数0~31，一共32个
     */
    private static final long MAX_DATA_CENTER_ID = -1L ^ (-1L << DATA_CENTER_ID_BITS);

    /**
     * 最大时间戳 2199023255551
     */
    private static final long MAX_DELTA_TIMESTAMP = -1L ^ (-1L << TIME_STAMP_BITS);

    /**
     * Customer epoch
     */
    private final long twepoch;

    private final long workerId;

    private final long dataCenterId;

    private long sequence = 0L;

    private long lastTimestamp = -1L;

    /**
     *
     * @param workerId 机器ID
     * @param dataCenterId  IDC ID
     */
    public SnowflakeIdGenerator(long workerId, long dataCenterId) {
        this(workerId, dataCenterId, null);
    }

    /**
     *
     * @param workerId  机器ID
     * @param dataCenterId IDC ID
     * @param epochDate 初始化时间起点
     */
    public SnowflakeIdGenerator(long workerId, long dataCenterId, Date epochDate) {
        if (workerId > MAX_WORKER_ID || workerId < 0) {
            throw new IllegalArgumentException("worker Id can't be greater than "+ MAX_WORKER_ID + " or less than 0");
        }
        if (dataCenterId > MAX_DATA_CENTER_ID || dataCenterId < 0) {
            throw new IllegalArgumentException("datacenter Id can't be greater than {" + MAX_DATA_CENTER_ID + "} or less than 0");
        }

        this.workerId = workerId;
        this.dataCenterId = dataCenterId;
        if (epochDate != null) {
            this.twepoch = epochDate.getTime();
        } else {
            //2010-10-11
            this.twepoch = 1286726400000L;
        }

    }

    public long genID() throws Exception {
        try {
            return nextId();
        } catch (Exception e) {
            throw e;
        }
    }

    public long getLastTimestamp() {
        return lastTimestamp;
    }

    /**
     * 通过移位解析出sequence，sequence有效位为[0,12]
     * 所以先向左移64-12，然后再像右移64-12，通过两次移位就可以把无效位移除了
     * @param id
     * @return
     */
    public long getSequence2(long id) {
        return (id << (TOTAL_BITS - SEQUENCE_BITS)) >>> (TOTAL_BITS - SEQUENCE_BITS);
    }

    /**
     * 通过移位解析出workerId，workerId有效位为[13,17], 左右两边都有无效位
     * 先向左移 41+5+1，移除掉41bit-时间，5bit-IDC、1bit-sign，
     * 然后右移回去41+5+1+12，从而移除掉12bit-序列号
     * @param id
     * @return
     */
    public long getWorkerId2(long id) {
        return (id << (TIME_STAMP_BITS + DATA_CENTER_ID_BITS + SIGN_BITS)) >>> (TIME_STAMP_BITS + DATA_CENTER_ID_BITS + SEQUENCE_BITS + SIGN_BITS);
    }
    /**
     * 通过移位解析出IDC_ID，dataCenterId有效位为[18,23]，左边两边都有无效位
     * 先左移41+1，移除掉41bit-时间和1bit-sign
     * 然后右移回去41+1+5+12，移除掉右边的5bit-workerId和12bit-序列号
     * @param id
     * @return
     */
    public long getDataCenterId2(long id) {
        return (id << (TIME_STAMP_BITS + SIGN_BITS)) >>> (TIME_STAMP_BITS + WORKER_ID_BITS + SEQUENCE_BITS + SIGN_BITS);
    }
    /**
     * 41bit-时间，左边1bit-sign为0，可以忽略，不用左移，所以只需要右移，并加上起始时间twepoch即可。
     * @param id
     * @return
     */
    public long getGenerateDateTime2(long id) {
        return (id >>> (DATA_CENTER_ID_BITS + WORKER_ID_BITS + SEQUENCE_BITS)) + twepoch;
    }

    public long getSequence(long id) {
        return id & ~(-1L << SEQUENCE_BITS);
    }

    public long getWorkerId(long id) {
        return id >> WORKER_ID_SHIFT & ~(-1L << WORKER_ID_BITS);
    }

    public long getDataCenterId(long id) {
        return id >> DATA_CENTER_ID_SHIFT & ~(-1L << DATA_CENTER_ID_BITS);
    }

    public long getGenerateDateTime(long id) {
        return (id >> TIMESTAMP_LEFT_SHIFT & ~(-1L << 41L)) + twepoch;
    }

    private synchronized long nextId() throws Exception {
        long timestamp = timeGen();
        // 1、出现时钟回拨问题，直接抛异常
        if (timestamp < lastTimestamp) {
            long refusedTimes = lastTimestamp - timestamp;
            // 可自定义异常类
            throw new UnsupportedOperationException(String.format("Clock moved backwards. Refusing for %d seconds", refusedTimes));
        }
        // 2、时间等于lastTimestamp，取当前的sequence + 1
        if (timestamp == lastTimestamp) {
            sequence = (sequence + 1) & SEQUENCE_MASK;
            // Exceed the max sequence, we wait the next second to generate id
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            // 3、时间大于lastTimestamp没有发生回拨， sequence 从0开始
            this.sequence = 0L;
        }
        lastTimestamp = timestamp;

        return allocate(timestamp - this.twepoch);
    }

    private long allocate(long deltaSeconds) {
        return (deltaSeconds << TIMESTAMP_LEFT_SHIFT) | (this.dataCenterId << DATA_CENTER_ID_SHIFT) | (this.workerId << WORKER_ID_SHIFT) | this.sequence;
    }

    private long timeGen() {
        long currentTimestamp = System.currentTimeMillis();
        // 时间戳超出最大值
        if (currentTimestamp - twepoch > MAX_DELTA_TIMESTAMP) {
            throw new UnsupportedOperationException("Timestamp bits is exhausted. Refusing ID generate. Now: " + currentTimestamp);
        }
        return currentTimestamp;
    }

    private long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    /**
     * 测试
     * @param args
     */
    public static void main(String[] args) throws Exception {
        SnowflakeIdGenerator snowflakeIdGenerator = new SnowflakeIdGenerator(1,2);
        long id = snowflakeIdGenerator.genID();

        System.out.println("ID=" + id + ", lastTimestamp=" + snowflakeIdGenerator.getLastTimestamp());
        System.out.println("ID二进制：" + Long.toBinaryString(id));
        System.out.println("解析ID:");
        System.out.println("Sequence=" + snowflakeIdGenerator.getSequence(id));
        System.out.println("WorkerId=" + snowflakeIdGenerator.getWorkerId(id));
        System.out.println("DataCenterId=" + snowflakeIdGenerator.getDataCenterId(id));
        System.out.println("GenerateDateTime=" + snowflakeIdGenerator.getGenerateDateTime(id));

        System.out.println("Sequence2=" + snowflakeIdGenerator.getSequence2(id));
        System.out.println("WorkerId2=" + snowflakeIdGenerator.getWorkerId2(id));
        System.out.println("DataCenterId2=" + snowflakeIdGenerator.getDataCenterId2(id));
        System.out.println("GenerateDateTime2=" + snowflakeIdGenerator.getGenerateDateTime2(id));
    }

}

雪花算法ID生成传统流程

1、组装生成id

生成id的过程，就是把每一种标识（时间、机器、序列号）移到对应位置，然后相加。

long id = (deltaTime << TIMESTAMP_LEFT_SHIFT) | (this.dataCenterId << DATA_CENTER_ID_SHIFT) | (this.workerId << WORKER_ID_SHIFT) | this.sequence;
  • deltaTime向左移22位（IDC-bit+机器bit+序列号bit）。
  • dataCenterId向左移17位（机器bit+序列号bit）。
  • workerId向左移12位（序列号bit）。
  • sequence不用移。
  • 中间的|以运算规律就相当于+求和（1 | 1 = 1，1 | 0 = 1，0 | 1 = 1，0 | 0 = 0）。

2、计算最大值的几种方式

（1）注意到代码中分别对每个标识的最大值做了计算：

//序列掩码，用于限定序列最大值为4095 ((2^12)-1) ，从0开始算就有4096个序列
private static final long SEQUENCE_MASK =  -1L ^ (-1L << SEQUENCE_BITS);

//最大支持机器节点数0~31，一共32个  (2^5)-1
private static final long MAX_WORKER_ID = -1L ^ (-1L << WORKER_ID_BITS);

//最大支持数据中心节点数0~31，一共32个   (2^5)-1
private static final long MAX_DATA_CENTER_ID = -1L ^ (-1L << DATA_CENTER_ID_BITS);

//最大时间戳 2199023255551   (2^41)-1
private static final long MAX_DELTA_TIMESTAMP = -1L ^ (-1L << TIME_STAMP_BITS);

如上方式计算最大值并不好理解，就是利用二进制的运算逻辑，如果不了解根本看不懂。拿-1L ^ (-1L << SEQUENCE_BITS)举例：

先看看从哪个方向开始计算：-1L ^ (-1L << 12)，-1L和(-1L <<12)做^按位异或运算（1 ^ 1 = 0，1 ^ 0 = 1，0 ^ 1 = 1，0 ^ 0 = 0）。

  • -1L的二进制为64个1：1111111111111111111111111111111111111111111111111111111111111111。
  • -1L左移12位得到：1111111111111111111111111111111111111111111111111111 000000 000000。
  • 最后1111111111111111111111111111111111111111111111111111111111111111和1111111111111111111111111111111111111111111111111111 000000 000000做^运算得到0000000000000000000000000000000000000000000000000000 111111 111111（前面有52个0），这就得到序列号的最大值（4095）了，也可以说是掩码。

Java运算符优先级列表

（2）其实有一种更容易理解的计算最大值的方式，比如计算12bit-序列号的最大值，那就是(2^12 -1)呀，但是位运算性能更高，用位运算的方式就是((1 << 12) -1)。1左移12位得到1 0000 0000 0000，减1也是可以得到1111 1111 1111，即4095。

（3）还看到一种计算最大值的方式，继续拿12bit-序列号举例，~(-1L << 12)，~不知道怎么计算那就傻了：

-1L先向左移12位得到1111111111111111111111111111111111111111111111111111 000000 000000，然后进行~按位非运算（~ 1 = -2，~ 0 = -1 ，~n = - ( n+1 )），也可以理解为反转，1转为0,0转为1，然后也可以得到0000000000000000000000000000000000000000000000000000 111111 111111。

3、反解析ID

（1）通过已经生成的ID解析出时间、机器和序列号：

public long getSequence(long id) {
    return id & ~(-1L << SEQUENCE_BITS);
}

public long getWorkerId(long id) {
    return id >> WORKER_ID_SHIFT & ~(-1L << WORKER_ID_BITS);
}

public long getDataCenterId(long id) {
    return id >> DATA_CENTER_ID_SHIFT & ~(-1L << DATA_CENTER_ID_BITS);
}

public long getGenerateDateTime(long id) {
    return (id >> TIMESTAMP_LEFT_SHIFT & ~(-1L << 41L)) + twepoch;
}

因为sequence本身就在低位，所以不需要移动，其他机器和时间都是需要将id向右移动，使得自己的有效位置在低位，至于和自己的最大值做&运算，是为了让不属于自己bit的位置无效，即都转为0。

例如：生成的id为1414362783486840832，转为二进制1001110100000110100110111010100111101010001000001000000000000，想解析出workerId，workerId有效位为[13, 17]，那就将id向右移12位，移到低位得到0000000000001001110100000110100110111010100111101010001000001，workerId有5-bit，那么除了低位5-bit，其他位置都是无效bit，转为0。0000000000001001110100000110100110111010100111101010001000001和11111做&运算得到1（左边都是0可以省掉）。

（2）不过还有一种解析的思路更易于理解，就是运用两次移位运算，把无效位置移除：

1bit-sign + 41bit-time + 5bit-IDC + 5bit-workerId + 12bit-sequence

/**
 * 通过移位解析出sequence，sequence有效位为[0,12]
 * 所以先向左移64-12，然后再像右移64-12，通过两次移位就可以把无效位移除了
 * @param id
 * @return
 */
public long getSequence2(long id) {
    return (id << (TOTAL_BITS - SEQUENCE_BITS)) >>> (TOTAL_BITS - SEQUENCE_BITS);
}
/**
 * 通过移位解析出workerId，workerId有效位为[13,17], 左右两边都有无效位
 * 先向左移 41+5+1，移除掉41bit-时间，5bit-IDC、1bit-sign，
 * 然后右移回去41+5+1+12，从而移除掉12bit-序列号
 * @param id
 * @return
 */
public long getWorkerId2(long id) {
    return (id << (TIME_STAMP_BITS + DATA_CENTER_ID_BITS + SIGN_BITS)) >>> (TIME_STAMP_BITS + DATA_CENTER_ID_BITS + SEQUENCE_BITS + SIGN_BITS);
}
/**
 * 通过移位解析出IDC_ID，dataCenterId有效位为[18,23]，左边两边都有无效位
 * 先左移41+1，移除掉41bit-时间和1bit-sign
 * 然后右移回去41+1+5+12，移除掉右边的5bit-workerId和12bit-序列号
 * @param id
 * @return
 */
public long getDataCenterId2(long id) {
    return (id << (TIME_STAMP_BITS + SIGN_BITS)) >>> (TIME_STAMP_BITS + WORKER_ID_BITS + SEQUENCE_BITS + SIGN_BITS);
}
/**
 * 41bit-时间，左边1bit-sign为0，可以忽略，不用左移，所以只需要右移，并加上起始时间twepoch即可。
 * @param id
 * @return
 */
public long getGenerateDateTime2(long id) {
    return (id >>> (DATA_CENTER_ID_BITS + WORKER_ID_BITS + SEQUENCE_BITS)) + twepoch;
}

4、ID生成器使用方式

主要有两种方式，一种是发号器，一种是本地生成：

  • 发号器，就是把雪花算法ID生成封装成一个服务，部署在多台机器上，由外界请求发号器服务获取ID。这样做的好处，是机器不需要那么多，1024台完全足够了，相对ID的时间戳和序列号的bit就可以调大一些。但是因为需要远程请求获取ID，所以会受到网络波动的影响，性能上肯定是没有直接从本地生成获取高的，同时发号器一旦挂了，很多服务就不能对外提供服务了，所以发号器服务需要高可用，多实例，异地部署和容灾，发号器在发号的时候，也可以发布一段时间的ID，服务本地缓存起来，这样不仅提高性能，不需要每次都去请求发号器，也在一定程度上缓解了发号器故障带来的影响。
  • 本地生成ID，没有网络延迟，性能极高。只能通过机器id来保证生成的ID唯一性，所以需要提供足够多的机器id，每台机器可能部署多个服务，每个服务可能部署在多台机器，都需要分配不同的机器id，并且服务重启了也需要重新分配机器id。这样机器id就有了用后即毁的特点。需要足够多的机器id，就必须缩减时间bit和序列号bit。

可以利用MySql或者zk进行机器id的分配和管理。

四、时钟回拨问题和解决方案讨论

首先看看时钟为什么会发生回拨？机器本地时钟可能会因为各种原因发生不准的情况，网络中提供了NTP服务来做时间校准，做校准的时候就会发生时钟的跳跃或者回拨的问题。

因为雪花算法强依赖机器时钟，所以难以避免受到时钟回拨的影响，有可能产生ID重复。原标准实现代码中是直接抛异常，短暂停止对外服务，这样在实际生产中是无法忍受的。所以要尽量避免时钟回拨带来的影响，解决思路有两个：

  • 不依赖机器时钟驱动，就没时钟回拨的事儿了。即定义一个初始时间戳，在初始时间戳上自增，不跟随机器时钟增加。时间戳何时自增？当序列号增加到最大时，此时时间戳+1，这样完全不会浪费序列号，适合流量较大的场景，如果流量较小，可能出现时间断层滞后。
  • 依然依赖机器时钟，如果时钟回拨范围较小，如几十毫秒，可以等到时间回到正常；如果流量不大，前几百毫秒或者几秒的序列号肯定有剩余，可以将前几百毫秒或者几秒的序列号缓存起来，如果发生时钟回拨，就从缓存中获取序列号自增。

（时钟回拨问题，可通过手动调整电脑上的时钟进行模拟测试。）

1、时间戳自增彻底解决时钟回拨问题

private long sequence = -1L;
private long startTimestamp = 1623947387000L;
private synchronized  long nextId2() {
    long sequenceTmp = sequence;
    sequence = (sequence + 1) & SEQUENCE_MASK;
    // sequence =0 有可能是初始+1=0，也可能是超过了最大值等于0
    // 所以把 初始+1=0排除掉
    if (sequence == 0 && sequenceTmp >= 0) {
        // sequence自增到最大了，时间戳自增1
        startTimestamp += 1;
    }
    // 生成id
    return allocate(startTimestamp - twepoch);
}

起始时间可以构造器里指定，也可以用默认的，而sequence初始为-1，是为了不想浪费sequence+1=0这一序列号。

sequence = 0排除掉初始sequence=-1 +1 = 0的情况就是sequence超过最大值了，此时时间戳startTimestamp自增。

代码和思路都很简单，就是完全脱离机器时钟，彻底解决了时钟回拨问题。显而易见的优点，每一毫秒4096个序列号（[0,4095]）没有浪费，同时因为时间自增由程序自己掌控，所以可以利用未来时间，预先生成一些ID放在缓存里，外界从缓存中直接获取ID，快消费完了再生产，这样就形成了永动的生产-消费者模式，获取ID省去了生成的过程，性能也会大大提升。

但是时间戳完全自控，也有很明显的缺点，ID生成的时间，并不是真实的时间，如果流量较小，时间可能会滞后很多。如果对从ID解析出来的时间戳没有什么利用意义，这个缺点也不需要关心。

2、缓存历史序列号缓解时钟回拨问题

// 记录近2S的毫秒数的sequence的缓存
private int LENGTH = 2000;
// sequence缓存
private long[] sequenceCycle = new long[LENGTH];

private synchronized long nextId() throws Exception {
    long timestamp = timeGen();
    int index = (int)(timestamp % LENGTH);
    // 1、出现时钟回拨问题，获取历史序列号自增
    if (timestamp < lastTimestamp) {
        long sequence = 0;
        do {
           if ((lastTimestamp - timestamp) > LENGTH) {
               // 可自定义异常、告警等，短暂不能对外提供，故障转移，将请求转发到正常机器。
               throw new UnsupportedOperationException("The timeback range is too large and exceeds 2000ms caches");
            }
            long preSequence = sequenceCycle[index];
            sequence = (preSequence + 1) & SEQUENCE_MASK;
            if (sequence == 0) {
                // 如果取出的历史序列号+1后已经达到超过最大值，
                // 则重新获取timestamp,重新拿其他位置的缓存
                timestamp = tilNextMillis(lastTimestamp);
                index = (int)(timestamp % LENGTH);
            } else {
            	// 更新缓存
                sequenceCycle[index] = this.sequence;            
                return allocate((timestamp - this.twepoch), sequence);
            }
        } while (timestamp < lastTimestamp);
        // 如果在获取缓存的过程中timestamp恢复正常了，就走正常流程
    }
    // 2、时间等于lastTimestamp，取当前的sequence + 1
    if (timestamp == lastTimestamp) {
        sequence = (sequence + 1) & SEQUENCE_MASK;
        // Exceed the max sequence, we wait the next second to generate id
        if (sequence == 0) {
            timestamp = tilNextMillis(lastTimestamp);
            index = (int)(timestamp % LENGTH);
        }
    } else {
        // 3、时间大于lastTimestamp没有发生回拨， sequence 从0开始
        this.sequence = 0L;
    }
    // 缓存sequence + 更新lastTimestamp
    sequenceCycle[index] = this.sequence;
    lastTimestamp = timestamp;
    // 生成id
    return allocate(timestamp - this.twepoch);
}

这里缓存了2000ms的序列号，如果发生时钟回拨，且回拨范围在2000ms内，就从缓存中取序列号自增，超过2000ms回拨，就抛异常，故障转移，将请求分配到正常机器。

  • 若获取的历史sequence+1之后超过了最大值，则重新获取时间戳，重新获取缓存sequence。
  • 极端情况下，获取很多次缓存sequence+1都超过了最大值，就会一直循环获取，这样可能会影响性能，所以实际生产中可以限定重新获取次数。
  • 在这个重新获取的过程中，时钟可能恢复正常了，则此时也要退出循环，走正常流程。

3、等待时钟校正

private synchronized  long nextId3() {
    long timestamp = timeGen();
    // 1、出现时钟回拨问题，如果回拨幅度不大，等待时钟自己校正
    if (timestamp < lastTimestamp) {
        int sleepCntMax = 2;
        int sleepCnt = 0;
        do {
            long sleepTime = lastTimestamp - timestamp;
            if (sleepCnt > sleepCntMax) {
                // 可自定义异常类
                throw new UnsupportedOperationException(String.format("Clock moved backwards. Refusing for %d seconds", sleepTime));
            }
            if (sleepTime <= 500) {
                try {
                    Thread.sleep(sleepTime);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    sleepCnt++;
                    timestamp = tilNextMillis(lastTimestamp);
                }
            } else {
                // 可自定义异常类
                throw new UnsupportedOperationException(String.format("Clock moved backwards. Refusing for %d seconds", sleepTime));
            }
        } while (timestamp < lastTimestamp);
    }
    // 2、时间等于lastTimestamp，取当前的sequence + 1
    if (timestamp == lastTimestamp) {
        sequence = (sequence + 1) & SEQUENCE_MASK;
        // Exceed the max sequence, we wait the next second to generate id
        if (sequence == 0) {
            timestamp = tilNextMillis(lastTimestamp);
        }
    } else {
        // 3、时间大于lastTimestamp没有发生回拨， sequence 从0开始
        this.sequence = 0L;
    }
    lastTimestamp = timestamp;
    // 生成id
    return allocate(timestamp - this.twepoch);
}

等待时钟自己校正来解决时钟回拨问题，适用于回拨幅度小的场景。比如回拨时长小于500ms，那就睡眠500ms，等时间恢复到正常，如果这个过程中又发生了时钟回拨，不可能一直等它校正，实际生产中可限定校正的次数，超过最大校正次数，那就抛异常吧，这属于极端情况。

解决时钟回拨问题的方法还有很多，无非就是避免和缓解。每种方式有各自的特点和适用场景，可以两两结合使用，比如时钟回拨幅度小，就休眠校正，回拨幅度大或者出现多次回拨，也不抛异常，获取缓存sequence对外提供服务。也可以当发生时钟回拨时，用备用机器id生成ID等。

五、要点总结

  1. 生成全局唯一的分布式ID的方式有很多，常用的有数据库号段算法和雪花算法，这两个算法的实践，大厂也有开源的项目，如百度的uid-generator、美团的Leaf、滴滴的TinyId等。
  2. 雪花算法的原理很简单，主要由时间戳+机器id+序列号生成64bit的ID，整体趋势递增，且全局唯一，性能也不错。每种组成标识的bit都可以自定义，灵活性很高，如果需要更高的QPS，可以相对的把序列号bit调大一些。
  3. 因为雪花算法强依赖机器时钟，就难以避免时钟回拨问题，解决的方式很多，无非从避免和缓解两个角度出发，常用的方式有，时间戳自增脱离机器时钟依赖，利用缓存序列号，或者等待时钟校正等，各有各的特点，正确利用其优点，才能最大提高性能。
  4. 雪花算法ID生成器的使用方式有两种，一种是远程发号器，需要做到高可用。另一种就是直接本地生成ID，省去了远程请求过程，性能自然也是比远程发号器高的，但是机器id用后即毁，需要分配足够多的机器id。机器id的管理和分配可以利用MySql或者ZK。

参考：

如若文章有错误理解，欢迎批评指正，同时非常期待你的评论、点赞和收藏。

徐同学呀
关注
专栏目录
雪花算法时钟回拨问题
TheMilkyWayisbri的博客
08-29 677
雪花算法时钟回拨问题雪花算法（Snowflake Algorithm）是Twitter开源的一种分布式唯一ID生成算法，用于在分布式系统中生成全局唯一的ID。该算法生成的ID是一个64位的整数，由多个部分组成，包括符号位、时间戳、机器ID和序列号。然而，雪花算法依赖于系统时间的准确性，当系统时钟出现回拨（即时间回到之前的时间点）时，可能会导致ID重复或排序异常。
【项目经验】雪花算法与时钟回拨问题解决
软件工程探索之旅
05-08 1214
使用雪花算法生成分布式ID并遇到时钟回拨的真实案例，文中有解决方案，欢迎点击
深度思考：雪花算法snowflake分布式id生成原理详解
科技互联网领域深度探索者，乐于分享与写作。
03-29 2723
雪花算法snowflake是一种优秀的分布式ID生成方案，其优点突出：它能生成全局唯一且递增的ID，确保了数据的一致性和准确性；同时，该算法灵活性强，可自定义各部分bit位，满足不同业务场景的需求；此外，雪花算法生成ID的速度快，效率高，能有效应对高并发场景，是分布式系统中不可或缺的组件。
雪花算法（Snowflake）
qq_63161848的博客
08-03 2432
雪花算法（Snowflake）是一种生成全局唯一ID的分布式算法。它的主要功能是在分布式系统中生成一个全局唯一的ID，且ID是按照时间有序递增的。
雪花算法（Snowflake Algorithm）中解决时钟回拨
gaoqiao1988的专栏
03-16 2329
但是，在某些应用场景中，为了确保在分布式环境下生成的ID更加有序且具备更高的可用性，开发者可能会结合Redis的原子操作特性来管理序列号部分。： 雪花算法原本设计中序列号是在内存中自增的，为了避免时钟回拨导致的序列号重置问题，可以将序列号持久化存储到磁盘上，这样即使服务重启或时钟回拨，服务也能继续从上次持久化的序列号开始自增，从而避免ID重复。： 结合多种手段，例如增加序号的长度以提供更大的回拨容忍空间，同时配合持久化序列号、使用更可靠的时间源等措施，共同保障ID的唯一性。
雪花算法中的时间回拨问题解决方案
或左的博客
04-20 9864
什么是时间回拨问题 雪花算法通过时间来即将作为id的区分标准之一,对于同一台id生成机器,它通过时间和序号保证id不重复 当机器出现问题,时间可能回到之前,此时,时间就不能区分 又或者因为闰秒的出现,导致时间回拨 如何解决 方法1 直接抛出异常 不管3X7==21,直接抛出异常 将问题交给人工解决 这种方法也是原始的雪花算法,百度的uid-generator采用的 太过简单,显然不好 方法2 延迟等待 这种时间回拨(回跳)或许只出现一次,也许只是机器出现了小问题,所以产生 对于这种场景,没有必要抛
雪花算法-Java实现-解决时钟回拨的一种方法
tt5753的专栏
08-13 5180
一种可能是解决时钟回拨的方法, 仅改动代码, 不需要其他辅助.
分布式ID生成算法 - 雪花算法SnowFlake,不重复
最新发布
08-19
时间戳必须大于上一次生成ID的时间戳. 如果和上次生成时间不同,重置sequence，就是下一毫秒开始，sequence计数重新从0开始累加, 为了保证尾数随机性更大一些,最后一位可以设置一个随机数 防止产生的时间比之前的...
Js Snowflake(雪花算法)生成随机ID的实现方法
10-14
Js Snowflake算法，也称为雪花算法，是一种分布式系统中用于生成全局唯一ID的算法。该算法由Twitter开源，其生成的ID由64位的二进制数字组成，分为以下几个部分： 1. **时间戳**（41位）：从指定的起始时间（例如...
分布式ID生成方案-snowflake算法
【码农在新加坡】的专栏
12-30 3356
背景 在互联网的业务系统中，涉及到各种各样的ID，这些ID需要保证全局唯一。我们称之为分布式ID，分布式ID需要满足 唯一性、趋势递增性、高可用性、高性能等特点。 snowflake算法，也叫雪花算法，是其中的一种分布式ID生成方案。是twitter公司内部分布式项目采用的ID生成算法，开源后广受国内大厂的好评，在该算法影响下各大公司相继开发出各具特色的分布式生成器。 讲解雪花算法前，我们先概述一下分布式ID有哪些生成方案。 分布式ID生成方案 分布式ID有以下几种生成方式： UUID 算法的核心思想是结合
迄今为止最全面的分布式主键ID生成器，多语言新雪花算法（SnowFlake IdGenerator）.zip
05-03
优化的雪花算法（SnowFlake）——雪花漂移算法，在缩短ID长度的同时，具备极高瞬时并发处理能力（50W/0.1s）。 原生支持 C#/Java/Go/Rust/C/SQL 等多语言，且提供 PHP 扩展及 Python、Node.js、Ruby 多线程安全调用...
雪花算法时钟回拨解决方案
qq_3316359388的博客
05-23 480
用服务启动时的时间，等id追上已持久化数据的id，得到一个偏移量，后面时间的增量加上偏移量，就是有效id。
雪花算法解决时钟回拨问题
热门推荐
lzf的博客
03-23 1万+
SnowFlake算法 据国家大气研究中心的查尔斯·奈特称，一般的雪花大约由10^19个水分子组成。在雪花形成过程中，会形成不同的结构分支，所以说大自然中不存在两片完全一样的雪花，每一片雪花都拥有自己漂亮独特的形状。雪花算法表示生成的id如雪花般独一无二。 snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每
雪花算法-用go实现-附带三种解决时钟回拨的方案以及代码
qq_58339096的博客
08-24 1060
用go编写雪花算法-附带三种解决时钟回拨的方案代码
浅谈解决雪花算法的时钟回拨问题
qq_43513370的博客
03-24 1656
每个一段时间内保存过去一段时内 机器当前这一毫秒产生的 ID 的最大值，例如使用Map形式，就是<机器的id,最大值>,如果发生了时钟回拨，直接在这台机器对应的最大值继续自增生成 ID 即可。由于生成随机数时依赖于服务器的时间，加入机器发生了故障或者别的情况，对于服务器的时间进行了回拨，那么会导致生成的 ID 可能发生重复。第53-64的bit位：这12位表示序列号，也就是1毫秒内可以生成2的12方个不同的 ID。不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
『SnowFlake』雪花算法的详解及时间回拨解决方案
老陈聊架构
12-09 4932
📣读完这篇文章里你能收获到：图文形式为你讲解原生雪花算法的特征及原理，了解时间回拨的概念以及可能引起发此现象的操作，掌握时间回拨的解决方案—基于时钟序列的雪花算法，关于雪花算法的常见问题解答
雪花算法的实现原理
ACGkaka的博客
08-03 1532
雪花算法的实现原理
雪花算法时钟回拨解决
11-16
为了解决雪花算法中的时钟回拨问题，可以采用以下两种方法： 1.使用NTP协议同步时间：NTP是网络时间协议，可以通过与NTP服务器同步时间来解决时钟回拨问题。在使用雪花算法生成ID之前，先通过NTP协议同步服务器时间，确保服务器时间准确无误。 2.使用本地时钟回拨缓存：在使用雪花算法生成ID时，记录上一次生成ID的时间戳，如果当前时间戳小于上一次生成ID的时间戳，则说明出现了时钟回拨问题。此时可以使用本地时钟回拨缓存来解决问题，即将上一次生成ID的时间戳作为缓存，用缓存时间戳代替当前时间戳生成ID，直到当前时间戳大于缓存时间戳为止。
评论 13
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

徐同学呀

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值