本文由 yanglbme 首發於 GitHub 技術社區 Doocs,目前 stars 已超 30k。
項目地址:github.com/doocs/advan…java
分庫分表以後,id 主鍵如何處理?git
其實這是分庫分表以後你必然要面對的一個問題,就是 id 咋生成?由於要是分紅多個表以後,每一個表都是從 1 開始累加,那確定不對啊,須要一個全局惟一的 id 來支持。因此這都是你實際生產環境中必須考慮的問題。github
這個就是說你的系統裏每次獲得一個 id,都是往一個庫的一個表裏插入一條沒什麼業務含義的數據,而後獲取一個數據庫自增的一個 id。拿到這個 id 以後再往對應的分庫分表裏去寫入。面試
這個方案的好處就是方便簡單,誰都會用;缺點就是單庫生成自增 id,要是高併發的話,就會有瓶頸的;若是你硬是要改進一下,那麼就專門開一個服務出來,這個服務每次就拿到當前 id 最大值,而後本身遞增幾個 id,一次性返回一批 id,而後再把當前最大 id 值修改爲遞增幾個 id 以後的一個值;可是不管如何都是基於單個數據庫。算法
適合的場景:你分庫分表就倆緣由,要不就是單庫併發過高,要不就是單庫數據量太大;除非是你併發不高,可是數據量太大致使的分庫分表擴容,你能夠用這個方案,由於可能每秒最高併發最多就幾百,那麼就走單獨的一個庫和表生成自增主鍵便可。數據庫
能夠經過設置數據庫 sequence 或者表的自增字段步長來進行水平伸縮。bash
好比說,如今有 8 個服務節點,每一個服務節點使用一個 sequence 功能來產生 ID,每一個 sequence 的起始 ID 不一樣,而且依次遞增,步長都是 8。微信
適合的場景:在用戶防止產生的 ID 重複時,這種方案實現起來比較簡單,也能達到性能目標。可是服務節點固定,步長也固定,未來若是還要增長服務節點,就很差搞了。併發
好處就是本地生成,不要基於數據庫來了;很差之處就是,UUID 太長了、佔用空間大,做爲主鍵性能太差了;更重要的是,UUID 不具備有序性,會致使 B+ 樹索引在寫的時候有過多的隨機寫操做(連續的 ID 能夠產生部分順序寫),還有,因爲在寫的時候不能產生有順序的 append 操做,而須要進行 insert 操做,將會讀取整個 B+ 樹節點到內存,在插入這條記錄後會將整個節點寫回磁盤,這種操做在記錄佔用空間比較大的狀況下,性能降低明顯。app
適合的場景:若是你是要隨機生成個什麼文件名、編號之類的,你能夠用 UUID,可是做爲主鍵是不能用 UUID 的。
UUID.randomUUID().toString().replace(「-」, 「」) -> sfsdf23423rr234sfdaf
複製代碼
這個就是獲取當前時間便可,可是問題是,併發很高的時候,好比一秒併發幾千,會有重複的狀況,這個是確定不合適的。基本就不用考慮了。
適合的場景:通常若是用這個方案,是將當前時間跟不少其餘的業務字段拼接起來,做爲一個 id,若是業務上你以爲能夠接受,那麼也是能夠的。你能夠將別的業務字段值跟當前時間拼接起來,組成一個全局惟一的編號。
snowflake 算法是 twitter 開源的分佈式 id 生成算法,採用 Scala 語言實現,是把一個 64 位的 long 型的 id,1 個 bit 是不用的,用其中的 41 bit 做爲毫秒數,用 10 bit 做爲工做機器 id,12 bit 做爲序列號。
2^41 - 1
,也就是能夠標識 2^41 - 1
個毫秒值,換算成年就是表示69年的時間。2^5
個機房(32個機房),每一個機房裏能夠表明 2^5
個機器(32臺機器)。2^12 - 1 = 4096
,也就是說能夠用這個 12 bit 表明的數字來區分同一個毫秒內的 4096 個不一樣的 id。0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000
複製代碼
public class IdWorker {
private long workerId;
private long datacenterId;
private long sequence;
public IdWorker(long workerId, long datacenterId, long sequence) {
// sanity check for workerId
// 這兒不就檢查了一下,要求就是你傳遞進來的機房id和機器id不能超過32,不能小於0
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;
// 這個是二進制運算,就是 5 bit最多隻能有31個數字,也就是說機器id最多隻能是32之內
private long maxWorkerId = -1L ^ (-1L << workerIdBits);
// 這個是一個意思,就是 5 bit最多隻能有31個數字,機房id最多隻能是32之內
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) {
// 這個意思是說一個毫秒內最多隻能有4096個數字
// 不管你傳遞多少進來,這個位運算保證始終就是在4096這個範圍內,避免你本身傳遞個sequence超過了4096這個範圍
sequence = (sequence + 1) & sequenceMask;
if (sequence == 0) {
timestamp = tilNextMillis(lastTimestamp);
}
} else {
sequence = 0;
}
// 這兒記錄一下最近一次生成id的時間戳,單位是毫秒
lastTimestamp = timestamp;
// 這兒就是將時間戳左移,放到 41 bit那兒;
// 將機房 id左移放到 5 bit那兒;
// 將機器id左移放到5 bit那兒;將序號放最後12 bit;
// 最後拼接起來成一個 64 bit的二進制數字,轉換成 10 進制就是個 long 型
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) {
IdWorker worker = new IdWorker(1, 1, 1);
for (int i = 0; i < 30; i++) {
System.out.println(worker.nextId());
}
}
}
複製代碼
怎麼說呢,大概這個意思吧,就是說 41 bit 是當前毫秒單位的一個時間戳,就這意思;而後 5 bit 是你傳遞進來的一個機房 id(可是最大隻能是 32 之內),另外 5 bit 是你傳遞進來的機器 id(可是最大隻能是 32 之內),剩下的那個 12 bit序列號,就是若是跟你上次生成 id 的時間還在一個毫秒內,那麼會把順序給你累加,最多在 4096 個序號之內。
因此你本身利用這個工具類,本身搞一個服務,而後對每一個機房的每一個機器都初始化這麼一個東西,剛開始這個機房的這個機器的序號就是 0。而後每次接收到一個請求,說這個機房的這個機器要生成一個 id,你就找到對應的 Worker 生成。
利用這個 snowflake 算法,你能夠開發本身公司的服務,甚至對於機房 id 和機器 id,反正給你預留了 5 bit + 5 bit,你換成別的有業務含義的東西也能夠的。
這個 snowflake 算法相對來講仍是比較靠譜的,因此你要真是搞分佈式 id 生成,若是是高併發啥的,那麼用這個應該性能比較好,通常每秒幾萬併發的場景,也足夠你用了。
歡迎關注個人微信公衆號「Doocs開源社區」,原創技術文章第一時間推送。