資料庫分庫分表(一)常見分散式主鍵ID生成策略

NO IMAGE

主鍵生成策略

  系統唯一ID是我們在設計一個系統的時候常常會遇見的問題,下面介紹一些常見的ID生成策略。

  • Sequence ID
  • UUID
  • GUID
  • COMB
  • Snowflake

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

1. Sequence ID

資料庫自增長序列或欄位,最常見的方式。由資料庫維護,資料庫唯一。

優點:

  1. 簡單,程式碼方便,效能可以接受。
  2. 數字ID天然排序,對分頁或者需要排序的結果很有幫助。

缺點:

  1. 不同資料庫語法和實現不同,資料庫遷移的時候或多資料庫版本支援的時候需要處理。
  2. 在單個資料庫或讀寫分離或一主多從的情況下,只有一個主庫可以生成。有單點故障的風險。
  3. 在效能達不到要求的情況下,比較難於擴充套件。
  4. 如果遇見多個系統需要合併或者涉及到資料遷移會相當痛苦。
  5. 分表分庫的時候會有麻煩。

優化方案:

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

2. UUID

常見的方式,128位。可以利用資料庫也可以利用程式生成,一般來說全球唯一。

優點:

  1. 簡單,程式碼方便。
  2. 全球唯一,在遇見資料遷移,系統資料合併,或者資料庫變更等情況下,可以從容應對。

缺點:

  1. 沒有排序,無法保證趨勢遞增。
  2. UUID往往是使用字串儲存,查詢的效率比較低。
  3. 儲存空間比較大,如果是海量資料庫,就需要考慮儲存量的問題。
  4. 傳輸資料量大
  5. 不可讀。

優化方案:

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

3. GUID

GUID:是微軟對UUID這個標準的實現。UUID還有其它各種實現,不止GUID一種。優缺點同UUID。

4. COMB

  COMB(combine)型是資料庫特有的一種設計思想,可以理解為一種改進的GUID,它通過組合GUID和系統時間,以使其在索引和檢索事有更優的效能。
  資料庫中沒有COMB型別,它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中設計出來的。
  COMB資料型別的基本設計思路是這樣的:既然UniqueIdentifier資料因毫無規律可言造成索引效率低下,影響了系統的效能,那麼我們能不能通過組合的方式,保留UniqueIdentifier的前10個位元組,用後6個位元組表示GUID生成的時間(DateTime),這樣我們將時間資訊與UniqueIdentifier組合起來,在保留UniqueIdentifier的唯一性的同時增加了有序性,以此來提高索引效率。

優點:

  1. 解決UUID無序的問題,在其主鍵生成方式中提供了Comb演算法(combined guid/timestamp)。保留GUID的10個位元組,用另6個位元組表示GUID生成的時間(DateTime)。
  2. 效能優於UUID。

5. Twitter的snowflake演算法

  snowflake是Twitter開源的分散式ID生成演算法,結果是一個long型的ID。其核心思想是:使用41bit作為毫秒數,10bit作為機器的ID(5個bit是資料中心,5個bit的機器ID),12bit作為毫秒內的流水號(意味著每個節點在每毫秒可以產生 4096 個 ID),最後還有一個符號位,永遠是0。snowflake演算法可以根據自身專案的需要進行一定的修改。比如估算未來的資料中心個數,每個資料中心的機器數以及統一毫秒可以能的併發數來調整在演算法中所需要的bit數。

優點:

  1. 不依賴於資料庫,靈活方便,且效能優於資料庫。
  2. ID按照時間在單機上是遞增的。

缺點:

  1. 在單機上是遞增的,但是由於涉及到分散式環境,每臺機器上的時鐘不可能完全同步,也許有時候也會出現不是全域性遞增的情況。

參考:

  1. 分散式系統唯一ID生成方案彙總
  2. UUID 、GUID、COMB 的區別與聯絡
  3. UUID 和 GUID 的區別
  4. The Cost of GUIDs as Primary Keys
  5. Integer GUID和Comb做主鍵的效率測試(Delphi access)(三)
  6. Twitter-Snowflake專案地址(Tags:snowflake-2010)
  7. 如何在高併發分散式系統中生成全域性唯一Id
  8. Twitter-Snowflake(64位分散式ID演算法)分析與JAVA實現

轉載註明出處,我就不和你計較。
by Donney Young
http://www.jianshu.com/p/a0a3aa888a49

作者:DonneyYoung
連結:http://www.jianshu.com/p/a0a3aa888a49
來源:簡書
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。