分布式ID生成策略 · fossi

分布式环境下如何保证ID的不重复呢?一般我们可能会想到用UUID来实现嘛。但是UUID一般可以获取当前时间的毫秒数再加点随机数,但是在高并发下仍然可能重复。最重要的是,如果我要用这种UUID来生成分表的唯一ID的话,重复不谈,这种随机的字符串对于我们的innodb存储引擎的插入效率是很低的。所以我们生成的ID如果作为主键,最好有两种特性:分布式唯一和有序。

唯一性就不用说了,有序保证了对索引字段的插入的高效性。我们来具体看看ShardingJDBC的分布式ID生成策略是如何保证。

snowflake算法

sharding-jdbc的分布式ID采用twitter开源的snowflake算法,不需要依赖任何第三方组件,这样其扩展性和维护性得到最大的简化;但是snowflake算法的缺陷(强依赖时间,如果时钟回拨,就会生成重复的ID)。

雪花算法是由Twitter公布的分布式主键生成算法,它能够保证不同进程主键的不重复性,以及相同进程主键的有序性

在同一个进程中,它首先是通过时间位保证不重复,如果时间相同则是通过序列位保证。 同时由于时间位是单调递增的,且各个服务器如果大体做了时间同步,那么生成的主键在分布式环境可以认为是总体有序的,这就保证了对索引字段的插入的高效性。例如MySQL的Innodb存储引擎的主键。

使用雪花算法生成的主键,二进制表示形式包含4部分,从高位到低位分表为:1bit符号位、41bit时间戳位、10bit工作进程位以及12bit序列号位。

大专栏  分布式ID生成策略 · fossi

雪花算法主键的详细结构见下图。

  • 符号位(1bit)

预留的符号位,恒为零。

  • 时间戳位(41bit)

41位的时间戳可以容纳的毫秒数是2的41次幂,一年所使用的毫秒数是:365 * 24 * 60 * 60 * 1000。通过计算可知:

1
Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L);

结果约等于69.73年。ShardingSphere的雪花算法的时间纪元从2016年11月1日零点开始,可以使用到2086年,相信能满足绝大部分系统的要求。

  • 工作进程位(10bit)

该标志在Java进程内是唯一的,如果是分布式应用部署应保证每个工作进程的id是不同的。该值默认为0,可通过调用静态方法DefaultKeyGenerator.setWorkerId()设置。

  • 序列号位(12bit)

该序列是用来在同一个毫秒内生成不同的ID。如果在这个毫秒内生成的数量超过4096(2的12次幂),那么生成器会等待到下个毫秒继续生成。

时钟回拨

服务器时钟回拨会导致产生重复序列,因此默认分布式主键生成器提供了一个最大容忍的时钟回拨毫秒数。 如果时钟回拨的时间超过最大容忍的毫秒数阈值,则程序报错;如果在可容忍的范围内,默认分布式主键生成器会等待时钟同步到最后一次主键生成的时间后再继续工作。 最大容忍的时钟回拨毫秒数的默认值为0,可通过调用静态方法DefaultKeyGenerator.setMaxTolerateTimeDifferenceMilliseconds()设置。

原文地址:https://www.cnblogs.com/lijianming180/p/12041145.html

时间: 2024-08-30 09:19:30

分布式ID生成策略 · fossi的相关文章

【数据库】总结常用分布式ID生成策略

1. SequenceID 数据库自增列,最常见的方式.由数据库维护,数据库唯一. 优点: 1)简单,代码方便,性能可以接受. 2)数字ID天然排序,对分页或者需要排序的结果很有帮助. 缺点: 1)数据迁移或者合库麻烦. 2)分表分库的时候麻烦. 改进方案: 通过设置各数据库的步长,或者通过HASH进行分表. 2. GUID 微软对UUID这个标准的实现.UUID(Universally Unique Identifier)的标准型式包含32个16进制数字,以连字号分为五段,形式为8-4-4-4

Disruptor分布式id生成策略

需要的pom文件: <!-- 顺序UUID --> <dependency> <groupId>com.fasterxml.uuid</groupId> <artifactId>java-uuid-generator</artifactId> <version>3.1.4</version> </dependency> 有时间顺序: import com.fasterxml.uuid.Etherne

业务ID 生成策略

