自增主鍵和UUID主鍵的優缺點及適用場景
我們首先考慮效率和儲存空間,然後再考慮安全和分散式
使用自增主鍵
優點:
1、資料儲存空間小
2、查詢效率高
缺點:
1、如果資料量過大,會超出自增長的值範圍
2、分散式儲存的表操作,尤其是在合併的時候操作複雜
3、安全性低,因為是有規律的,如果惡意扒取使用者資訊會很容易,如果是單據編號使用,競爭對手會容易查詢出貨量
使用UUID主鍵
優點:
1、出現重複的機會少
2、適合大量資料的插入和更新操作,尤其是在高併發和分散式環境下
3、安全性較高
缺點:
1、儲存空間大（16 byte）,因此它將會佔用更多的磁碟空間, MySQL官方有明確的建議主鍵要儘量越短越好，36個字元長度的UUID不符合要求
2、效能降低,對MySQL索引不利: 如果作為資料庫主鍵，在InnoDB引擎下，UUID的無序性可能會引起資料位置頻繁變動，嚴重影響效能。
適用場景
1、專案是單機版的,並且資料量比較大（百萬級）時,用自增長的,此時最好能考慮下安全性,做些安全措施
2、專案是單機版的,並且資料量沒那麼大,對速度和儲存要求不高時,用UUID
3、專案是分散式的,那麼首選UUID,分散式一般對速度和儲存要求不高
4、專案是分散式的,並且資料量達到千萬級別可更高時,對速度和儲存有要求時,可以用自增長。
分散式環境下保證主鍵的唯一性
目前兩種解決方式,下面分別介紹:
Twitter-Snowflake 64位自增id演算法
背景:
Twitter-Snowflake演算法產生的背景相當簡單,為了滿足Twitter每秒上萬條訊息的請求,每條訊息都必須分配一條唯一的id,這些id還需要一些大致的順序（方便客戶端排序）,並且在分散式系統中不同機器產生的id必須不同
Snowflake演算法核心
時間戳 + 工作機器id + 序列
Snowflake ID有64bits長 由如圖4部分組成:
- 第一位不可用
- 第二組 timestamp—41bits 使用41位時間戳,精確到毫秒,意味著其可以表示長達
(2^41-1)/(1000360024*365)=139.5年，另外使用者可以自己定義一個開始紀元（epoch)，然後用(當前時間-開始紀元）算出time，這表示在time這個部分在140年的時間裡是不會重複的,另外這裡用time還有一個很重要的原因，就是可以直接更具time進行排序，對於twitter這種更新頻繁的應用，時間排序就顯得尤為重要了。 - machine id—10bits(工作機器id),該部分其實由datacenterId和workerId兩部分組成，這兩部分是在配置檔案中指明的:
10位的資料機器位，可以部署在1024個節點，包括5位datacenterId和5位workerId
1、datacenterId，方便搭建多個生成uid的service，並保證uid不重複，比如在datacenter0將機器0，1，2組成了一個生成uid的service，而datacenter1此時也需要一個生成uid的service，從本中心獲取uid顯然是最快最方便的，那麼它可以在自己中心搭建，只要保證datacenterId唯一。如果沒有datacenterId，即用10bits，那麼在搭建一個新的service前必須知道目前已經在用的id，否則不能保證生成的id唯一，比如搭建的兩個uid service中都有machine id為100的機器，如果其server時間相同，那麼產生相同id的情況不可避免。
2、workerId是實際server機器的代號，最大到32，同一個datacenter下的workerId是不能重複的。它會被註冊到consul上，確保workerId未被其他機器佔用，並將host:port值存入，註冊成功後就可以對外提供服務了。
- sequence id —12bits(序列號),該id可以表示4096個數字，它是在time相同的情況下，遞增該值直到為0，即一個迴圈結束，此時便只能等到下一個ms到來，一般情況下4096/ms的請求是不太可能出現的，所以足夠使用了。
原始碼
/**
* Twitter_Snowflake<br>
* SnowFlake的結構如下(每部分用-分開):<br>
* 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
* 1位標識，由於long基本型別在Java中是帶符號的，最高位是符號位，正數是0，負數是1，所以id一般是正數，最高位是0<br>
* 41位時間截(毫秒級)，注意，41位時間截不是儲存當前時間的時間截，而是儲存時間截的差值（當前時間截 - 開始時間截)
* 得到的值），這裡的的開始時間截，一般是我們的id生成器開始使用的時間，由我們程式來指定的（如下下面程式IdWorker類的startTime屬性）。41位的時間截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
* 10位的資料機器位，可以部署在1024個節點，包括5位datacenterId和5位workerId<br>
* 12位序列，毫秒內的計數，12位的計數順序號支援每個節點每毫秒(同一機器，同一時間截)產生4096個ID序號<br>
* 加起來剛好64位，為一個Long型。<br>
* SnowFlake的優點是，整體上按照時間自增排序，並且整個分散式系統內不會產生ID碰撞(由資料中心ID和機器ID作區分)，並且效率較高，經測試，SnowFlake每秒能夠產生26萬ID左右。
*/
public class SnowflakeIdWorker {
// ==============================Fields===========================================
/** 開始時間截 (2015-01-01) */
private final long twepoch = 1420041600000L;
/** 機器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;
//==============================Constructors=====================================
/**
* 建構函式
* @param workerId 工作ID (0~31)
* @param datacenterId 資料中心ID (0~31)
*/
public SnowflakeIdWorker(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;
}
// ==============================Methods==========================================
/**
* 獲得下一個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();
}
//==============================Test=============================================
/** 測試 */
public static void main(String[] args) {
SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0);
for (int i = 0; i < 1000; i++) {
long id = idWorker.nextId();
System.out.println(Long.toBinaryString(id));
System.out.println(id);
}
}
}
複製程式碼參考文章
資料庫主鍵到底是用自增長（INT）好還是UUID好？
www.yyjjssnn.cn/articles/75…
Twitter-Snowflake，64位自增ID演算法詳解
www.jianshu.com/p/54a87a7c3…
Snowflake 原始碼github地址
github.com/twitter-arc…
Twitter的分散式自增ID演算法snowflake (Java版)
www.cnblogs.com/relucent/p/…
Leaf——美團點評分散式ID生成系統
tech.meituan.com/MT_Leaf.htm…