【Spring Cloud系列】 雪花算法原理及实现

这篇具有很好参考价值的文章主要介绍了【Spring Cloud系列】 雪花算法原理及实现。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

【Spring Cloud系列】 雪花算法原理及实现

一、概述

分布式高并发的环境下,常见的就是12306节日订票,在大量用户同是抢购一个方向的票,毫秒级的时间下可能生成数万个订单,此时为确保生成订单ID的唯一性变得至关重要。此时秒杀环境下,不仅要保障ID唯一性,还得确保ID生成的优先度。

二、生成ID规则部分硬性要求

  1. 全局唯一:不能出现重复的ID号,既然是唯一标识,这是最基本的要求。
  2. 趋势递增:在MySQL的InnoDB引擎中适用的是聚集索引,由于多数RDBMS使用B+Tree的数据结构来存储索引数据,在主键的选择上我们尽量使用有序的主键保证写入性能。
  3. 单调递增:保证下一个ID一定大于上一个ID,如事务版本号、排序等特殊需求。
  4. 信息安全:如果ID是连续的,恶意用户的抓取工作就非常容易,直接按照顺序下载指定URL即可;如果是订单号就危险。
  5. 含有时间戳:生成的ID包含完整的时间戳信息。

三、ID号生成系统可用性要求

  1. 高可用:发一个获取分布式ID的请求,服务器就是保证99.9999%的情况下给我创建一个唯一分布式ID。
  2. 低延迟:发一个获取分布式ID的请求,服务器要快,极速。
  3. 高QPS:如果一次请求10万个分布式ID,服务器要顶住并成功创建10万个分布式ID。

四、解决分布式ID通用方案

4.1 UUID

UUID(Universally Unique Identifier)的标准型式包含32个16进制数字,以连字号分为五段,形式为:8-4-4-4-12的36个字符,示例:1E785B2B-111C-752A-997B-3346E7495CE2;UUID性能非常高,不依赖网络,本地生成。

UUID缺点:

  1. 无序,无法预测它的生成顺序,不能生成递增有序的数字。在MySql官方推荐主键约短越好,UUID是一个32位的字符串,所以不推荐使用。

  2. 索引,B+Tree索引的分裂

    分布式Id是主键,主键是聚簇索引。Mysql的索引是B+Tree来实现的,每次新的UUID数据的插入,为了新的UUID数据的插入,为了查询的优化,都会对索引底部的B+Tree进行修改;因为UUID数据是无序的,所以每一次UUID数据的插入都会对主键的聚簇索引做很大的修改,在做数据Insert时,会插入主键是无序的,会导致一些中间节点的产生分裂,会导致大量不饱和的节点。这样大大降低了数据库插入的性能。

4.2 数据库自增主键

单机

在分布式里面,数据库的自增ID机制的主要原理是:数据库自增ID和MySql数据库的replace into实现的。

Replace into的含义是插入一条纪录,如果表中唯一索引的值遇到冲突,则替换老数据。

在单体应用的时候,自增长ID使用,但是在集群分布式应用中单体应用就不适合。

  1. 系统水平扩展比较困难,比如定义好了增长步长和机器台数之后,在大量添加服务器时,需要重新设置初始值,这样可操作性差,所以系统水平扩展方案复杂度高难以实现。
  2. 数据库压力大,每次获取ID都需要读写一次数据库,非常影响性能,不符合分布式ID里面的延迟低和要高QPS的规则(在高并发下,如果都去数据库里面获取Id,非常影响性能的。)

4.3 基于Redis生成全局id策略

在Redis集群情况下,同样和MySql一样需要设置不同的增长步长,同时key一定要设置有效期。可以使用Redis集群来获取更高的吞吐量。

五、SnowFlake(雪花算法)

而Twitter的SnowFlake解决了这种需求,最初Twitter把存储系统从MySQL迁移到Cassandra(由Facebook开发一套开源分布式NoSQL数据库系统) 因为Cassandra没有顺序ID生成机制,所以开发了这样一套全局唯一ID生成服务。SnowFlake每秒能产生26万个自增可排序的ID。

5.1 SnowFlake特点

  1. Twitter的SnowFlake生成ID能够按照时间有序生成。
  2. SnowFlake算法生成Id的结果是一个64bit大小的整数,为一个Long型(转换成字符串后长度最多19)。
  3. 分布式系统内不会产生ID碰撞(由datacenter和workerid作为区分)并且效率较高。

5.2 SnowFlake结构

【Spring Cloud系列】 雪花算法原理及实现,Spring Cloud,JAVA,spring cloud,算法,spring

