很多大的互聯(lián)網(wǎng)公司數(shù)據(jù)量很大，都采用分庫分表，那么分庫后就需要統(tǒng)一的唯一ID進行存儲。這個ID可以是數(shù)字遞增的，也可以是UUID類型的。

創(chuàng)新互聯(lián)公司技術團隊10年來致力于為客戶提供做網(wǎng)站、網(wǎng)站制作、成都品牌網(wǎng)站建設、營銷型網(wǎng)站建設、搜索引擎SEO優(yōu)化等服務。經(jīng)過多年發(fā)展，公司擁有經(jīng)驗豐富的技術團隊，先后服務、推廣了上千網(wǎng)站，包括各類中小企業(yè)、企事單位、高校等機構單位。

如果是遞增的話，那么拆分了數(shù)據(jù)庫后，可以按照id的hash，均勻的分配到數(shù)據(jù)庫中，并且mysql數(shù)據(jù)庫如果將遞增的字段作為主鍵存儲的話會大大提高存儲速度。但是如果把訂單ID按照數(shù)字遞增的話，別人能夠很容易猜到你有多少訂單了，這種情況就可以需要一種非數(shù)字遞增的方式進行ID的生成。

想到分布式ID的生成，大家可能想到采用Redis進行生成ID，使用Redis的INCR命令去生成和獲取這個自增的ID，這個沒有問題，但是這個INCR的生成QPS速度為200400（官網(wǎng)發(fā)布的測試結果），也就是20W這樣子，如果QPS沒有超過這些的話，顯然使用Redis比較合適。

那么我們對于要達到高可用，高QPS，低延遲我們有沒有更好的想法呢。接下來一起看一下snowflake算法，由twitter公司開源的雪花算法。

snowflake一共64位：

• 1.第一位不用。

• 2. 41位是時間戳。 2^41以毫秒為單位的話，可得到69年，非常夠用了。

• 3. 10位位工作機器，可以有2^10=1024個工作節(jié)點，有的公司將其拆分為5位工作中心編碼，5位分給工作機器。

• 4. 最后12位用于生成遞增數(shù)據(jù)共4096個數(shù)。

如果用這個理論上的QPS上的QPS為409W/S。

這種方式的優(yōu)點為：

• 1. QPS非常高，性能也非常夠。高性能條件也滿足了。

• 2. 不需要依賴其他第三方的中間件，比如Redis。少了依賴，可用率提高了。

• 3. 可以根據(jù)自己定制進行調(diào)節(jié)。也就是里邊的10位進行自由分配。

缺點：

此種算法很依賴時鐘，假如時鐘進行回撥了，將有可能生成相同的ID。

UUID是采用32位二進制數(shù)據(jù)生成的，它生成的性能非常好，但是它是基于機器MAC地址生成的，而且不是分布式的，所以不是咱們討論的范疇。

下面咱們看一下一些大公司的分布式ID實現(xiàn)機制，通過生成創(chuàng)建一張表，采用8個Byte, 64位進行存儲使用，用這張表記錄所產(chǎn)生ID的位置，比如ID從0開始，然后使用了1000個，那么數(shù)據(jù)庫里邊記錄里邊的大值是一千，同時還有個步長值，比如1000，那么獲取下一個值得時候大值為2001，即大的沒有使用的值。

具體的實現(xiàn)步驟如下：

• 1. 提供一個生成分布式ID的服務，這個ID的服務是讀取數(shù)據(jù)庫里邊的值和步長值計算生成需要的值和范圍，然后服務消費方拿到后進行將號段存儲到緩存中使用。

• 2.當給到服務調(diào)用方之后，數(shù)據(jù)庫立即更新數(shù)據(jù)。

這種情況下的優(yōu)點為：

• 1.? 容災性能好，如果DB出現(xiàn)問題，因為數(shù)據(jù)放到內(nèi)存中，還是可以支撐一段時間。

• 2. 8個Byte可以滿足業(yè)務生成ID使用。

• 3. 大值可以自己定義，這樣有些遷移的業(yè)務還可以自己定義大值繼續(xù)使用。

當然缺點也存在：

• 1. 當數(shù)據(jù)庫掛了整個系統(tǒng)將不能使用。

• 2. 號段遞增的，容易被其他人猜到。

• 3. 如果很多服務同時訪問獲取這個ID或者網(wǎng)絡波動導致數(shù)據(jù)庫IO升高的時候，系統(tǒng)穩(wěn)定性會出現(xiàn)問題。

然后針對上述情況的解決方法是他們采用了雙緩存機制，即將號碼段讀取到內(nèi)存中之后開始使用，當使用到了10%的時候重新啟動一個新線程，然后當一個緩存用完了之后去用另一塊緩存的數(shù)據(jù)。當另一個緩存的數(shù)據(jù)達到10%的時候再重啟激動一個新線程獲取，依次反復。

這樣做的好處是避免同時訪問大量數(shù)據(jù)庫，導致I/O增多。同時可以通過兩個緩存段解決了單一緩存導致很快用完的情況。當然把這個號段設置成QPS大小的600倍，這樣數(shù)據(jù)庫掛了10-20分鐘內(nèi)還是可以繼續(xù)提供服務的。

以上一直提到了一個問題，就是ID遞增，咱們?nèi)绾谓鉀Q這個問題呢。就是采用snowflake，然后解決里邊的時鐘問題，有些公司采用ZK去比較當前workerId也就是節(jié)點ID使用的時間是否有回撥，如果有回撥就進行休眠固定時間，看是否能趕上時間，如果能趕上的話，繼續(xù)生成ID，如果一直沒有趕上達到某個值得話，那么就報錯處理。因為中間10位是表示不同的節(jié)點，那么不同的節(jié)點生成的ID就不會存在遞增的情況。

這些思路都是某公司已經(jīng)實現(xiàn)了的，如果有興趣繼續(xù)研究的話，那么在GITHUB上搜索下開源的Leaf可以直接拿著使用的。

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

文章標題：一文讀懂分布式唯一ID生成-創(chuàng)新互聯(lián)
路徑分享：http://www.chinadenli.net/article14/dpdcde.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供面包屑導航、網(wǎng)站制作、電子商務、動態(tài)網(wǎng)站、網(wǎng)站建設、云服務器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)