什么是分庫(kù)分表常見(jiàn)分布式主鍵ID生成策略

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

主鍵生成策略

　　系統(tǒng)唯一ID是我們?cè)谠O(shè)計(jì)一個(gè)系統(tǒng)的時(shí)候常常會(huì)遇見(jiàn)的問(wèn)題，下面介紹一些常見(jiàn)的ID生成策略。

• Sequence ID

• UUID

• GUID

• COMB

• Snowflake

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

1. Sequence ID

數(shù)據(jù)庫(kù)自增長(zhǎng)序列或字段，最常見(jiàn)的方式。由數(shù)據(jù)庫(kù)維護(hù)，數(shù)據(jù)庫(kù)唯一。

優(yōu)點(diǎn)：

1. 簡(jiǎn)單，代碼方便，性能可以接受。

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

缺點(diǎn)：

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

2. 在單個(gè)數(shù)據(jù)庫(kù)或讀寫(xiě)分離或一主多從的情況下，只有一個(gè)主庫(kù)可以生成。有單點(diǎn)故障的風(fēng)險(xiǎn)。

3. 在性能達(dá)不到要求的情況下，比較難于擴(kuò)展。

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

5. 分表分庫(kù)的時(shí)候會(huì)有麻煩。

優(yōu)化方案：

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

2. UUID

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

優(yōu)點(diǎn)：

1. 簡(jiǎn)單，代碼方便。

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

缺點(diǎn)：

1. 沒(méi)有排序，無(wú)法保證趨勢(shì)遞增。

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

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

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

5. 不可讀。

優(yōu)化方案：

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

3. GUID

GUID：是微軟對(duì)UUID這個(gè)標(biāo)準(zhǔn)的實(shí)現(xiàn)。UUID還有其它各種實(shí)現(xiàn)，不止GUID一種。優(yōu)缺點(diǎn)同UUID。

4. COMB

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

優(yōu)點(diǎn)：

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

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

5. Twitter的snowflake算法

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

優(yōu)點(diǎn)：

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

2. ID按照時(shí)間在單機(jī)上是遞增的。

缺點(diǎn)：

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

上述就是小編為大家分享的什么是分庫(kù)分表常見(jiàn)分布式主鍵ID生成策略了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。