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

简介: 写到这里,分布式Id算是写到最后一篇了,在这一篇里,我会讲到目前网上最适合分布式Id的方法,什么方法呢,请您往下看: 介绍Snowflake算法 SnowFlake算法是国际大公司Twitter的采用的一种生成分布式自增id的策略,这个算法产生的分布式id是足够我们我们中小公司在日常里面的使用了。

文章首发于我的个人博客,到个人博客体验更佳阅读哦

https://www.itqiankun.com/article/1565747019

写到这里,分布式Id算是写到最后一篇了,在这一篇里,我会讲到目前网上最适合分布式Id的方法,什么方法呢,请您往下看:

介绍Snowflake算法

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

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

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

1565746793_jpeg

这里我么来讲一下这个结构:首先因为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算法的源码如下所示(这个是我从网上找到的),这里我进行了测试了一波,结果如下所示

package com.hello;

import java.text.SimpleDateFormat;
import java.util.Date;

public class Test {
    /**
     * 开始时间截 (1970-01-01)
     */
    private final long twepoch = 0L;

    /**
     * 机器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;

    public Test(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;
    }

    /**
     * 获得下一个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();
    }

    public static void parseId(long id) {
        long miliSecond = id >>> 22;
        long shardId = (id & (0xFFF << 10)) >> 10;
        System.err.println("分布式id-"+id+"生成的时间是:"+new SimpleDateFormat("yyyy-MM-dd").format(new Date(miliSecond)));
    }

    public static void main(String[] args) {
        Test idWorker = new Test(0, 0);
        for (int i = 0; i < 10; i++) {
            long id = idWorker.nextId();
            System.out.println(id);
            parseId(id);
        }
    }
}

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

6566884785623400448
分布式id-6566884785623400448生成的时间是:2019-08-13
6566884785812144128
分布式id-6566884785812144128生成的时间是:2019-08-13
6566884785812144129
分布式id-6566884785812144129生成的时间是:2019-08-13
6566884785812144130
分布式id-6566884785812144130生成的时间是:2019-08-13
6566884785812144131
分布式id-6566884785812144131生成的时间是:2019-08-13
6566884785812144132
分布式id-6566884785812144132生成的时间是:2019-08-13
6566884785816338432
分布式id-6566884785816338432生成的时间是:2019-08-13
6566884785816338433
分布式id-6566884785816338433生成的时间是:2019-08-13
6566884785816338434
分布式id-6566884785816338434生成的时间是:2019-08-13
6566884785816338435
分布式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返回

package com.hello;

import java.text.SimpleDateFormat;
import java.util.Date;

public class Test {

    /**
     * 开始时间截 (1970-01-01)
     */
    private final long twepoch = 0L;

    /**
     * 机器id,范围是1到15
     */
    private final long workerId;

    /**
     * 机器id所占的位数,占4位
     */
    private final long workerIdBits = 4L;

    /**
     * 支持的最大机器id,结果是15
     */
    private final long maxWorkerId = ~(-1L << workerIdBits);

    /**
     * 生成序列占的位数
     */
    private final long sequenceBits = 15L;

    /**
     * 机器ID向左移15位
     */
    private final long workerIdShift = sequenceBits;

    /**
     * 生成序列的掩码,这里为最大是32767 (1111111111111=32767)
     */
    private final long sequenceMask = ~(-1L << sequenceBits);

    /**
     * 时间截向左移19位(4+15)
     */
    private final long timestampLeftShift = 19L;


    /**
     * 秒内序列(0~32767)
     */
    private long sequence = 0L;

    /**
     * 上次生成ID的时间截
     */
    private long lastTimestamp = -1L;


    public Test(long workerId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        this.workerId = workerId;
    }

