分布式惟一ID生成系列（5）——Twitter的雪法算法Snowflake适合作分布式ID吗
写到这里，分布式Id算是写到最后一篇了，在这一篇里，我会讲到目前网上最适合分布式Id的方法，什么方法呢，请您往下看：html
介绍Snowflake算法
SnowFlake算法是国际大公司Twitter的采用的一种生成分布式自增id的策略，这个算法产生的分布式id是足够咱们咱们中小公司在平常里面的使用了。我也是比较推荐这一种算法产生的分布式id的。前端
算法snowflake的生成的分布式id结构组成部分
算法snowflake生成id的结果是一个64bit大小的整数，它的结构以下图， java
这里我么来说一下这个结构：首先由于window是64位的，而后整数的时候第一位必须是0，因此最大的数值就是63位的111111111111111111111111111111111111111111111111111111111111111，而后呢Snowflake算法分出来41位做为毫秒值，而后10位做为redis节点的数量，而后12位作成redis节点在每一毫秒的自增序列值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值segmentfault
因为在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的建立了less
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系列（3）——数据库自增ID机制适合作分布式ID吗
分布式ID系列（4）——Redis集群实现的分布式ID适合作分布式ID吗
分布式ID系列（5）——Twitter的雪法算法Snowflake适合作分布式ID吗
大佬网址 www.itqiankun.com/article/156…
- 1. 分布式惟一ID生成系列（2）——UUID适合作分布式ID吗
- 2. 分布式惟一 ID 之 Snowflake 算法
- 3. 分布式惟一ID系列（2）——UUID适合作分布式ID吗
- 4. snowflake 分布式惟一ID生成器
- 5. 分布式 ID 生成算法 -- Snowflake
- 6. 分布式id之雪花算法 -- SnowFlake
- 7. 分布式惟一ID系列（4）——Redis集群实现的分布式ID适合作分布式ID吗
- 8. snowflake分布式惟一id
- 9. 分布式惟一ID生成系列（3）——数据库自增ID机制适合作分布式ID吗
- 10. 分布式惟一ID生成算法-雪花算法
- 更多相关文章...
- • Redis发布订阅模式 - Redis教程
- • ASP.NET MVC - 样式和布局 - ASP.NET 教程
- • 常用的分布式事务解决方案
- • 再有人问你分布式事务，把这篇扔给他
-
每一个你不满意的现在，都有一个你没有努力的曾经。