业务ID 生成策略,从技术上说,基本要借助一个集中式的引擎来帮忙实现. 为了扩大业务ID生成策略的并发问题,还有更为技巧性的提升. 先来介绍普遍的分布式ID生成策略: 1. 利用DB的自增主键 这里又有两种做法,一种是 单独创建一个只有自增主键的表,来负责主键自增,业务表从这里取得自增的主键返回给业务主键生成组件使用. 另外一种: 业务中不使用DB的自增主键, 自增主键仅存在DB层面,并增加业务主键字段,并加以约束.这种比较常见. 通常的步骤为: A. Create table `tbl_biz

常见分布式全局唯一ID生成策略

全局唯一的 ID 几乎是所有系统都会遇到的刚需.这个 id 在搜索, 存储数据, 加快检索速度 等等很多方面都有着重要的意义.工业上有多种策略来获取这个全局唯一的id,针对常见的几种场景,我在这里进行简单的总结和对比. 简单分析一下需求 [1] 所谓全局唯一的 id 其实往往对应是生成唯一记录标识的业务需求. 这个 id 常常是数据库的主键,数据库上会建立聚集索引(cluster index),即在物理存储上以这个字段排序.这个记录标识上的查询,往往又有分页或者排序的业务需求.所以往往要有一个t

分布式ID生成方案

分布式ID生成方案(分布式数据库) 背景:在互联网应用中,应用需要为每一个用户分配一个id,在使用分布式数据库情况下,已经不能依靠自增主键来生成唯一性id了... 根据特定算法生成唯一ID 可重现的id生成方案:使用用户提供的特定的数据源(登录凭证),通过某种算法生成id,这个过程是可重现的,只要用户提供的数据源是唯一的,那么生成的id也是唯一的. 例如通过用户注册的email+salt,使用摘要算法(md5/sha)生成128bit的数据,然后通过混合因子转变为一个long类型的数据是64bi

数据库主键ID生成策略

前言: 系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,下面介绍一些常见的ID生成策略. Sequence ID UUID GUID COMB Snowflake 最开始的自增ID为了实现分库分别的需求,会在自增的前提下,使用不同起点,但需要做数据库拓展时,极其麻烦. 比如刚开始时,我们设计某个系统的数据库时,这个数据库中会有10个表,那么我们对于每个表的内容都需要不同的ID我们就可以使用不同不长自增的形式,比如,第一张表的是1.11.21.31... 第二张表是2.12.22.32..

分布式ID生成

在看代码的时候遇到一个snowflake算法,查了一下发现是Twitter的一个分布式ID生成算法,能够在分布式环境中生成一个全局唯一的ID,然后上网找了一些业界的做法,目前看到了携程和美团的方案,做一下笔记. 背景1 在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识.如在美团点评的金融.支付.餐饮.酒店.猫眼电影等产品的系统中,数据日渐增长,对数据分库分表后需要有一个唯一ID来标识一条数据或消息,数据库的自增ID显然不能满足需求:特别一点的如订单.骑手.优惠券也都需要有唯一ID做标识

详解分布式系统中的唯一id生成策略

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结.生成ID的方法有很多,适应不同的场景.需求以及性能要求.所以有些比较复杂的系统会有多个ID生成的策略.下面就介绍一些常见的ID生成策略. 平常应用中方式很多 1. 数据库自增长序列或字段 2. UUID 3.uuid的变种 4.redis生成 5. Twitter的snowflake算法 snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID.其核心思想是:使用41bit作为毫秒数,1

融云技术分享:解密融云IM产品的聊天消息ID生成策略

本文来自融云技术团队原创分享,原文发布于“融云全球互联网通信云”公众号,原题<如何实现分布式场景下唯一 ID 生成?>,即时通讯网收录时有部分改动. 1.引言 对于IM应用来说,消息ID(或称序列号)是个看似不起眼,但非常重要的东西之一. 消息ID的使用贯穿了IM技术逻辑的方方面面,比如: 1)聊天消息的顺序保证: 2)聊天消息QoS送达保证机制时的去重: 3)特定聊天消息的精确查找和匹配: 4)聊天消息的已读未读处理: 5)聊天消息的送达回执: 6)群聊消息的扩散读拉取标记: 7)... .