Twitter雪花算法SnowFlake改造: 兼容JS截短位数的53bit分布式ID生成器

时间 2019-11-09

标签雪花算法 snowflake 改造兼容截短位数 53bit bit 分布式成器栏目 JavaScript 繁體版

原文原文链接

前言

众所周知, 在分布式全局惟一ID生成器方案中, 由Twitter开源的SnowFlake算法对比美团Leaf为表明的须要部署的发号器算法, 因其有性能高, 代码简单, 不依赖第三方服务, 无需独立部署服务等优势, 在通常状况下已经能知足绝大多数系统的需求, 原生SnowFlake, 百度UidGenerator这类基于划分命名空间原理的算法已经积累了大量用户;html

使用原生的雪花算法其默认生成的是64bit长整型, 若是以ID和前端的JS进行交互时会出现精度丢失(最后两位数字变成00) 而致使最终系统报错: 找不到ID; 废话, 最后两位都变成00了那确定找不到啊! 究其缘由是由于JS的Number类型精度最高只有53bit, 致使JS其最大安全值只有2^53 = ‭9007199254740992 算法生成的18位数字妥妥的超标了啊;前端

解决方法有: 避免使用ID进行交互, 后端将long类型的ID映射为String, 使JS兼容64bit长整型, 改造SnowFlake缩短位数;java

既然是由于位数太长了, 那咱们缩短位数不就行了吗? JS的53bit精度, 也有最大值是亿亿, 也没有谁会有亿亿个数据吧, 那咱们仔细研究一下这个雪花算法, 把他缩短一下, 程序员如何向公司证实本身的价值不就在于反复造轮子吗? 管他方的轮子好用仍是圆的轮子好用;git

对SnowFlake进行改造

命名空间划分(减小位长, 改成Unix的秒级时间戳)

原生SnowFlake默认结构以下:程序员

原生SnowFlake中的空间划分:
1, 高位1bit固定0表示正数
2, 41bit毫秒时间戳
3, 10bit机器编号, 最高可支持1024个节点
4, 12bit自增序列, 单节点最高可支持4096个ID/ms
复制代码

由上面原生算法结构能够看到, 影响最终生成ID长度最大的是毫秒时间戳, 它占了整整41bit换成10进制就是占了13位数, 不减小这个最终位数确定就下不去; 考虑到绝大部分公司并不存在这么高的数据库并发也没有1024台这么多的机器集群;github

时间戳由毫秒改成32bit的秒级时间戳, 机器编码缩短为5bit, 剩下16bit作自增序列;算法

机器编号也能够减小, 最终结果以下图 ↓↓↓:数据库

缩短算法后空间划分
1, 高位32bit做为秒级时间戳, 时间戳减去固定值(2019年时间戳), 最高可支持到2106年(1970 + 2^32 / 3600 / 24 / 365 ≈ 2106)
2, 5bit做为机器标识, 最高可部署32台机器
3, 最后16bit做为自增序列, 单节点最高每秒 2^16 = 65536个ID
PS: 若是须要部署更多节点, 能够适当调整机器位和自增序列的位长, 如机器位7bit, 自增序列14bit, 这样一来就变成了支持2^7=128个节点, 单节点每秒2^14=16384个自增序列
复制代码

时钟回拨问题(可用节点减半, 设置备份节点)

趋势自增依赖于高位的时间戳, 若是服务器因同步时间等操做致使了时钟回拨, 那么将会有可能产生重复ID, 对此个人解决方法是将32个节点ID再次拆分, 0~15做为主节点ID, 16~31做为备份节点ID, 当主节点检测到时钟回拨时, 启用对应的备份节点继续提供服务, 若是不巧极端状况并发极高, 使用备份节点时一秒内耗尽65536个序列, 则借调下一秒的未使用序列, 直到主节点时钟追回;
备份节点可在主节点秒内序列耗尽时接管继续提供服务, 或者在时钟回拨时接管服务, 这样一来最大支持的机器就只剩下16台了, 虽然少了点, 可是也已经足够知足通常小型企业的需求了, 同时也提升了服务的可靠性;后端

主节点与备份节点关系: 主节点为0时对应备份节点为0 + 16 = 16, 主节点为1时则对应1 + 16 = 17, 主节点为2时则对应2 + 16 = 18 ......缓存

具体代码则体现以下: 节点标识为5bit时, BACK_WORKER_ID_BEGIN是备份节点ID的最小值 = 16, 主节点 + 16 获得备份节点

((WORKER_ID ^ BACK_WORKER_ID_BEGIN) << WORKER_SHIFT_BITS)
复制代码

秒内自增序列用尽问题(向后借下一秒未分配的序列)