5.3 雪花算法原理

雪花算法的原理就是生成一个的64位比特位的long类型的唯一id

  1. 最高1位固定值0,因为生成的id是正整数,如果是1就是负值。
  2. 紧接着是41位存储毫秒级时间戳,2^41/(1000 * 60 * 24 * 365) = 69 ,大概可以使用69年。
  3. 接下来10位存储机器码,包括5位DataCenterId和5位WorkerId,最多可以部署2^10=1024台机器。
  4. 最后12位存储序列号,同一毫秒时间戳时,通过这个递增的序列号来区分,即对于同一台机器而言,同一毫秒级时间戳下,可以生成2^12=4096个不重复id。

可以将雪花算法作为一个单独的服务进行部署,然后需要全局唯一id的系统,请求雪花算法服务获取id即可。

对于每一个雪花算法服务,需要先指定10位的机器码,这个根据自身业务进行设定即可。例如机房号+机器号,机器号+服务号,或者时其他区别标识的10位比特位的整数都行。

5.4 算法实现

package com.goyeer;
import java.util.Date;

/**
 * @ClassName: SnowFlakeUtil
 * @Author: goyeer
 * @Date: 2023/09/09 19:34
 * @Description:
 */
public class SnowFlakeUtil {

    private static SnowFlakeUtil snowFlakeUtil;
    static {
        snowFlakeUtil = new SnowFlakeUtil();
    }

    // 初始时间戳(纪年),可用雪花算法服务上线时间戳的值
    //
    private static final long INIT_EPOCH = 1694263918335L;

    // 时间位取&
    private static final long TIME_BIT = 0b1111111111111111111111111111111111111111110000000000000000000000L;

    // 记录最后使用的毫秒时间戳,主要用于判断是否同一毫秒,以及用于服务器时钟回拨判断
    private long lastTimeMillis = -1L;

    // dataCenterId占用的位数
    private static final long DATA_CENTER_ID_BITS = 5L;

    // dataCenterId占用5个比特位,最大值31
    // 0000000000000000000000000000000000000000000000000000000000011111
    private static final long MAX_DATA_CENTER_ID = ~(-1L << DATA_CENTER_ID_BITS);

    // dataCenterId
    private long dataCenterId;

    // workId占用的位数
    private static final long WORKER_ID_BITS = 5L;

    // workId占用5个比特位,最大值31
    // 0000000000000000000000000000000000000000000000000000000000011111
    private static final long MAX_WORKER_ID = ~(-1L << WORKER_ID_BITS);

    // workId
    private long workerId;

    // 最后12位,代表每毫秒内可产生最大序列号,即 2^12 - 1 = 4095
    private static final long SEQUENCE_BITS = 12L;

    // 掩码(最低12位为1,高位都为0),主要用于与自增后的序列号进行位与,如果值为0,则代表自增后的序列号超过了4095
    // 0000000000000000000000000000000000000000000000000000111111111111
    private static final long SEQUENCE_MASK = ~(-1L << SEQUENCE_BITS);

    // 同一毫秒内的最新序号,最大值可为 2^12 - 1 = 4095
    private long sequence;

    // workId位需要左移的位数 12
    private static final long WORK_ID_SHIFT = SEQUENCE_BITS;

    // dataCenterId位需要左移的位数 12+5
    private static final long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS;

    // 时间戳需要左移的位数 12+5+5
    private static final long TIMESTAMP_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATA_CENTER_ID_BITS;

    /**
     * 无参构造
     */
    public SnowFlakeUtil() {
        this(1, 1);
    }

    /**
     * 有参构造
     * @param dataCenterId
     * @param workerId
     */
    public SnowFlakeUtil(long dataCenterId, long workerId) {
        // 检查dataCenterId的合法值
        if (dataCenterId < 0 || dataCenterId > MAX_DATA_CENTER_ID) {
            throw new IllegalArgumentException(
                    String.format("dataCenterId 值必须大于 0 并且小于 %d", MAX_DATA_CENTER_ID));
        }
        // 检查workId的合法值
        if (workerId < 0 || workerId > MAX_WORKER_ID) {
            throw new IllegalArgumentException(String.format("workId 值必须大于 0 并且小于 %d", MAX_WORKER_ID));
        }
        this.workerId = workerId;
        this.dataCenterId = dataCenterId;
    }

    /**
     * 获取唯一ID
     * @return
     */
    public static Long getSnowFlakeId() {
        return snowFlakeUtil.nextId();
    }

