博客分类：
Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统中不同机器产生的id必须不同。
Snowflake算法核心
把时间戳，工作机器id，序列号组合在一起。
除了最高位bit标记为不可用以外，其余三组bit占位均可浮动，看具体的业务需求而定。默认情况下41bit的时间戳可以支持该算法使用到2082年，10bit的工作机器id可以支持1023台机器，序列号支持1毫秒产生4095个自增序列id。下文会具体分析。
Snowflake – 时间戳
这里时间戳的细度是毫秒级，具体代码如下，建议使用64位linux系统机器，因为有，gettimeofday()在用户态就可以完成操作，减少了进入内核态的损耗。
uint64_t generateStamp()
gettimeofday(&tv, 0);
return (uint64_t)tv.tv_sec * 1000 + (uint64_t)tv.tv_usec / 1000;
默认情况下有41个bit可以供使用，那么一共有T（1llu && 41）毫秒供你使用分配，年份 = T / (3600 * 24 * 365 * 1000) = 69.7年。如果你只给时间戳分配39个bit使用，那么根据同样的算法最后年份 = 17.4年。
Snowflake – 工作机器id
严格意义上来说这个bit段的使用可以是进程级，机器级的话你可以使用MAC地址来唯一标示工作机器，工作进程级可以使用IP+Path来区分工作进程。如果工作机器比较少，可以使用配置文件来设置这个id是一个不错的选择，如果机器过多配置文件的维护是一个灾难性的事情。
这里的解决方案是需要一个工作id分配的进程，可以使用自己编写一个简单进程来记录分配id，或者利用Mysql auto_increment机制也可以达到效果。
工作进程与工作id分配器只是在工作进程启动的时候交互一次，然后工作进程可以自行将分配的id数据落文件，下一次启动直接读取文件里的id使用。
PS：这个工作机器id的bit段也可以进一步拆分，比如用前5个bit标记进程id，后5个bit标记线程id之类:D
Snowflake – 序列号
序列号就是一系列的自增id（多线程建议使用atomic），为了处理在同一毫秒内需要给多条消息分配id，若同一毫秒把序列号用完了，则“等待至下一毫秒”。
uint64_t waitNextMs(uint64_t lastStamp)
uint64_t cur = 0;
cur = generateStamp();
} while (cur &= lastStamp);
总体来说，是一个很高效很方便的GUID产生算法，一个int64_t字段就可以胜任，不像现在主流128bit的GUID算法，即使无法保证严格的id序列性，但是对于特定的业务，比如用做游戏服务器端的GUID产生会很方便。另外，在多线程的环境下，序列号使用atomic可以在代码实现上有效减少锁的密度。
0 --- 00000 ---00000 --- 00
在上面的字符串中，第一位为未使用（实际上也可作为long的符号位），接下来的41位为毫秒级时间，然后5位datacenter标识位，5位机器ID（并不算标识符，实际是为线程标识），然后12位该毫秒内的当前毫秒内的计数，加起来刚好64位，为一个Long型。
这样的好处是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和机器ID作区分），并且效率较高，经测试，snowflake每秒能够产生26万ID左右，完全满足需要。
public class IdWorker {
private final long
private final static long twepoch
private long
private final static long workerIdBits
private final static long maxWorkerId
= -1L ^ -1L && workerIdB
private final static long sequenceBits
private final static long workerIdShift
= sequenceB
private final static long timestampLeftShift = sequenceBits + workerIdB
private final static long sequenceMask
= -1L ^ -1L && sequenceB
private long
lastTimestamp
public IdWorker(final 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;
public synchronized long nextId() {
long timestamp = this.timeGen();
if (this.lastTimestamp == timestamp) {
this.sequence = (this.sequence + 1) & sequenceM
if (this.sequence == 0) {
System.out.println("###########" + sequenceMask);
timestamp = this.tilNextMillis(this.lastTimestamp);
this.sequence = 0;
if (timestamp & this.lastTimestamp) {
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 =
long nextId = ((timestamp - twepoch && timestampLeftShift))
| (this.workerId && 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();
private long timeGen() {
return System.currentTimeMillis();
public static void main(String[] args) throws InterruptedException {
IdWorker worker2 = new IdWorker(2);
System.out.println(worker2.nextId());
Thread.sleep(1000L);
System.out.println(worker2.nextId());
Reference:
浏览: 240347 次
来自: 上海
popu_12 写道Can you please explai ...
Can you please explain neighbor ...
网站所有者也是www吗？ 你这样做很不安全？详细原因见分析：正 ...
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'Twitter-Snowflake，64位自增ID算法详解 - 漫漫路
Twitter-Snowflake，64位自增ID算法详解 - 漫漫路Twitter的分布式自增ID算法Snowflake
Twitter早期使用MySQL存储数据，随着用户的增长，单一MySQL实例无法支持海量数据，Twitter开始把存储系统从MySQL迁移到Cassandra，但是Cassandra没有内置的顺序ID生成机制，因此Twitter开发了一套分布式系统全局唯一ID生成服务：Snowflake。
Twitter早期使用MySQL存储数据，随着用户的增长，单一MySQL实例无法支持海量数据，Twitter开始把存储系统从MySQL迁移到Cassandra，但是Cassandra没有内置的顺序ID生成机制，因此Twitter开发了一套分布式系统全局唯一ID生成服务：Snowflake。
对于Twitter而言，必须满足每秒上万条消息的请求，并且每条消息能够分配一个全局唯一的ID，因此，ID生成服务要求必须满足高性能（&10K ids/s）、低延迟（&2ms）、高可用的特性，同时生成的ID还可以进行大致的排序，以方便客户端的排序。
Snowflake满足了以上的需求。Snowflake生成的每一个ID都是64位的整型数，它的核心算法也比较简单高效，结构如下：
41位的时间序列，精确到毫秒级，41位的长度可以使用69年。时间位还有一个很重要的作用是可以根据时间进行排序。
10位的机器标识，10位的长度最多支持部署1024个节点。
12位的计数序列号，序列号即一系列的自增id，可以支持同一节点同一毫秒生成多个ID序号，12位的计数序列号支持每个节点每毫秒产生4096个ID序号。
最高位是符号位，始终为0，不可用。
Snowflake是一个高效方便的GUID生成算法，可用性强，速度快并且可以根据时间排序。但是，就目前来看部署Snowflake需要引入ZooKeeper和Snowflake专用服务器，Twitter也声明希望可以让Snowflake运行在Twitter以外更多的环境中，如果可以实现，Snowflake的使用就会更方便。
Snowflake是用Scala实现的，如果想要了解更多细节，请移步至Snowflake项目。
====================================分割线================================
本文转自d1net（转载）
版权声明：本文内容由互联网用户自发贡献，本社区不拥有所有权，也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至： 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
用云栖社区APP，舒服~
【云栖快讯】他，一路保送，但可能不是你想象中的学霸； 他，曾是微软最年轻的技术管理者，挑战带领跨国团队； 他，后来加入阿里，成为阿里西雅图分部的第22名员工；
他，就是阿里通用计算平台负责人关涛！ 云栖社区通过短视频，为你揭晓他的成长和开发计算平台的经历，以及他对未来的展望！&&
充分利用阿里云现有资源管理和服务体系，引入中间件成熟的整套分布式计算框架，以应用为中心，帮助企业级客户轻松构建并...
一种稳定、可靠、容量和服务能力可弹性伸缩的分布式关系型数据库服务。
用于实时预测用户对物品偏好，支持企业定制推荐算法，支持A/B Test效果对比
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
社区之星年度评选，投票可抽奖
Loading...分布式系统中，有一些需要使用全局唯一ID的场景，这种时候为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。
有些时候我们希望能使用一种简单一些的ID，并且希望ID能够按照时间有序生成。
而twitter的snowflake解决了这种需求，最初Twitter把存储系统从MySQL迁移到Cassandra，因为Cassandra没有顺序ID生成机制，所以开发了这样一套全局唯一ID生成服务。
snowflake是twitter开源的分布式ID生成算法，其核心思想是：一个long型的ID，使用其中41bit作为毫秒数，10bit作为机器编号，12bit作为毫秒内序列号。这个算法单机每秒内理论上最多可以生成)，也就是400W的ID，完全能满足一般业务的需求。
snowflake的结构如下(每部分用-分开):
0 - 00000 - 00000 -
第一位为未使用，接下来的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版本的源码)
package com.yy.
* Twitter_Snowflake&br&
* SnowFlake的结构如下(每部分用-分开):&br&
0 - 00000 - 00000 -
* 1位标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0&br&
* 41位时间截(毫秒级)，注意，41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)
* 得到的值），这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的（如下下面程序IdWorker类的startTime属性）。41位的时间截，可以使用69年，年T = (1L && 41) / (1000L * 60 * 60 * 24 * 365) = 69&br&
* 10位的数据机器位，可以部署在1024个节点，包括5位datacenterId和5位workerId&br&
* 12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号&br&
* 加起来刚好64位，为一个Long型。&br&
* SnowFlake的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右。
public class SnowflakeIdWorker {
/** 开始时间截 () */
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 = sequenceB
/** 数据标识id向左移17位(12+5) */
private final long datacenterIdShift = sequenceBits + workerIdB
/** 时间截向左移22位(5+5+12) */
private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdB
/** 生成序列的掩码，这里为xfff=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;
* 构造函数
* workerId 工作ID (0~31)
* datacenterId 数据中心ID (0~31)
public SnowflakeIdWorker(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 (该方法是线程安全的)
* SnowflakeId
public synchronized long nextId() {
long timestamp = timeGen();
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) & sequenceM
if (sequence == 0) {
timestamp = tilNextMillis(lastTimestamp);
sequence = 0L;
lastTimestamp =
return ((timestamp - twepoch) && timestampLeftShift)
| (datacenterId && datacenterIdShift)
| (workerId && workerIdShift)
* 阻塞到下一个毫秒，直到获得新的时间戳
* lastTimestamp 上次生成ID的时间截
* 当前时间戳
protected long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp &= lastTimestamp) {
timestamp = timeGen();
* 返回以毫秒为单位的当前时间
* 当前时间(毫秒)
protected long timeGen() {
return System.currentTimeMillis();
/** 测试 */
public static void main(String[] args) {
SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0);
for (int i = 0; i & 1000; i++) {
long id = idWorker.nextId();
System.out.println(Long.toBinaryString(id));
System.out.println(id);
存在的问题
首先贴出测试代码
package com.yy.
import java.util.HashS
* Created by Administrator on .
public class SnowflakeIdWorkerTest {
public static HashSet&Long& idSet = new HashSet&&();
public static void main(String[] args) {
for (long i = 0; i & 1000; i++) {
new Thread(new Worker(new SnowflakeIdWorker(1, 0))).start();
static class Worker implements Runnable {
private SnowflakeIdWorker snowflakeIdW
public Worker(SnowflakeIdWorker snowflakeIdWorker) {
this.snowflakeIdWorker = snowflakeIdW
public void run() {
for (int i = 0; i & 1; i++) {
Long id = snowflakeIdWorker.nextId();
if (!idSet.add(id)) {
System.err.println("存在重复id:" + id);
运行过后发现结果为：
存在重复:480512
存在重复:674816
存在重复:674816
存在重复:674816
存在重复:869120
存在重复:869120
存在重复:869120
存在重复:869120
存在重复:869120
存在重复:869120
存在重复:869120
存在重复:869120
存在重复:869120
也就是说同一台机器同一个业务，并发量3000的情况下会产生大量相同的id。这又是什么原因导致的呢。算法是没有问题的。
仔细观察源码我们发现，代码里面生成id是使用的是syncronized关键字来进行同步的，syncronized使用在方法上表示的是锁住的是当前对象。而我们测试时使用，每一个线程对新建了一个对象，也就是说在生成id时，每个线程的取时间戳可以同时进行，序列sequence 自增也是的。所以才会可能产生相同的id。
问题改进或者使用注意事项
使用时，应该采用单例模式。也就是在多个线程去生成id的时候，用的需要时同一个SnowflakeIdWorker 对象，因为syncronized关键字用在方法上锁住的仅仅是当前的对象。因此采用单例就不会产生多线程安全问题。在实际的应用中可以考虑把SnowflakeIdWorker 对象使用spring来创建，scope使用singleton。
下面是单例的代码：
package com.yy.
import java.util.HashS
* Created by Administrator on .
public class SnowflakeIdWorkerTest {
public static HashSet&Long& idSet = new HashSet&&();
public static void main(String[] args) {
SnowflakeIdWorker snowflakeIdWorker = new SnowflakeIdWorker(1, 0);
for (long i = 0; i & 1000; i++) {
new Thread(new Worker(snowflakeIdWorker)).start();
static class Worker implements Runnable {
private SnowflakeIdWorker snowflakeIdW
public Worker(SnowflakeIdWorker snowflakeIdWorker) {
this.snowflakeIdWorker = snowflakeIdW
public void run() {
for (int i = 0; i & 1; i++) {
Long id = snowflakeIdWorker.nextId();
if (!idSet.add(id)) {
System.err.println("存在重复id:" + id);
本文已收录于以下专栏：
相关文章推荐
首先简单讲讲Snowflake,snowflake是来自于Twitter的一个开源算法,github上有,但是找不到源代码,现在好像是一个公有的服务,然并卵,别人在墙外,我们还是来讲讲其算法,snow...
关于订单号的生成，一些比较简单的方案：
1、数据库自增长ID
优势：无需编码缺陷：
大表不能做水平分表，否则插入删除时容易出现问题高并发下插入数据需要加入事务机制在业务操作父、子表（...
把时间戳，工作机器id，序列号组合在一起。
除了最高位bit标记为不可用以外，其余三组bit占位均可浮动，看具体的业务需求而定。默认情况下41bit的时间戳可以支持该...
final int threadC = 300;
final int loopC = 1000;
//final Set idCounter = Sets.newConcurrentHa...
不重复id代码生成类package com.hp.
* @author zhujuan
* From: /twitter/snowf...
在分布式系统中经常会使用到生成全局唯一不重复ID的情况。本篇博客介绍生成的一些方法。...
SnowFlake不依赖第三方介质，不像基于ZK，Redis等，每次用完一个区间还得通过网络去获取下一个区间，效率较低，基于SnowFlake的分布式ID生成是目前我见过的最快的
详解Twitter开源分布式自增ID算法snowflake，附演算验证过程.
snowflake简介，snowflake算法原理，snowflake算法源码（java版），snowflake算法推导和...
分布式系统中，有一些需要使用全局唯一ID的场景，这种时候为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。
有些时候我们希...
* @author zhujuan
* From: /twitter/snowflake
* An object that generates IDs...
他的最新文章
讲师：李江龙
讲师：司徒正美
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)分布式系统中，有一些需要使用全局唯一ID的场景，这种时候为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。
有些时候我们希望能使用一种简单一些的ID，并且希望ID能够按照时间有序生成。
而twitter的snowflake解决了这种需求，最初Twitter把存储系统从MySQL迁移到Cassandra，因为Cassandra没有顺序ID生成机制，所以开发了这样一套全局唯一ID生成服务。
snowflake的结构如下(每部分用-分开):
0 - 00000 - 00000 -
第一位为未使用，接下来的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版本的源码)
Snowflake */
public&class&IdWorker
&&private&final&long&twepoch
&&private&final&long&workerIdBits
&&private&final&long&datacenterIdBits
&&private&final&long&maxWorkerId
= -1L ^ (-1L && workerIdBits);
&&private&final&long&maxDatacenterId
= -1L ^ (-1L && datacenterIdBits);
&&private&final&long&sequenceBits
&&private&final&long&workerIdShift
= sequenceB
&&private&final&long&datacenterIdShift
= sequenceBits + workerIdB
&&private&final&long&timestampLeftShift
= sequenceBits + workerIdBits + datacenterIdB
&&private&final&long&sequenceMask
= -1L ^ (-1L && sequenceBits);
&&private&long&workerId;
&&private&long&datacenterId;
&&private&long&sequence
&&private&long&lastTimestamp
&&public&IdWorker(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;
&&public&synchronized&long&nextId()
&&&&long&timestamp
= timeGen();
&&&&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)
& sequenceM
&&&&&&if&(sequence
&&&&&&&&timestamp
= tilNextMillis(lastTimestamp);
&&&&}&else&{
&&&&&&sequence
&&&&lastTimestamp
&&&&return&((timestamp
- twepoch) && timestampLeftShift) | (datacenterId && datacenterIdShift) | (workerId && workerIdShift) |
&&protected&long&tilNextMillis(long&lastTimestamp)
&&&&long&timestamp
= timeGen();
&&&&while&(timestamp
&= lastTimestamp) {
&&&&&&timestamp
= timeGen();
&&&&return&
&&protected&long&timeGen()
&&&&return&System.currentTimeMillis();
&&public&static&void&main(String[]
&&&&IdWorker
idWorker =&new&IdWorker(0,&0);
&&&&for&(int&i
i++) {
&&&&&&long&id
= idWorker.nextId();
&&&&&&System.out.println(id);
(JAVA版本2的源码)
Snowflake */
public class IdWorker {
private final long workerId;
private final static long twepoch = 8L;
private long sequence = 0L;
private final static long workerIdBits = 4L;
public final static long maxWorkerId = -1L ^ -1L && workerIdB
private final static long sequenceBits = 10L;
private final static long workerIdShift = sequenceB
private final static long timestampLeftShift = sequenceBits + workerIdB
public final static long sequenceMask = -1L ^ -1L && sequenceB
private long lastTimestamp = -1L;
public IdWorker(final long workerId) {
&if (workerId & 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.sequenceM
& if (this.sequence == 0) {
& &System.out.println(&###########& + sequenceMask);
& &timestamp = this.tilNextMillis(this.lastTimestamp);
& this.sequence = 0;
&if (timestamp & this.lastTimestamp) {
& &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 =
&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();
private long timeGen() {
&return System.currentTimeMillis();
public static void main(String[] args){
&IdWorker worker2 = new IdWorker(2);
&System.out.println(worker2.nextId());
本文已收录于以下专栏：
相关文章推荐
Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统...
在分布式系统中经常会使用到生成全局唯一不重复ID的情况。本篇博客介绍生成的一些方法。...
当不使用任何持久化框架时，需要想办法来生成
这种文章，网上应该很多了，不过自己不写一遍，总是不会印象太深刻，所以今天为了再度加深印象，自己也写一遍。
现在的互联网项目，用户数越来越多，系统基本都是分布式部署，所以基于数据库的自增id这里就不说...
详解Twitter开源分布式自增ID算法snowflake，附演算验证过程.
snowflake简介，snowflake算法原理，snowflake算法源码（java版），snowflake算法推导和...
但这篇博文实际上是“半分享半讨论”的博文：
半分享是我将说下我所了解到的关于今天主题所涉及的几种方案。
半讨论是我希望大家对各个方案都说说自己的见解，更加希...
最近看了一个清华博士写的代码，把代码研究了一番，在一些方面深度受益。在这里与大家分享下我对其中一点的分析。
在做项目的时候经常会用id作为唯一标识。
但是当有这样一个需求出现的时候：工程分布式部署，要...
在大型互联网应用中，随着用户数的增加，为了提高应用的性能，我们经常需要对数据库进行分库分表操作。在单表时代，我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象。
但是当我们对数据库...
1.需求来源：
公司现有评论系统的所有评论ID，是根据MySQL数据库的自增方式获得。随着时间的推移，唯一的MySQL后台库承受着大量的记录（大约在2亿左右），这样每次为了获得评论ID，而进行插入查...
之前有人问我设计一个分布式的递增的唯一id生成。想了半天不知道，偶然一个同事说起snowflake算法，我百度了一下，很简单高效。
/twitte...
他的最新文章
讲师：李江龙
讲师：司徒正美
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)