当遇到极端状况每秒并发超过65536时则会遇到该秒内再无可分配ID的问题, 为了解决这个问题, 可在秒内序列用尽时启用备份节点, 这个一个节点ID则每秒能够得到翻倍的ID, 当备份节点也不足时, 最后能够考虑由备份节点直接启用下一秒的未分配序列继续提供服务, 这样理论上就得到了无限容量的秒内可分配ID(只要机器性能跟得上能够无限借调下一秒, 直到1秒后主节点追回时间差由主节点继续提供服务, 以此循环往复生生不息~)

if (0L == (++sequence & SEQUENCE_MAX)) {
    // 上面自增序列已自增1, 回滚这个自增操做确保下次进入时依旧触发条件
    sequence--;
    // 秒内序列用尽, 使用备份节点继续提供服务
    return nextIdBackup(timestamp);
}
复制代码

代码实现

为了代码逻辑清晰简单, 主节点和备份节点生成直接复制为结构类似的两个方法

/** * 雪花算法分布式惟一ID生成器<br> * 每一个机器号最高支持每秒‭65535个序列, 当秒序列不足时启用备份机器号, 若备份机器也不足时借用备份机器下一秒可用序列<br> * 53 bits 趋势自增ID结构以下: * * |00000000|00011111|11111111|11111111|11111111|11111111|11111111|11111111| * |-----------|##########32bit 秒级时间戳##########|-----|-----------------| * |--------------------------------------5bit机器位|xxxxx|-----------------| * |-----------------------------------------16bit自增序列|xxxxxxxx|xxxxxxxx| * * @author: yangzc * @date: 2019-10-19 **/
@Slf4j
public class SequenceUtils {

    /** 初始偏移时间戳 */
    private static final long OFFSET = 1546300800L;

    /** 机器id (0~15 保留 16~31做为备份机器) */
    private static final long WORKER_ID;
    /** 机器id所占位数 (5bit, 支持最大机器数 2^5 = 32)*/
    private static final long WORKER_ID_BITS = 5L;
    /** 自增序列所占位数 (16bit, 支持最大每秒生成 2^16 = ‭65536‬) */
    private static final long SEQUENCE_ID_BITS = 16L;
    /** 机器id偏移位数 */
    private static final long WORKER_SHIFT_BITS = SEQUENCE_ID_BITS;
    /** 自增序列偏移位数 */
    private static final long OFFSET_SHIFT_BITS = SEQUENCE_ID_BITS + WORKER_ID_BITS;
    /** 机器标识最大值 (2^5 / 2 - 1 = 15) */
    private static final long WORKER_ID_MAX = ((1 << WORKER_ID_BITS) - 1) >> 1;
    /** 备份机器ID开始位置 (2^5 / 2 = 16) */
    private static final long BACK_WORKER_ID_BEGIN = (1 << WORKER_ID_BITS) >> 1;
    /** 自增序列最大值 (2^16 - 1 = ‭65535) */
    private static final long SEQUENCE_MAX = (1 << SEQUENCE_ID_BITS) - 1;
    /** 发生时间回拨时容忍的最大回拨时间 (秒) */
    private static final long BACK_TIME_MAX = 1L;

    /** 上次生成ID的时间戳 (秒) */
    private static long lastTimestamp = 0L;
    /** 当前秒内序列 (2^16)*/
    private static long sequence = 0L;
    /** 备份机器上次生成ID的时间戳 (秒) */
    private static long lastTimestampBak = 0L;
    /** 备份机器当前秒内序列 (2^16)*/
    private static long sequenceBak = 0L;

    static {
        // 初始化机器ID
        // 伪代码: 由你的配置文件获取节点ID
        long workerId = your configured worker id;
        if (workerId < 0 || workerId > WORKER_ID_MAX) {
            throw new IllegalArgumentException(String.format("cmallshop.workerId范围: 0 ~ %d 目前: %d", WORKER_ID_MAX, workerId));
        }
        WORKER_ID = workerId;
    }

    /** 私有构造函数禁止外部访问 */
    private SequenceUtils() {}

    /** * 获取自增序列 * @return long */
    public static long nextId() {
        return nextId(SystemClock.now() / 1000);
    }

    /** * 主机器自增序列 * @param timestamp 当前Unix时间戳 * @return long */
    private static synchronized long nextId(long timestamp) {
        // 时钟回拨检查
        if (timestamp < lastTimestamp) {
            // 发生时钟回拨
            log.warn("时钟回拨, 启用备份机器ID: now: [{}] last: [{}]", timestamp, lastTimestamp);
            return nextIdBackup(timestamp);
        }

        // 开始下一秒
        if (timestamp != lastTimestamp) {
            lastTimestamp = timestamp;
            sequence = 0L;
        }
        if (0L == (++sequence & SEQUENCE_MAX)) {
            // 秒内序列用尽
// log.warn("秒内[{}]序列用尽, 启用备份机器ID序列", timestamp);
            sequence--;
            return nextIdBackup(timestamp);
        }

        return ((timestamp - OFFSET) << OFFSET_SHIFT_BITS) | (WORKER_ID << WORKER_SHIFT_BITS) | sequence;
    }

