什么是分庫分表常見分布式主鍵ID生成策略

這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)什么是分庫分表常見分布式主鍵ID生成策略，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都創(chuàng)新互聯(lián)于2013年成立，先為三江侗等服務(wù)建站，三江侗等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為三江侗企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

主鍵生成策略

系統(tǒng)唯一ID是我們在設(shè)計一個系統(tǒng)的時候常常會遇見的問題，下面介紹一些常見的ID生成策略。

  • Sequence ID

  • UUID

  • GUID

  • COMB

  • Snowflake

最開始的自增ID為了實現(xiàn)分庫分別的需求，會在自增的前提下，使用不同步長(例如DB1 生成1,4,7,10，DB2生成2,5,8,11，DB3生成3,6,9,12)，但需要做數(shù)據(jù)庫拓展時，極其麻煩。
　　相比自增ID，UUID生成唯一主鍵更加方便（數(shù)據(jù)量非常大的情況下，存在重復(fù)的可能），但由于UUID的無序性，性能不如自增ID，字符串儲存，儲存空間大，查詢效率低。
　　COMB相對于UUID，增加了生成ID的有序性，插入與查詢效率都有所提高。見Integer GUID和Comb做主鍵的效率測試(Delphi+access)(三)
　　Sonwflake是Twitter主鍵生成策略，可以看做是COMB的一種改進，用64位的長整型代替128位的字符串。ID構(gòu)成：第一位0 + 41位的時間前綴 + 10位的節(jié)點標識 + 12位的sequence避免并發(fā)的數(shù)字。見Twitter-Snowflake（64位分布式ID算法）分析與JAVA實現(xiàn)

1. Sequence ID

數(shù)據(jù)庫自增長序列或字段，最常見的方式。由數(shù)據(jù)庫維護，數(shù)據(jù)庫唯一。

優(yōu)點：

  1. 簡單，代碼方便，性能可以接受。

  2. 數(shù)字ID天然排序，對分頁或者需要排序的結(jié)果很有幫助。

缺點：

  1. 不同數(shù)據(jù)庫語法和實現(xiàn)不同，數(shù)據(jù)庫遷移的時候或多數(shù)據(jù)庫版本支持的時候需要處理。

  2. 在單個數(shù)據(jù)庫或讀寫分離或一主多從的情況下，只有一個主庫可以生成。有單點故障的風險。

  3. 在性能達不到要求的情況下，比較難于擴展。

  4. 如果遇見多個系統(tǒng)需要合并或者涉及到數(shù)據(jù)遷移會相當痛苦。

  5. 分表分庫的時候會有麻煩。

優(yōu)化方案：

  1. 針對主庫單點，如果有多個Master庫，則每個Master庫設(shè)置的起始數(shù)字不一樣，步長一樣，可以是Master的個數(shù)。
    比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。這樣就可以有效生成集群中的唯一ID，也可以大大降低ID生成數(shù)據(jù)庫操作的負載。

2. UUID

常見的方式,128位?？梢岳脭?shù)據(jù)庫也可以利用程序生成，一般來說全球唯一。

優(yōu)點：

  1. 簡單，代碼方便。

  2. 全球唯一，在遇見數(shù)據(jù)遷移，系統(tǒng)數(shù)據(jù)合并，或者數(shù)據(jù)庫變更等情況下，可以從容應(yīng)對。

缺點：

  1. 沒有排序，無法保證趨勢遞增。

  2. UUID往往是使用字符串存儲，查詢的效率比較低。

  3. 存儲空間比較大，如果是海量數(shù)據(jù)庫，就需要考慮存儲量的問題。

  4. 傳輸數(shù)據(jù)量大

  5. 不可讀。

優(yōu)化方案：

  1. 為了解決UUID不可讀，可以使用UUID to Int64的方法。

3. GUID

GUID：是微軟對UUID這個標準的實現(xiàn)。UUID還有其它各種實現(xiàn)，不止GUID一種。優(yōu)缺點同UUID。

4. COMB

COMB（combine）型是數(shù)據(jù)庫特有的一種設(shè)計思想，可以理解為一種改進的GUID，它通過組合GUID和系統(tǒng)時間，以使其在索引和檢索事有更優(yōu)的性能。
　　數(shù)據(jù)庫中沒有COMB類型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設(shè)計出來的。
　　COMB數(shù)據(jù)類型的基本設(shè)計思路是這樣的：既然UniqueIdentifier數(shù)據(jù)因毫無規(guī)律可言造成索引效率低下，影響了系統(tǒng)的性能，那么我們能不能通過組合的方式，保留UniqueIdentifier的前10個字節(jié)，用后6個字節(jié)表示GUID生成的時間（DateTime），這樣我們將時間信息與UniqueIdentifier組合起來，在保留UniqueIdentifier的唯一性的同時增加了有序性，以此來提高索引效率。

優(yōu)點：

  1. 解決UUID無序的問題，在其主鍵生成方式中提供了Comb算法(combined guid/timestamp)。保留GUID的10個字節(jié)，用另6個字節(jié)表示GUID生成的時間(DateTime)。

  2. 性能優(yōu)于UUID。

5. Twitter的snowflake算法

snowflake是Twitter開源的分布式ID生成算法，結(jié)果是一個long型的ID。其核心思想是：使用41bit作為毫秒數(shù)，10bit作為機器的ID（5個bit是數(shù)據(jù)中心，5個bit的機器ID），12bit作為毫秒內(nèi)的流水號（意味著每個節(jié)點在每毫秒可以產(chǎn)生 4096 個 ID），最后還有一個符號位，永遠是0。snowflake算法可以根據(jù)自身項目的需要進行一定的修改。比如估算未來的數(shù)據(jù)中心個數(shù)，每個數(shù)據(jù)中心的機器數(shù)以及統(tǒng)一毫秒可以能的并發(fā)數(shù)來調(diào)整在算法中所需要的bit數(shù)。

優(yōu)點：

  1. 不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。

  2. ID按照時間在單機上是遞增的。

缺點：

  1. 在單機上是遞增的，但是由于涉及到分布式環(huán)境，每臺機器上的時鐘不可能完全同步，也許有時候也會出現(xiàn)不是全局遞增的情況。

上述就是小編為大家分享的什么是分庫分表常見分布式主鍵ID生成策略了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

當前標題：什么是分庫分表常見分布式主鍵ID生成策略
地址分享：http://muchs.cn/article12/jojjgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導航、響應(yīng)式網(wǎng)站、企業(yè)網(wǎng)站制作、網(wǎng)站排名、定制網(wǎng)站、自適應(yīng)網(wǎng)站

廣告

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

網(wǎng)站優(yōu)化排名