問題的背景
公司老的系統原先采用的時間戳生成訂單号，導緻了如下情形
打斷一下：大家知道怎麼查系統某項重複的資料吧
SELECT * FROM XX表 WHERE 重複項 in( SELECT 重複項 FROM XX表 GROUP BY 重複項 HAVING count(1) >= 2)
解決方法
不得了，這樣重複豈不是一單成功三方回調導緻另一單也成功了。
多個服務怎麼保證生成的訂單号唯一呢？
先上code
package com.hc.util;
public class IdWorkerUtil{
private long workerId;
private long datacenterId;
private long sequence;
public IdWorkerUtil(long workerId, long datacenterId, long sequence){
// sanity check for workerId
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));
}
System.out.printf("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);
this.workerId = workerId;
this.datacenterId = datacenterId;
this.sequence = sequence;
}
private long twepoch = 1288834974657L;
private long workerIdBits = 5L;
private long datacenterIdBits = 5L;
private long maxWorkerId = -1L ^ (-1L << workerIdBits);
private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
private long sequenceBits = 12L;
private long workerIdShift = sequenceBits;
private long datacenterIdShift = sequenceBits + workerIdBits;
private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
private long sequenceMask = -1L ^ (-1L << sequenceBits);
private long lastTimestamp = -1L;
public long getWorkerId(){
return workerId;
}
public long getDatacenterId(){
return datacenterId;
}
public long getTimestamp(){
return System.currentTimeMillis();
}
public synchronized long nextId() {
long timestamp = timeGen();
if (timestamp < lastTimestamp) {
System.err.printf("clock is moving backwards. Rejecting requests until %d.", 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 = 0;
}
lastTimestamp = timestamp;
return ((timestamp - twepoch) << timestampLeftShift) |
(datacenterId << datacenterIdShift) |
(workerId << workerIdShift) |
sequence;
}
private long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}
private long timeGen(){
return System.currentTimeMillis();
}
public static void main(String[] args) {
IdWorkerUtil idWorkerUtil = new IdWorkerUtil(1,1,0L);
System.out.println(idWorkerUtil.nextId());
}
}
以上是采用snowflake算法生成分布式唯一ID
41-bit的時間可以表示
（1L<<41）/(1000L360024*365)=69
年的時間，10-bit機器可以分别表示1024台機器。如果我們對IDC劃分有需求，還可以将10-bit分5-bit給IDC，分5-bit給工作機器。
這樣就可以表示32個IDC，每個IDC下可以有32台機器，可以根據自身需求定義。12個自增序列号可以表示
2^12
個ID，理論上snowflake方案的QPS約為
409.6w/s
，這種配置設定方式可以保證在任何一個IDC的任何一台機器在任意毫秒内生成的ID都是不同的。
這種方式的優缺點是：
優點：
- 毫秒數在高位，自增序列在低位，整個ID都是趨勢遞增的。
- 不依賴資料庫等第三方系統，以服務的方式部署，穩定性更高，生成ID的性能也是非常高的。
- 可以根據自身業務特性配置設定bit位，非常靈活。
缺點：
- 強依賴機器時鐘，如果機器上時鐘回撥，會導緻發号重複或者服務會處于不可用狀态。
一般來說，采用這種方案就解決了。
還有諸如，mysql的 auto_increment政策，redis的INCR，zookeeper的單一節點修改版本号遞增，以及zookeeper的持久順序節點。
看完點個贊呗~