    /**
     * 通过雪花算法生成下一个id,注意这里使用synchronized同步
     * @return 唯一id
     */
    public synchronized long nextId() {
        long currentTimeMillis = System.currentTimeMillis();
        System.out.println(currentTimeMillis);
        // 当前时间小于上一次生成id使用的时间,可能出现服务器时钟回拨问题
        if (currentTimeMillis < lastTimeMillis) {
            throw new RuntimeException(
                    String.format("可能出现服务器时钟回拨问题,请检查服务器时间。当前服务器时间戳:%d,上一次使用时间戳:%d", currentTimeMillis,
                            lastTimeMillis));
        }
        if (currentTimeMillis == lastTimeMillis) {
            // 还是在同一毫秒内,则将序列号递增1,序列号最大值为4095
            // 序列号的最大值是4095,使用掩码(最低12位为1,高位都为0)进行位与运行后如果值为0,则自增后的序列号超过了4095
            // 那么就使用新的时间戳
            sequence = (sequence + 1) & SEQUENCE_MASK;
            if (sequence == 0) {
                currentTimeMillis = getNextMillis(lastTimeMillis);
            }
        } else { // 不在同一毫秒内,则序列号重新从0开始,序列号最大值为4095
            sequence = 0;
        }
        // 记录最后一次使用的毫秒时间戳
        lastTimeMillis = currentTimeMillis;
        // 核心算法,将不同部分的数值移动到指定的位置,然后进行或运行
        // <<:左移运算符, 1 << 2 即将二进制的 1 扩大 2^2 倍
        // |:位或运算符, 是把某两个数中, 只要其中一个的某一位为1, 则结果的该位就为1
        // 优先级:<< > |
        return
                // 时间戳部分
                ((currentTimeMillis - INIT_EPOCH) << TIMESTAMP_SHIFT)
                        // 数据中心部分
                        | (dataCenterId << DATA_CENTER_ID_SHIFT)
                        // 机器表示部分
                        | (workerId << WORK_ID_SHIFT)
                        // 序列号部分
                        | sequence;
    }

    /**
     * 获取指定时间戳的接下来的时间戳,也可以说是下一毫秒
     * @param lastTimeMillis 指定毫秒时间戳
     * @return 时间戳
     */
    private long getNextMillis(long lastTimeMillis) {
        long currentTimeMillis = System.currentTimeMillis();
        while (currentTimeMillis <= lastTimeMillis) {
            currentTimeMillis = System.currentTimeMillis();
        }
        return currentTimeMillis;
    }

    /**
     * 获取随机字符串,length=13
     * @return
     */
    public static String getRandomStr() {
        return Long.toString(getSnowFlakeId());
    }

    /**
     * 从ID中获取时间
     * @param id 由此类生成的ID
     * @return
     */
    public static Date getTimeBySnowFlakeId(long id) {
        return new Date(((TIME_BIT & id) >> 22) + INIT_EPOCH);
    }

    public static void main(String[] args) {
        SnowFlakeUtil snowFlakeUtil = new SnowFlakeUtil();
        long id = snowFlakeUtil.nextId();

        System.out.println(id);
        Date date = SnowFlakeUtil.getTimeBySnowFlakeId(id);
        System.out.println(date);
        long time = date.getTime();
        System.out.println(time);
        System.out.println(getRandomStr());

    }

}

5.4 雪花算法优点

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

5.5 雪花算法缺点:

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

六、总结

其实雪花算法每一部分占用的比特位数量并不是固定死的。例如你的业务可能达不到 69 年之久,那么可用减少时间戳占用的位数,雪花算法服务需要部署的节点超过1024 台,那么可将减少的位数补充给机器码用。

注意,雪花算法中 41 位比特位不是直接用来存储当前服务器毫秒时间戳的,而是需要当前服务器时间戳减去某一个初始时间戳值,一般可以使用服务上线时间作为初始时间戳值。

对于机器码,可根据自身情况做调整,例如机房号,服务器号,业务号,机器 IP 等都是可使用的。对于部署的不同雪花算法服务中,最后计算出来的机器码能区分开来即可。文章来源地址https://www.toymoban.com/news/detail-705615.html

