方式一、UUID
UUID是通用唯一識別碼（Universally Unique Identifier)的縮寫，開放軟件基金會(OSF)規範定義了包括網卡MAC地址、時間戳、名字空間（Namespace）、隨機或僞隨機數、時序等元素。利用這些元素來生成UUID。
UUID是由128位二進制組成，一般轉換成十六進制，然後用String表示。在java中有個UUID類,在他的註釋中我們看見這裏有4種不同的UUID的生成策略:
1. randomly
基於隨機數生成UUID，由於Java中的隨機數是僞隨機數，其重複的概率是可以被計算出來的。這個一般我們用下面的代碼獲取基於隨機數的UUID:
java.util.UUID.randomUUID()
2. time-based
基於時間的UUID,這個一般是通過當前時間，隨機數，和本地Mac地址來計算出來，自帶的JDK包並沒有這個算法的我們在一些UUIDUtil中，比如我們的log4j.core.util
3. DCE security
DCE安全的UUID。
4. name-based
基於名字的UUID，通過計算名字和名字空間的MD5來計算UUID。
- 優點
通過本地生成，沒有經過網絡I/O，性能較快
無序，無法預測他的生成順序。(當然這個也是他的缺點之一)
- 缺點
128位二進制一般轉換成36位的16進制，太長了只能用String存儲，空間佔用較多。
不能生成遞增有序的數字
- 適用
UUID的適用場景可以爲不擔心過多的空間佔用，以及不需要生成有遞增趨勢的數字。在Log4j裏面他在UuidPatternConverter中加入了UUID來標識每一條日誌。
方式二、數據庫主鍵自增
- 優點
簡單方便，有序遞增，方便排序和分頁
- 缺點
1.分庫分表會帶來問題，需要進行改造。
2.併發性能不高，受限於數據庫的性能。
3.簡單遞增容易被其他人猜測利用，比如你有一個用戶服務用的遞增，那麼其他人可以根據分析註冊的用戶ID來得到當天你的服務有多少人註冊，從而就能猜測出你這個服務當前的一個大概狀況。
4.數據庫宕機服務不可用。
- 適用
當數據量不多，併發性能不高的時候這個很適合，比如一些to B的業務，商家註冊這些，商家註冊和用戶註冊不是一個數量級的，所以可以數據庫主鍵遞增。如果對順序遞增強依賴，那麼也可以使用數據庫主鍵自增。
Redis
Redis中有兩個命令Incr，IncrBy,因爲Redis是單線程的所以能保證原子性。
- 優點
性能比數據庫好，能滿足有序遞增。
- 缺點
1.由於redis是內存的KV數據庫，即使有AOF和RDB，但是依然會存在數據丟失，有可能會造成ID重複。
2.依賴於redis，redis要是不穩定，會影響ID生成。
- 適用
由於其性能比數據庫好，但是有可能會出現ID重複和不穩定，這一塊如果可以接受那麼就可以使用。也適用於到了某個時間，比如每天都刷新ID，那麼這個ID就需要重置，通過(Incr Today)，每天都會從0開始加。
數據庫分段+服務緩存ID
step代表每個proxyServer緩存的步長。
之前我們的每個服務都訪問的是數據庫，現在不需要，每個服務直接和我們的ProxyServer做交互，減少了對數據庫的依賴。我們的每個ProxyServer回去數據庫中拿出步長的長度，比如server1拿到了1-1000,server2拿到來 1001-2000。如果用完會再次去數據庫中拿。
- 優點
比主鍵遞增性能高，能保證趨勢遞增。
如果DB宕機，proxServer由於有緩存依然可以堅持一段時間。
- 缺點
和主鍵遞增一樣，容易被人猜測。
DB宕機，雖然能支撐一段時間但是仍然會造成系統不可用。
- 適用
需要趨勢遞增，並且ID大小可控制的，可以使用這套方案。
當然這個方案也可以通過一些手段避免被人猜測，把ID變成是無序的，比如把我們生成的數據是一個遞增的long型，把這個Long分成幾個部分，比如可以分成幾組三位數，幾組四位數，然後在建立一個映射表，將我們的數據變成無序
雪花算法-Snowflake
適用場景:當我們需要無序不能被猜測的ID，並且需要一定高性能，且需要long型，那麼就可以使用我們雪花算法。比如常見的訂單ID，用雪花算法別人就無法猜測你每天的訂單量是多少。
public class IdWorker{
private long workerId;
private long datacenterId;
private long sequence = 0;
/**
* 2018/9/29日，從此時開始計算，可以用到2089年
*/
private long twepoch = 1538211907857L;
private long workerIdBits = 5L;
private long datacenterIdBits = 5L;
private long sequenceBits = 12L;
private long workerIdShift = sequenceBits;
private long datacenterIdShift = sequenceBits + workerIdBits;
private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
// 得到0000000000000000000000000000000000000000000000000000111111111111
private long sequenceMask = -1L ^ (-1L << sequenceBits);
private long lastTimestamp = -1L;
public IdWorker(long workerId, long datacenterId){
this.workerId = workerId;
this.datacenterId = datacenterId;
}
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;
}
/**
* 當前ms已經滿了
* @param lastTimestamp
* @return
*/
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) {
IdWorker worker = new IdWorker(1,1);
for (int i = 0; i < 30; i++) {
System.out.println(worker.nextId());
}
}
}