    /** * 备份机器自增序列 * @param timestamp timestamp 当前Unix时间戳 * @return long */
    private static long nextIdBackup(long timestamp) {
        if (timestamp < lastTimestampBak) {
            if (lastTimestampBak - SystemClock.now() / 1000 <= BACK_TIME_MAX) {
                timestamp = lastTimestampBak;
            } else {
                throw new RuntimeException(String.format("时钟回拨: now: [%d] last: [%d]", timestamp, lastTimestampBak));
            }
        }

        if (timestamp != lastTimestampBak) {
            lastTimestampBak = timestamp;
            sequenceBak = 0L;
        }

        if (0L == (++sequenceBak & SEQUENCE_MAX)) {
            // 秒内序列用尽
// logger.warn("秒内[{}]序列用尽, 备份机器ID借取下一秒序列", timestamp);
            return nextIdBackup(timestamp + 1);
        }

        return ((timestamp - OFFSET) << OFFSET_SHIFT_BITS) | ((WORKER_ID ^ BACK_WORKER_ID_BEGIN) << WORKER_SHIFT_BITS) | sequenceBak;
    }

}
复制代码

Linux下System.currentTimeMillis()的性能问题

copy上面的ID生成算法你会发现有个报错找不到SystemClock.now(), 由于它并非JDK自带的类, 使用这个工具类生成时间戳的缘由是通过实测发现 Linux环境中高并发下System.currentTimeMillis()这个API对比Windows环境有近百倍的性能差距;

此问题的缘由分析博文: 缓慢的 System.currentTimeMillis();

百度简单搜索发现已有不少解决方案, 最简单直接的是起一个线程定时维护一个毫秒时间戳以覆盖JDK的System.currentTimeMillis(), 虽然这样当然会形成必定的时间精度问题, 但咱们的ID生成算法是秒级的Unix时间戳, 也不在意这几十微秒的偏差, 换来的倒是百倍的性能提高, 这是彻底值得的支出;

代码以下:

import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;

/** * 缓存时间戳解决System.currentTimeMillis()高并发下性能问题<br> * 问题根源分析: http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html * * @author: yangzc * @date: 2019-10-19 **/
public class SystemClock {

    private final long period;
    private final AtomicLong now;

    private SystemClock(long period) {
        this.period = period;
        this.now = new AtomicLong(System.currentTimeMillis());
        scheduleClockUpdating();
    }

    /** * 尝试下枚举单例法 */
    private enum SystemClockEnum {
        SYSTEM_CLOCK;
        private SystemClock systemClock;
        SystemClockEnum() {
            systemClock = new SystemClock(1);
        }
        public SystemClock getInstance() {
            return systemClock;
        }
    }

    /** * 获取单例对象 * @return com.cmallshop.module.core.commons.util.sequence.SystemClock */
    private static SystemClock getInstance() {
        return SystemClockEnum.SYSTEM_CLOCK.getInstance();
    }

    /** * 获取当前毫秒时间戳 * @return long */
    public static long now() {
        return getInstance().now.get();
    }

    /** * 起一个线程定时刷新时间戳 */
    private void scheduleClockUpdating() {
        ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(runnable -> {
            Thread thread = new Thread(runnable, "System Clock");
            thread.setDaemon(true);
            return thread;
        });
        scheduler.scheduleAtFixedRate(() -> now.set(System.currentTimeMillis()), period, period, TimeUnit.MILLISECONDS);
    }

}
复制代码

后记

了解了主流的各大公司开源的分布式ID生成方式最终选中了雪花算法, 经过这次改造总算是深刻了解了雪花算法的原理了, 同时也复习了一遍简单加减乘处的位运算, 总的来讲收获仍是颇丰的, 出来工做的时间也不算长, 在程序员大军中还算是年轻的一股经验有所不足, 若有错误请多指教, 借此慢慢培养本身写博客的习惯, 为了钱钱, 冲鸭!

Twitter雪花算法SnowFlake改造: 兼容JS截短位数的53bit分布式ID生成器

前言

对SnowFlake进行改造

命名空间划分(减小位长, 改成Unix的秒级时间戳)

时钟回拨问题(可用节点减半, 设置备份节点)

秒内自增序列用尽问题(向后借下一秒未分配的序列)

代码实现

Linux下System.currentTimeMillis()的性能问题

后记