分散式唯一ID的幾種生成方案
導讀 | 這篇文章,我們就接著分庫分表的知識,來具體聊一下全域性唯一ID如何生成。在分庫分表之後你必然要面對的一個問題,就是id咋生成?因為要是一個表分成多個表之後,每個表的id都是從1開始累加自增長,那肯定不對啊。 |
舉個例子,你的訂單表拆分為了1024張訂單表,每個表的id都從1開始累加,這個肯定有問題了!
你的系統就沒辦法根據表主鍵來查詢訂單了,比如id = 50這個訂單,在每個表裡都有!
所以此時就需要分散式架構下的全域性唯一id生成的方案了,在分庫分表之後,對於插入資料庫中的核心id,不能直接簡單使用表自增id,要全域性生成唯一id,然後插入各個表中,保證每個表內的某個id,全域性唯一。
比如說訂單表雖然拆分為了1024張表,但是id = 50這個訂單,只會存在於一個表裡。
那麼如何實現全域性唯一id呢?有以下幾種方案。
這個方案就是說你的系統每次要生成一個id,都是往一個獨立庫的一個獨立表裡插入一條沒什麼業務含義的資料,然後獲取一個資料庫自增的一個id。拿到這個id之後再往對應的分庫分表裡去寫入。
比如說你有一個auto_id庫,裡面就一個表,叫做auto_id表,有一個id是自增長的。
那麼你每次要獲取一個全域性唯一id,直接往這個表裡插入一條記錄,獲取一個全域性唯一id即可,然後這個全域性唯一id就可以插入訂單的分庫分表中。
這個方案的好處就是方便簡單,誰都會用。缺點就是單庫生成自增id,要是高併發的話,就會有瓶頸的,因為auto_id庫要是承載個每秒幾萬併發,肯定是不現實的了。
這個每個人都應該知道吧,就是用UUID生成一個全域性唯一的id。
好處就是每個系統本地生成,不要基於資料庫來了
不好之處就是,uuid太長了,作為主鍵效能太差了,不適合用於主鍵。
如果你是要隨機生成個什麼檔名了,編號之類的,你可以用uuid,但是作為主鍵是不能用uuid的。
這個方案的意思就是獲取當前時間作為全域性唯一的id。
但是問題是,併發很高的時候,比如一秒併發幾千,會有重複的情況,這個是肯定不合適的。
一般如果用這個方案,是將當前時間跟很多其他的業務欄位拼接起來,作為一個id,如果業務上你覺得可以接受,那麼也是可以的。
你可以將別的業務欄位值跟當前時間拼接起來,組成一個全域性唯一的編號,比如說訂單編號:時間戳 + 使用者id + 業務含義編碼。
snowflake演算法,是twitter開源的分散式id生成演算法。
其核心思想就是:使用一個64 bit的long型的數字作為全域性唯一id,這64個bit中,其中1個bit是不用的,然後用其中的41 bit作為毫秒數,用10 bit作為工作機器id,12 bit作為序列號。
給大家舉個例子吧,比如下面那個64 bit的long型數字,大家看看
上面第一個部分,是1個bit:0,這個是無意義的
上面第二個部分是41個bit:表示的是時間戳
上面第三個部分是5個bit:表示的是機房id,10001
上面第四個部分是5個bit:表示的是機器id,1 1001
上面第五個部分是12個bit:表示的序號,就是某個機房某臺機器上這一毫秒內同時生成的id的序號,0000 00000000
1 bit:是不用的,為啥呢?
因為二進位制裡第一個bit為如果是1,那麼都是負數,但是我們生成的id都是正數,所以第一個bit統一都是0
41 bit:表示的是時間戳,單位是毫秒。
41 bit可以表示的數字多達2^41 - 1,也就是可以標識2 ^ 41 - 1個毫秒值,換算成年就是表示69年的時間。
10 bit:記錄工作機器id,代表的是這個服務最多可以部署在2^10臺機器上,也就是1024臺機器。
但是10 bit裡5個bit代表機房id,5個bit代表機器id。意思就是最多代表2 ^ 5個機房(32個機房),每個機房裡可以代表2 ^ 5個機器(32臺機器)。
12 bit:這個是用來記錄同一個毫秒內產生的不同id。
12 bit可以代表的最大正整數是2 ^ 12 - 1 = 4096,也就是說可以用這個12bit代表的數字來區分同一個毫秒內的4096個不同的id
簡單來說,你的某個服務假設要生成一個全域性唯一id,那麼就可以傳送一個請求給部署了snowflake演算法的系統,由這個snowflake演算法系統來生成唯一id。
這個snowflake演算法系統首先肯定是知道自己所在的機房和機器的,比如機房id = 17,機器id = 12。
接著snowflake演算法系統接收到這個請求之後,首先就會用二進位制位運算的方式生成一個64 bit的long型id,64個bit中的第一個bit是無意義的。
接著41個bit,就可以用當前時間戳(單位到毫秒),然後接著5個bit設定上這個機房id,還有5個bit設定上機器id。
最後再判斷一下,當前這臺機房的這臺機器上這一毫秒內,這是第幾個請求,給這次生成id的請求累加一個序號,作為最後的12個bit。
最終一個64個bit的id就出來了,類似於:
這個演算法可以保證說,一個機房的一臺機器上,在同一毫秒內,生成了一個唯一的id。可能一個毫秒內會生成多個id,但是有最後12個bit的序號來區分開來。
下面我們簡單看看這個snowflake演算法的一個程式碼實現,這就是個示例,大家如果理解了這個意思之後,以後可以自己嘗試改造這個演算法。
總之就是用一個64bit的數字中各個bit位來設定不同的標誌位,區分每一個id。
public class IdWorker { private long workerId; // 這個就是代表了機器id private long datacenterId; // 這個就是代表了機房id private long sequence; // 這個就是代表了一毫秒內生成的多個id的最新序號 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)); } 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(); } // 這個是核心方法,透過呼叫nextId()方法,讓當前這臺機器上的snowflake演算法程式生成一個全域性唯一的id 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)); } // 下面是說假設在同一個毫秒內,又傳送了一個請求生成一個id // 這個時候就得把seqence序號給遞增1,最多就是4096 if (lastTimestamp == timestamp) { // 這個意思是說一個毫秒內最多隻能有4096個數字,無論你傳遞多少進來, //這個位運算保證始終就是在4096這個範圍內,避免你自己傳遞個sequence超過了4096這個範圍 sequence = (sequence + 1) & sequenceMask; if (sequence == 0) { timestamp = tilNextMillis(lastTimestamp); } } else { sequence = 0; } // 這兒記錄一下最近一次生成id的時間戳,單位是毫秒 lastTimestamp = timestamp; // 這兒就是最核心的二進位制位運算操作,生成一個64bit的id // 先將當前時間戳左移,放到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()); } } }
其實在實際的開發中,這個snowflake演算法可以做一點點改進。
因為大家可以考慮一下,我們在生成唯一id的時候,一般都需要指定一個表名,比如說訂單表的唯一id。
所以上面那64個bit中,代表機房的那5個bit,可以使用業務表名稱來替代,比如用00001代表的是訂單表。
因為其實很多時候,機房並沒有那麼多,所以那5個bit用做機房id可能意義不是太大。
這樣就可以做到,snowflake演算法系統的每一臺機器,對一個業務表,在某一毫秒內,可以生成一個唯一的id,一毫秒內生成很多id,用最後12個bit來區分序號對待。
原文來自:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2935412/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 生成分散式唯一ID的幾種解決方案分散式
- 分散式唯一id生成策略分散式
- 分散式唯一 ID 生成器分散式
- 分散式唯一ID生成服務分散式
- 分散式唯一 ID 生成器 - IDGen分散式
- php生成唯一id的幾種解決方法PHP
- 分散式系統中唯一 ID 的生成方法分散式
- Redis實現分散式鎖的幾種方案Redis分散式
- 搞懂分散式技術16:淺談分散式鎖的幾種方案分散式
- 分散式全域性ID生成方案分散式
- 研究分散式唯一ID生成,看完這篇就夠分散式
- PHP 實現 Snowflake 生成分散式唯一 IDPHP分散式
- 搞懂分散式技術12:分散式ID生成方案分散式
- 分散式唯一ID解決方案-雪花演算法分散式演算法
- 分散式唯一ID生成方案選型!詳細解析雪花演算法Snowflake分散式演算法
- 分散式全域性唯一ID分散式
- 分庫分表的 9種分散式主鍵ID 生成方案,挺全乎的分散式
- 高併發下,php使用uniqid函式生成唯一識別符號的四種方案PHP函式符號
- 分散式ID生成器的解決方案總結分散式
- 最常用的分散式ID解決方案,你知道幾個分散式
- 框架篇:分散式全域性唯一ID框架分散式
- 全域性唯一ID(GUID)生成方案對比GUI
- 分散式鎖的幾種實現方式分散式
- 分散式鎖的幾種實現方式~分散式
- 分散式鎖的幾種實現思路分散式
- 開源專案|Go 開發的一款分散式唯一 ID 生成系統Go分散式
- 分散式全域性ID生成方案彙總和對比分散式
- 分散式:分散式系統下的唯一序列分散式
- PostgreSQL的幾種分散式架構對比SQL分散式架構
- 分散式事務的幾種實現方式分散式
- 全域性唯一ID生成常見的幾種方式和twitter/snowflake(雪花演算法)解析演算法
- 【高併發】之分散式全域性唯一 ID分散式
- 分散式唯一id:snowflake演算法思考分散式演算法
- 怎樣生成分散式的流水ID分散式
- 分散式的環境中id生成策略分散式
- 分散式系統唯一主鍵識別符號ID生成機制比較 - Encore分散式符號
- 詳解 Redis 分散式鎖的 5 種方案Redis分散式
- 講分散式唯一id,這篇文章很實在分散式