SnowFlake 分布式ID生成算法Java实现

SnowFlake 分布式ID生成Java实现

SnowFlake不依赖第三方介质，不像基于ZK，Redis等，每次用完一个区间还得通过网络去获取下一个区间，效率较低，基于SnowFlake的分布式ID生成是目前我见过的最快的

 

SnowFlake生成的是一个64位的数字，其中42位时间戳，接下来10位是自定义的数，其作用就是区分集群中的所有机器，最后12位是毫秒内序列，集群内每个机器能够在1毫秒内生成2^12 - 1个ID

 

 

/**
* 基于SnowFlake的序列号生成实现, 64位ID (42(毫秒)+5(机器ID)+5(业务编码)+12(重复累加))
*/
static class Generator {

		private final static long TWEPOCH = 1288834974657L;

		// 机器标识位数
		private final static long WORKER_ID_BITS = 5L;

		// 数据中心标识位数
		private final static long DATA_CENTER_ID_BITS = 5L;

		// 机器ID最大值 31
		private final static long MAX_WORKER_ID = -1L ^ (-1L << WORKER_ID_BITS);

		// 数据中心ID最大值 31
		private final static long MAX_DATA_CENTER_ID = -1L ^ (-1L << DATA_CENTER_ID_BITS);

		// 毫秒内自增位
		private final static long SEQUENCE_BITS = 12L;

		// 机器ID偏左移12位
		private final static long WORKER_ID_SHIFT = SEQUENCE_BITS;

		private final static long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS;

		// 时间毫秒左移22位
		private final static long TIMESTAMP_LEFT_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATA_CENTER_ID_BITS;

		private final static long SEQUENCE_MASK = -1L ^ (-1L << SEQUENCE_BITS);

		private long lastTimestamp = -1L;

		private long sequence = 0L;
		private final long workerId;
		private final long dataCenterId;
		
		//private final AtomicBoolean lock = new AtomicBoolean(false);
		
		Generator(long workerId, long dataCenterId) {
			if (workerId > MAX_WORKER_ID || workerId < 0) {
				throw new IllegalArgumentException(String.format("%s must range from %d to %d", K_WORK_ID, 0,
						MAX_WORKER_ID));
			}

			if (dataCenterId > MAX_DATA_CENTER_ID || dataCenterId < 0) {
				throw new IllegalArgumentException(String.format("%s must range from %d to %d", K_DC_ID, 0,
						MAX_DATA_CENTER_ID));
			}

			this.workerId = workerId;
			this.dataCenterId = dataCenterId;
		}

		synchronized long nextValue() throws SequenceException {
			long timestamp = time();
			if (timestamp < lastTimestamp) {
				throw new SequenceException("Clock moved backwards, refuse to generate id for "
						+ (lastTimestamp - timestamp) + " milliseconds");
			}

			if (lastTimestamp == timestamp) {
				// 当前毫秒内，则+1
				sequence = (sequence + 1) & SEQUENCE_MASK;
				if (sequence == 0) {
					// 当前毫秒内计数满了，则等待下一秒
					timestamp = tilNextMillis(lastTimestamp);
				}
			} else {
				sequence = 0;
			}
			lastTimestamp = timestamp;
			
			// ID偏移组合生成最终的ID，并返回ID
			long nextId = ((timestamp - TWEPOCH) << TIMESTAMP_LEFT_SHIFT)
					| (dataCenterId << DATA_CENTER_ID_SHIFT) | (workerId << WORKER_ID_SHIFT) | sequence;

			return nextId;
		}

		private long tilNextMillis(final long lastTimestamp) {
			long timestamp = this.time();
			while (timestamp <= lastTimestamp) {
				timestamp = this.time();
			}
			return timestamp;
		}

		private long time() {
			return System.currentTimeMillis();
		}

	}

 

评论

5 楼 莫名的拉风 2016-12-29  

bjyzxxds 写道

bjyzxxds 写道

莫名的拉风 写道

bjyzxxds 写道

重点就在这个10位自定义数，需要考虑应用自动弹性扩展时，如何自动获取，不用zk、redis，那也得找个其他的或者自己写个，总之跑不了

这个数一般无须变化，所以在配置文件里面配没啥问题吧

当然必须变化，否则就有产生相同id的情况出现

对于已启动的应用，在运行过程中，是不需要变化的，但是弹性扩展出来的新实例，必须与已有实例中的配置不一样。

嗯，确实是

4 楼 bjyzxxds 2016-12-29  

bjyzxxds 写道

莫名的拉风 写道

bjyzxxds 写道

重点就在这个10位自定义数，需要考虑应用自动弹性扩展时，如何自动获取，不用zk、redis，那也得找个其他的或者自己写个，总之跑不了

这个数一般无须变化，所以在配置文件里面配没啥问题吧

当然必须变化，否则就有产生相同id的情况出现

对于已启动的应用，在运行过程中，是不需要变化的，但是弹性扩展出来的新实例，必须与已有实例中的配置不一样。

3 楼 bjyzxxds 2016-12-29  

莫名的拉风 写道

bjyzxxds 写道

重点就在这个10位自定义数，需要考虑应用自动弹性扩展时，如何自动获取，不用zk、redis，那也得找个其他的或者自己写个，总之跑不了

这个数一般无须变化，所以在配置文件里面配没啥问题吧

当然必须变化，否则就有产生相同id的情况出现

2 楼 莫名的拉风 2016-12-29  

bjyzxxds 写道

重点就在这个10位自定义数，需要考虑应用自动弹性扩展时，如何自动获取，不用zk、redis，那也得找个其他的或者自己写个，总之跑不了

这个数一般无须变化，所以在配置文件里面配没啥问题吧

1 楼 bjyzxxds 2016-12-29  

重点就在这个10位自定义数，需要考虑应用自动弹性扩展时，如何自动获取，不用zk、redis，那也得找个其他的或者自己写个，总之跑不了