Twitter的分布式自增ID算法snowflake (Java版)

最新推荐文章于 2024-07-26 17:24:18 发布
最新推荐文章于 2024-07-26 17:24:18 发布
阅读量3.4k 收藏 2
点赞数 2
分类专栏： java基础
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/a408308321/article/details/51187840
版权
本文介绍了Twitter的Snowflake算法，它用于生成全局唯一且时间有序的ID。Snowflake结构包含时间戳（41位）、数据中心ID（5位）、工作节点ID（5位）和序列号（12位）。通过这种方式，它能在分布式系统中避免ID冲突，并能以时间顺序生成ID，每秒可产生约26万个ID。
摘要由CSDN通过智能技术生成

概述

分布式系统中，有一些需要使用全局唯一ID的场景，这种时候为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。

有些时候我们希望能使用一种简单一些的ID，并且希望ID能够按照时间有序生成。

而twitter的snowflake解决了这种需求，最初Twitter把存储系统从MySQL迁移到Cassandra，因为Cassandra没有顺序ID生成机制，所以开发了这样一套全局唯一ID生成服务。

 

结构

snowflake的结构如下(每部分用-分开):

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）

一共加起来刚好64位，为一个Long型。(转换成字符串长度为18)

snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。据说：snowflake每秒能够产生26万个ID。

 

源码

