最近遇到了分布式架构的使用，需要全局流水号，来贯穿整个微服务，所以找到了雪花算法，网上雪花算法的例子有很多，我也是随便找了一个研究一下，测试后感觉和算法格式的差距太大，打印出来的结果只有60位，而且转成long类型貌似是18位，不过还是得感谢前辈们的努力，让我了解这个算法，根据算法内容进行了修改，得到一个java最终版本，所以记录一下，目前不能确定是第一这个算法位置的本质是不是64位，第二:格式是不是41+5+5+12，其实我看了一下其它版本的还有中间10位是按照其它方式计算的，不过大体意思差不多，其实按照我的理解63位的这种算法应该已经满足不重复的要求了。
snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用
接下来的41位为毫秒级时间
然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点）
最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)
package com.beacon.sequence;
/**
* @version 1.0
* @author: beacon
* @Date: 2019-06-30 21:08
* @Description
*/
public class SnowflakeIdSeq {
/**
* 开始时间截 (2019-01-01)
*/
private final long twepoch = 1561902155808L;
/**
* 机器id所占的位数
*/
private final long workerIdBits = 5L;
/**
* 数据标识id所占的位数
*/
private final long dataCenterIdBits = 5L;
/**
* 序列在id中占的位数
*/
private final long sequenceBits = 12L;
/**
* 时间戳
*/
private final long timeIdBits = 41L;
/**
* 支持的最大机器id，结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数)
*/
private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
/**
* 支持的最大数据标识id，结果是31
*/
private final long maxDataCenterId = -1L ^ (-1L << dataCenterIdBits);
/**
* 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095)
*/
private final long sequenceMask = -1L ^ (-1L << sequenceBits);
/**
* 机器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;
/**
* 工作机器ID(0~31)
*/
private long workerId;
/**
* 数据中心ID(0~31)
*/
private long dataCenterId;
/**
* 毫秒内序列(0~4095)
*/
private long sequence = 0L;
/**
* 上次生成ID的时间截
*/
private long lastTimestamp = -1L;
/**
* 构造函数
*
* @param workerId 工作ID (0~31)
* @param dataCenterId 数据中心ID (0~31)
*/
public SnowflakeIdSeq(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;
}
/**
* 2进制结果当uuid用
* @return
*/
public String nextIdBinary(){
return "0" + Long.toBinaryString(this.nextId());
}
/**
* 获得下一个ID (该方法是线程安全的)
*
* @return SnowflakeId
*/
public synchronized long nextId() {
long timestamp = timeGen();
//System.out.println(timestamp);
//如果当前时间小于上一次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;
return ((timestamp - twepoch) << (timestampLeftShift + (timeIdBits - Long.toBinaryString(timestamp - twepoch).length())))
| (dataCenterId << datacenterIdShift)
| (workerId << workerIdShift)
| sequence;
}
/**
* 阻塞到下一个毫秒，直到获得新的时间戳
*
* @param lastTimestamp 上次生成ID的时间截
* @return 当前时间戳
*/
private long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}
/**
* 返回以毫秒为单位的当前时间
*
* @return 当前时间(毫秒)
*/
private long timeGen() {
return System.currentTimeMillis();
}
/**
* 测试
*/
public static void main(String[] args) {
SnowflakeIdSeq idWorker = new SnowflakeIdSeq(1, 1);
//for (int i = 0; i < 100000; i++) {
//long id = idWorker.nextId();
// System.out.println(id);
//System.out.println(Long.toBinaryString(id));
//}
// System.out.println( System.currentTimeMillis());
}
}
其实在计算过程中，直接使用毫秒时间戳也是满足需要的，用了减法其实就是让41位有更多的位移空间，单毫秒相等的情况下，还有序号保证不重复，不用测试我觉得也已经满足需要了，至于有强迫症的小伙伴如果一定要保证在64位，其实第一位改为1为首位（2进制啊），所有结果就是64位的了，毕竟第一位没有用，现在问题就是怕机器时间回滚，不过这种概率实在太小了，只能上线部署迁移的时候人工去核对了。