到了这里,关于【Spring Cloud系列】 雪花算法原理及实现的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Spring Cloud】Ribbon 实现负载均衡的原理,策略以及饥饿加载

    在前文《深入理解 Eureka 注册中心的原理、服务的注册与发现》中,介绍了如何使用 Eureka 实现服务的注册与拉取,并且通过添加 @LoadBalanced 注解实现了负载均衡。这种自动化的背后隐藏着许多疑问: 服务是在何时进行拉取的? 负载均衡是如何实现的? 负载均衡的原理和策略

    2024年02月07日
    浏览(47)
  • 【Spring云原生系列】SpringBoot+Spring Cloud Stream:消息驱动架构(MDA)解析,实现异步处理与解耦合!

    🎉🎉 欢迎光临,终于等到你啦 🎉🎉 🏅我是 苏泽 ,一位对技术充满热情的探索者和分享者。🚀🚀 🌟持续更新的专栏 《Spring 狂野之旅:从入门到入魔》 🚀 本专栏带你从Spring入门到入魔   这是苏泽的个人主页可以看到我其他的内容哦👇👇 努力的苏泽 http://suzee.blog.

    2024年03月10日
    浏览(53)
  • Java版知识付费源码 Spring Cloud+Spring Boot 前后端分离实现知识付费平台

     提供职业教育、企业培训、知识付费系统搭建服务。系统功能包含:录播课、直播课、题库、营销、公司组织架构、员工入职培训等。 提供私有化部署,免费售后,专业技术指导,支持PC、APP、H5、小程序多终端同步,支持二次开发定制,源码交付。   Java版知识付费-轻松

    2024年02月15日
    浏览(52)
  • 【Spring Cloud系列】Spring Cloud-网关Zuul详解与实战

    Spring Cloud Zuul 是 Spring Cloud Netflix 子项目的核心组件之一,是netflix开源的一个API Gateway服务器,本质上有一个Web Servlet应用,可以作为微服务架构中的 API 网关使用,支持动态路由与过滤功能;网关为微服务提供统一的访问入口;网关的定义类似设计模式中的门面模式,相当于

    2024年02月08日
    浏览(44)
  • java版工程管理系统Spring Cloud+Spring Boot+Mybatis实现工程管理系统源码

     工程项目管理软件(工程项目管理系统)对建设工程项目管理组织建设、项目策划决策、规划设计、施工建设到竣工交付、总结评估、运维运营,全过程、全方位的对项目进行综合管理    工程项目各模块及其功能点清单 一、系统管理     1、数据字典:实现对数据字典

    2024年02月07日
    浏览(47)
  • Java版知识付费源码 Spring Cloud+Spring Boot+Mybatis+uniapp+前后端分离实现知识付费平台

    知识付费平台主要指的是能够通过付费来满足用户知识需求的平台,用户可以通过该平台来消费知识或者开展知识买卖等行为。   此处的平台是一个广义的概念,可以是微信小程序或者论坛,也可以是网页或者手机APP,等,就我国的情况而言,在知识付费平台发展初期,平台

    2024年02月16日
    浏览(58)
  • 【Spring Cloud】Spring Cloud Alibaba-- 分布式事务Seata原理

    Seata 是一款开源的分布式事务解决方案,致力于提供高性能与简单易用的分布式事务服务,为用户提供了 AT、TCC、SAGA 和 XA 几种不同的事务模式: AT模式:无侵入式的分布式事务解决方案,适合不希望对业务进行改造的场景,但由于需要添加全局事务锁,对影响高并发系统的

    2024年02月08日
    浏览(78)
  • 系列十、Spring Cloud Gateway

            Spring Cloud全家桶中有个很重要的组件就是网关,在1.x版本中采用的是Zuul网关,但是在2.x版本中,由于Zuul的升级一直跳票,Spring Cloud最后自己研发了一个网关替代Zuul,即:Spring Cloud Gateway。简单点讲Gateway就是原Zuul1.x版的替代品。 (一)neflix不太靠谱,zuul2.0一直跳

    2024年02月03日
    浏览(34)
  • Spring Cloud Zuul 基本原理

    Spring Cloud Zuul 底层是基于Servlet实现的,核心是通过一系列的ZuulFilter来完成请求的转发。 启用Zuul作为微服务网关,需要在Application应用类加上@EnableZuulProxy注解,而该注解核心是利用@Import注解往Spring容器导入了ZuulProxyConfiguration配置类 ZuulProxyConfiguration继承了ZuulConfiguration。 1

    2024年02月07日
    浏览(40)
  • 19套项目实战系列--Spring Cloud Spring Boot(整套源码)

    整套大型项目源码,需要的回复私信:19 ┃ ┃ ┃ ┣━1-3 项目微服务架构图【课前必知】.vep ┃ ┃ ┃ ┣━1-4 项目技术架构图【课前必知】.vep ┃ ┃ ┃ ┣━10-1 接口解耦需求【章节概述】.vep ┃ ┃ ┃ ┣━10-12 实现文章的定时延迟发布【延迟队列】.vep ┃ ┃ ┃ ┣━10-2 Rabb

    2024年02月15日
    浏览(95)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包