(JAVA版本的源码)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
/** Snowflake */
最低0.47元/天 解锁文章
Aaronns
关注
专栏目录
Java 数据库主键生成类 IdWorker
05-05
高并发分布式系统中生成全局唯一Id汇总 数据在分片时，典型的是分库分表，就有一个全局ID生成的问题。 单纯的生成全局ID并不是什么难题，但是生成的ID通常要满足分片的一些要求： 1 不能有单点故障。 2 以时间为序，或者ID里包含时间。这样一是可以少一个索引，二是冷热数据容易分离。 3 可以控制ShardingId。比如某一个用户的文章要放在同一个分片内，这样查询效率高，修改也容易。 4 不要太长，最好64bit。使用long比较好操作，如果是96bit，那就要各种移位相当的不方便，还有可能有些组件不能支持这么大的ID。 一 twitter twitter在把存储系统从MySQL迁移到Cassandra的过程中由于Cassandra没有顺序ID生成机制，于是自己开发了一套全局唯一ID生成服务：Snowflake。 1 41位的时间序列（精确到毫秒，41位的长度可以使用69年） 2 10位的机器标识（10位的长度最多支持部署1024个节点） 3 12位的计数顺序号（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号） 最高位是符号位，始终为0。 优点：高性能，低延迟；独立的应用；按时间有序。 缺点：需要独立的开发和部署。 原理 java 实现代码 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 public class IdWorker { private final long workerId; private final static long twepoch = 1288834974657L; private long sequence = 0L; private final static long workerIdBits = 4L; public final static long maxWorkerId = -1L ^ -1L << workerIdBits; private final static long sequenceBits = 10L; private final static long workerIdShift = sequenceBits; private final static long timestampLeftShift = sequenceBits + workerIdBits; public final static long sequenceMask = -1L ^ -1L < this.maxWorkerId || workerId < 0) { throw new IllegalArgumentException(String.format( "worker Id can't be greater than %d or less than 0", this.maxWorkerId)); } this.workerId = workerId; } public synchronized long nextId() { long timestamp = this.timeGen(); if (this.lastTimestamp == timestamp) { this.sequence = (this.sequence + 1) & this.sequenceMask; if (this.sequence == 0) { System.out.println("###########" + sequenceMask); timestamp = this.tilNextMillis(this.lastTimestamp); } } else { this.sequence = 0; } if (timestamp < this.lastTimestamp) { try { throw new Exception( String.format( "Clock moved backwards. Refusing to generate id for %d milliseconds", this.lastTimestamp - timestamp)); } catch (Exception e) { e.printStackTrace(); } } this.lastTimestamp = timestamp; long nextId = ((timestamp - twepoch << timestampLeftShift)) | (this.workerId << this.workerIdShift) | (this.sequence); System.out.println("timestamp:" + timestamp + ",timestampLeftShift:" + timestampLeftShift + ",nextId:" + nextId + ",workerId:" + workerId + ",sequence:" + sequence); return nextId; } private long tilNextMillis(final long lastTimestamp) { long timestamp = this.timeGen(); while (timestamp <= lastTimestamp) { timestamp = this.timeGen(); } return timestamp; } private long timeGen() { return System.currentTimeMillis(); } public static void main(String[] args){ IdWorker worker2 = new IdWorker(2); System.out.println(worker2.nextId()); } }
IdWorker
zhanglong_longlong的专栏
11-11 4883
Skip to content Personal Open source Business Explore Sign upSign inPricingBlogSupport This repository Search Watch 1 Star 3 Fork 1 SimpleDays/IdWorker Code Issues 0 Pull requests 0 Projects 0
分布式ID详解
最新发布
努力分享一些干货内容，纯干货，没有一点水
07-26 942
在分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了，这个时候就需要生成分布式。适用于并发不高，但是数据量太大导致的分库分表扩容，可能每秒最高并发最多就几百，那么就走单独的一个库和表生成自增主键即可。雪花算法相对来说还是比较靠谱的，毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的，能达到百万计。生成，如果是高并发啥的，那么用这个应该性能比较好，一般每秒几万并发的场景，也足够用了。
分布式ID生成-雪花算法
ououaoligei的博客
10-30 384
分布式ID生成 - 雪花算法 项目中主键ID生成方式比较多，但是哪种方式更能提高的我们的工作效率、项目质量、代码实用性以及健壮性呢，下面作了一下比较，目前雪花算法的优点还是很明显的。 优缺点比较 UUID（缺点：太长、没法排序、使数据库性能降低） Redis（缺点：必须依赖Redis） Oracle序列号（缺点：用Oracle才能使用） Snowflake雪花算法，优点：生成有顺序的id，提高数据库的性能 Snowflake雪花算法解析 雪花算法解析 结构 snowflake的结构如下(每部分用-分开):
雪花算法&改造16位或者15位
热门推荐
程金鹏（程利鹏）
05-12 1万+
默认雪花算法，最大长度19位，前端需要使用string类型接收，不可以使用number接收。 对于老项目来说，将mysql自增id清洗为雪花算法id，前端需要改很很多东西，但是我们可以缩短雪花算法的最大长度，适应前端。当然可能会牺牲一部分工作节点数量或者每秒并发数量，但是对于中小型公司也是可以接受的。
雪花算法id长度_SnowflakeId雪花ID算法，分布式自增ID应用
weixin_39616961的博客
12-04 1333
概述snowflake是Twitter开源的分布式ID生成算法，结果是一个Long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID(5个bit是数据中心，5个bit的机器ID)，12bit作为毫秒内的序列号(意味着每个节点在每毫秒可以产生 4096 个 ID)，最后还有一个符号位，永远是0。特点：作为ID，肯定是唯一的；自增，依赖时间戳生成，序列号有序递增；支持非常大的业...
Java实现Twitter的分布式自增ID算法snowflake
09-07
【Java实现Twitter的分布式自增ID算法snowflake】 在分布式系统设计中，生成全局唯一ID是一个常见的需求。Twitter的Snowflake算法就是为了解决这个问题而诞生的，它提供了一种高效、有序且不会冲突的ID生成策略。...
Twitter的分布式自增ID雪花算法snowflake
01-24
综上所述，Twitter的雪花算法（Snowflake）提供了一种高效、简单的分布式ID生成方案，通过合理的结构设计，确保了全局唯一性和顺序性。在Java环境下，可以通过实现相应的类和方法轻松地引入这一机制，为分布式系统的...
SnowFlake：Twitter的分布式自增ID雪花算法snowflake（Java版）
02-06
而twitter的snowflake解决了这种需求，最初是Twitter把存储系统从MySQL迁移到Cassandra，因为Cassandra没有顺序的ID生成机制，所以开发了这样一套唯一的ID生成服务。结构雪花的结构如下（每部分用-分开）： 0 - ...
Twitter的分布式自增ID算法Snowflake的PHP实现,Snowflake PHP版本,高并发唯一id,全局唯一id,不重复id
10-28
Twitter Snowflake算法，php版代码； 请见博客： http://blog.csdn.net/envon123/article/details/52953872
ID自增JAVA类方法
12-20
ID自增的java类方法，不用数据库主键自增的可以考虑试试这个，自己定义方式
分布式ID生成解决方案——推特雪花算法
dandyjiew
07-25 278
对于某些应用，MySQL里的某个表可能会占用很大的存储空间，甚至让服务器硬盘满了，这时候就会涉及到数据库的分片，把一个数据库进行拆分，通过数据库中间件(MyCat)进行连接。 假设现在我们有三台服务器A B C，他们都含有一张表，然后应用通过数据库中间件进行连接，如果这个表某个字段使用数据自增，可能产生重复的ID。 采用分布式ID生成的解决方案： UUID (缺点：长度太长；没办法排序) ...
IdWorker工具类，自增长Id
无恙。的博客
05-24 2877
IdWorker工具类及使用 这个idwoker所生成的id是自增长的。 所用到的id是Long类型的，于uuid的String类型所不同; 话不多说，上工具类： public class IdWorker { /** * 这个就是代表了机器id */ private long workerId; // 这个就是代表了机房id private long datacenterId; // 这个就是代表了一毫秒内生成的多个id的最新序号 private long sequen
【SnowFlake】雪花算法（Java版本）
斯基的朦胧
08-03 1万+
SnowFlake雪花算法（Java版本）
Java实现雪花算法（SnowFlake）
qq_34042417的博客
07-04 8699
分布式id生成算法的有很多种，Twitter的SnowFlake就是其中经典的一种。 算法原理 SnowFlake算法生成id的结果是一个64bit大小的整数，它的结构如下图： 1bit，不用，因为二进制中最高位是符号位，1表示负数，0表示正数。生成的id一般都是用整数，所以最高位固定为0。 41bit-时间戳，用来记录时间戳，毫秒级。 - 41位可以表示个数字， - 如果只用来表示正整数（计算机中正数包含0），可以表示的数值范围是：0 至 ，减1是因为可表示的数值范围是从0开始
配置IdWorker ID生成工具
qq1192360489的博客
11-18 3693
配置IdWorker ID生成工具 dworker是一个ID生成工具，可以生成一个全局唯一的长整形ID。也支持分布式环境下的使用。idworker采用了Snowflake算法，并在此基础上增加了奇偶抖动功能，避免在低并发的环境下生成全是偶数的情况。 1.IdWorkerProperties 为配置类，用于封装 application.yml中配置信息 IdWorkerConfig 根据配置类ID...
分布式ID生成算法-雪花算法
彼岸舞的博客
11-15 2125
原因:为什么需要雪花算法 为什么需要分布式全局唯一ID以及分布式ID的业务需求？集群高并发情况下如何保证分布式唯一全局Id生成？ 在复杂分布式系统中，往往需婴对大量的数据和消息进行唯一标识，如在美团点评的金融、支付、餐饮、酒店，猫眼电影等产品的系统中数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息。特别一点的如订单、骑手、优惠券也都雷要有唯一ID做标识。此时一个能够生成全局...
实现高性能分布式 ID 生成器：Java 雪花算法详解
蜗牛的博客
03-30 2655
雪花算法（Snowflake）是 Twitter 开源的分布式 ID 生成算法，可以生成不重复的、有序的、可自增的 64 位 ID，适用于分布式系统中的 ID 生成需求。雪花算法的核心思想是将一个 64 位的 ID 按照一定的规则进行拆分，其中 41 位作为时间戳，10 位作为机器 ID，12 位作为序列号，保证了生成的 ID 全局唯一、有序、可自增。雪花算法的 ID 由以下几个部分组成：符号位：1 个 bit，始终为 0，用于区分正数和负数。时间戳：41 个 bit，精确到毫秒级别。
java生成5位分布式自增id
04-07
1. 可以使用Snowflake算法来生成分布式自增id，该算法是Twitter开源的一种生成分布式唯一ID的方法。 2. Snowflake算法的核心思想是将一个64位的long类型数字分为5个部分，分别是： a. 1位符号位：固定为0，不可...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值