    /**
     * 获得下一个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;
        //黄色代码注释开始
        //移位并通过或运算拼到一起组成53 位的ID
        return ((timestamp - twepoch) << timestampLeftShift)
            | (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()/1000L;
    }

    public static void parseId(long id) {
        long second = id >>> 19;
        System.err.println("分布式id-"+id+"生成的时间是:"+new SimpleDateFormat("yyyy-MM-dd").format(new Date(second*1000)));
    }

    public static void main(String[] args) {
        Test idWorker = new Test(0);
        for (int i = 0; i < 10; i++) {
            long id = idWorker.nextId();
            System.out.println(id);
            parseId(id);
        }
    }
}

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

820870564020224
分布式id-820870564020224生成的时间是:2019-08-13
820870564020225
分布式id-820870564020225生成的时间是:2019-08-13
820870564020226
分布式id-820870564020226生成的时间是:2019-08-13
820870564020227
分布式id-820870564020227生成的时间是:2019-08-13
820870564020228
分布式id-820870564020228生成的时间是:2019-08-13
820870564020229
分布式id-820870564020229生成的时间是:2019-08-13
820870564020230
分布式id-820870564020230生成的时间是:2019-08-13
820870564020231
分布式id-820870564020231生成的时间是:2019-08-13
820870564020232
分布式id-820870564020232生成的时间是:2019-08-13
820870564020233
分布式id-820870564020233生成的时间是:2019-08-13

雪法算法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吗

原文链接

大佬链接
https://www.itqiankun.com/article/1565747019

目录
相关文章
|
4月前
|
NoSQL 算法 安全
分布式锁—1.原理算法和使用建议
本文主要探讨了Redis分布式锁的八大问题,包括非原子操作、忘记释放锁、释放其他线程的锁、加锁失败处理、锁重入问题、锁竞争问题、锁超时失效及主从复制问题,并提供了相应的优化措施。接着分析了Redis的RedLock算法,讨论其优缺点以及分布式专家Martin对其的质疑。此外,文章对比了基于Redis和Zookeeper(zk)的分布式锁实现原理,包括获取与释放锁的具体流程。最后总结了两种分布式锁的适用场景及使用建议,指出Redis分布式锁虽有性能优势但模型不够健壮,而zk分布式锁更稳定但部署成本较高。实际应用中需根据业务需求权衡选择。
|
7月前
|
运维 NoSQL 算法
【📕分布式锁通关指南 04】redis分布式锁的细节问题以及RedLock算法原理
本文深入探讨了基于Redis实现分布式锁时遇到的细节问题及解决方案。首先,针对锁续期问题,提出了通过独立服务、获取锁进程自己续期和异步线程三种方式,并详细介绍了如何利用Lua脚本和守护线程实现自动续期。接着,解决了锁阻塞问题,引入了带超时时间的`tryLock`机制,确保在高并发场景下不会无限等待锁。最后,作为知识扩展,讲解了RedLock算法原理及其在实际业务中的局限性。文章强调,在并发量不高的场景中手写分布式锁可行,但推荐使用更成熟的Redisson框架来实现分布式锁,以保证系统的稳定性和可靠性。
325 0
【📕分布式锁通关指南 04】redis分布式锁的细节问题以及RedLock算法原理
|
8月前
|
存储 人工智能 算法
解锁分布式文件分享的 Java 一致性哈希算法密码
在数字化时代,文件分享成为信息传播与协同办公的关键环节。本文深入探讨基于Java的一致性哈希算法,该算法通过引入虚拟节点和环形哈希空间,解决了传统哈希算法在分布式存储中的“哈希雪崩”问题,确保文件分配稳定高效。文章还展示了Java实现代码,并展望了其在未来文件分享技术中的应用前景,如结合AI优化节点布局和区块链增强数据安全。
|
6月前
|
开发框架
osharp集成Yitter.IdGenerator并实现分布式ID
本文介绍了在 osharp 框架中集成 Yitter.IdGenerator 实现分布式 ID 的方法。osharp 是一个基于 .NET Core 的快速开发框架,而 Yitter.IdGenerator 是一种高效的分布式 ID 生成器。通过实现 `IKeyGenerator&lt;long&gt;` 接口并创建 `YitterSnowKeyGenerator` 类,结合 `YitterIdGeneratorPack` 模块化配置,实现了分布式环境下唯一 ID 的生成。
121 0
|
10月前
|
算法 关系型数据库 MySQL
分布式唯一ID生成:深入理解Snowflake算法在Go中的实现
在分布式系统中,确保每个节点生成的 ID 唯一且高效至关重要。Snowflake 算法由 Twitter 开发,通过 64 位 long 型数字生成全局唯一 ID,包括 1 位标识位、41 位时间戳、10 位机器 ID 和 12 位序列号。该算法具备全局唯一性、递增性、高可用性和高性能,适用于高并发场景,如电商促销时的大量订单生成。本文介绍了使用 Go 语言的 `bwmarrin/snowflake` 和 `sony/sonyflake` 库实现 Snowflake 算法的方法。
478 1
分布式唯一ID生成:深入理解Snowflake算法在Go中的实现
|
10月前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
337 8
|
9月前
|
存储 算法 安全
分布式系统架构1:共识算法Paxos
本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。
587 1
|
27天前
|
机器学习/深度学习 算法 新能源
【优化调度】基于matlab粒子群算法求解水火电经济调度优化问题研究(Matlab代码实现)
【优化调度】基于matlab粒子群算法求解水火电经济调度优化问题研究(Matlab代码实现)
|
28天前
|
算法 机器人 定位技术
基于机器视觉和Dijkstra算法的平面建筑群地图路线规划matlab仿真
本程序基于机器视觉与Dijkstra算法,实现平面建筑群地图的路径规划。通过MATLAB 2022A读取地图图像,识别障碍物并进行路径搜索,支持鼠标选择起点与终点,最终显示最优路径及长度,适用于智能导航与机器人路径规划场景。
|
29天前
|
机器学习/深度学习 算法 数据安全/隐私保护
基于PSO粒子群优化的XGBoost时间序列预测算法matlab仿真
本程序基于Matlab 2024b实现,结合粒子群优化(PSO)与XGBoost算法,用于时间序列预测。通过PSO优化XGBoost超参数,提升预测精度。程序包含完整注释与操作视频,运行后生成预测效果图及性能评估指标RMSE。

热门文章

最新文章