當(dāng)前各大主流關(guān)系型數(shù)據(jù)庫(kù)都提供了自增主鍵生成策略，如Mysql的AUTO_INCREMENT，Sql Server的IDENTITY，Oracle則是通過(guò)SEQUENCE來(lái)實(shí)現(xiàn)主鍵自增。使用自增主鍵，比較簡(jiǎn)單，占用空間較?。恢麈I按順序增長(zhǎng)存放，不會(huì)產(chǎn)生頁(yè)分裂;同時(shí)也有一些不足，如多個(gè)系統(tǒng)之間集成數(shù)據(jù)時(shí)，容易有主鍵沖突;單表自增對(duì)于數(shù)據(jù)庫(kù)單表壓力較大，不適用于高并發(fā)及分布式場(chǎng)景，自增主鍵容易被探知到系統(tǒng)業(yè)務(wù)量等。由此可見(jiàn)在系統(tǒng)業(yè)務(wù)量較小，并發(fā)量不大時(shí)使用自增主鍵不失為一種較好的選擇，但是當(dāng)面對(duì)高并發(fā)、分布式需求時(shí)，使用自增主鍵會(huì)存在較大的瓶頸。

[[338977]]

下面介紹業(yè)界較為流行的一些主鍵生成策略。

1. UUID模式

通用唯一識(shí)別碼(Universally Unique Identifier)，根據(jù)標(biāo)準(zhǔn)方法生成，不依賴中央機(jī)構(gòu)的注冊(cè)和分配，UUID具有唯一性重復(fù)UUID碼概率接近零，可以忽略不計(jì)。UUID具有多個(gè)版本：基于時(shí)間的UUID、DCE安全的UUID、基于名字的UUID(MD5)(UUID.nameUUIDFromBytes())、隨機(jī)UUID(UUID.randomUUID().toString())、基于名字的UUID(SHA1),Version 1/2適合應(yīng)用于分布式計(jì)算環(huán)境下，具有高度的唯一性;Version 3/5適合于需要相同內(nèi)容生成相同UUID的業(yè)務(wù)場(chǎng)景下；Version 4建議不要使用(隨機(jī)數(shù)有可能出現(xiàn)重復(fù)，但是重復(fù)的概率極低，在設(shè)計(jì)時(shí)需要考慮到這一點(diǎn))。

UUID雖然解決了依賴于數(shù)據(jù)庫(kù)生成主鍵的策略，但是也存在一些不足：占用存儲(chǔ)空間大;隨機(jī)生成，不具有連續(xù)性，作為主鍵時(shí)性能較差;無(wú)法根據(jù)主鍵進(jìn)行排序，確定記錄插入的先后順序;對(duì)于開(kāi)發(fā)人員不友好;如果生成過(guò)程中使用了機(jī)器MAC地址，存在一定安全隱患。

2. 步長(zhǎng)模式

即Flickr的sharding主鍵生成方案。使用多臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，通過(guò)設(shè)置不同的起始值、一致自增步長(zhǎng)，讓每個(gè)數(shù)據(jù)庫(kù)中各表主鍵保持唯一。如圖所示：

步長(zhǎng)方式在一定程度上解決了高并發(fā)的問(wèn)題，但是也存在一些問(wèn)題如：擴(kuò)展困難，設(shè)置好步長(zhǎng)后，再進(jìn)行擴(kuò)展將會(huì)比較困難;ID并不是按順序嚴(yán)格單調(diào)遞增的特性，只是趨勢(shì)遞增;每次獲取ID仍然需要讀寫(xiě)一次數(shù)據(jù)庫(kù)，仍然存在瓶頸。

3. 號(hào)段模式

即每次從數(shù)據(jù)庫(kù)獲取id時(shí)，從數(shù)據(jù)庫(kù)取到當(dāng)前id最大值，然后返回max+step，當(dāng)應(yīng)用程序用完這個(gè)號(hào)段后，再?gòu)臄?shù)據(jù)庫(kù)獲取下一個(gè)長(zhǎng)度為step的號(hào)段。為此需要專門(mén)設(shè)計(jì)一張用以記錄id的表，在應(yīng)用服務(wù)為集群，而主鍵服務(wù)器為單點(diǎn)時(shí)，多個(gè)應(yīng)用服務(wù)節(jié)點(diǎn)同時(shí)獲取id時(shí)，會(huì)產(chǎn)生沖突，可以增加version字段從而使用樂(lè)觀鎖進(jìn)行并發(fā)訪問(wèn)控制。

號(hào)段模式將主鍵緩存在應(yīng)用服務(wù)端，從而減少對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)頻率;在數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)不可用時(shí)，應(yīng)用服務(wù)仍然可以持續(xù)運(yùn)行一段時(shí)間直到當(dāng)前號(hào)段用完;但是在應(yīng)用服務(wù)重啟時(shí)有可能丟失部分id，導(dǎo)致id增長(zhǎng)不連續(xù)。

基于號(hào)段模式有一些成熟方案，且經(jīng)過(guò)實(shí)踐驗(yàn)證：美團(tuán)的Leaf-segment對(duì)號(hào)段發(fā)放方式進(jìn)行了雙buffer緩存及高可用容災(zāi)優(yōu)化。采用雙buffer模式，在當(dāng)前號(hào)段消費(fèi)到某個(gè)點(diǎn)時(shí)就異步的把下一個(gè)號(hào)段加載到內(nèi)存中。而不需要等到號(hào)段用盡的時(shí)候才去更新號(hào)段，不會(huì)在應(yīng)用服務(wù)器向數(shù)據(jù)庫(kù)請(qǐng)求id時(shí)，因?yàn)閕d號(hào)段沒(méi)有取回來(lái)，導(dǎo)致線程阻塞。

滴滴的TinyId參照了美團(tuán)Leaf的實(shí)現(xiàn)方式，并對(duì)其做了擴(kuò)展，增加了多db支持和tinyid-client。

4. snowflake模式(雪花算法)

Twitter實(shí)現(xiàn)的分布式ID生成算法。結(jié)構(gòu)如下：0-00000000000000000000000000000000000000000-00000-00000-000000000000

• 1 bit：保留位，為符號(hào)位，全部為0，表示生成的id都是正數(shù)。
• 41bit：時(shí)間戳，單位為毫秒，41位可以表示69年的時(shí)間。
• 10bit：機(jī)器id，10bit里面5位代表機(jī)房id，5位代表機(jī)器id，可以表示32個(gè)機(jī)房，每個(gè)機(jī)房里面可以用32臺(tái)機(jī)器。
• 12bit：12位序列號(hào)，按順序遞增，記錄每個(gè)節(jié)點(diǎn)1毫秒內(nèi)產(chǎn)生的id，每毫秒可以產(chǎn)生4096個(gè)id。

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

• 主鍵在單個(gè)節(jié)點(diǎn)上是按序列遞增的，能夠按照時(shí)間趨勢(shì)進(jìn)行遞增。
• 主鍵的生成不依賴于數(shù)據(jù)庫(kù)，可以由應(yīng)用程序生成。
• 在分布式集群內(nèi)不會(huì)產(chǎn)生重復(fù)id。
• 可以根據(jù)業(yè)務(wù)需求對(duì)bit位進(jìn)行調(diào)整。

snowflake的缺點(diǎn)：

• 對(duì)于時(shí)間依賴較高，如果時(shí)間回?fù)?，則會(huì)產(chǎn)生主鍵重復(fù)情況。
• 當(dāng)集群規(guī)模較大時(shí)，workid配置會(huì)增加一定成本。

美團(tuán)的Leaf-snowflake，使用zk解決了snowflake依賴于時(shí)鐘，時(shí)間回?fù)墚a(chǎn)生重復(fù)主鍵問(wèn)題;百度的UidGenerator，支持自定義時(shí)間戳、workerId、序列號(hào)等。

5. Redis模式

利用Redis原子操作INCR和INCRBY來(lái)實(shí)現(xiàn)，使用Redis集群提高并發(fā)量，與步長(zhǎng)模式類似，只不過(guò)將id生成器由傳統(tǒng)數(shù)據(jù)庫(kù)換成效率更高的Redis數(shù)據(jù)庫(kù)。但是當(dāng)Redis重啟或者宕機(jī)，記錄主鍵值會(huì)丟失，所以利用Redis進(jìn)行主鍵生成時(shí)需要對(duì)當(dāng)前主鍵值進(jìn)行持久化。Redis支持RDB和AOF兩種持久化機(jī)制。RDB模式下，可能會(huì)丟失部分未打鏡像的數(shù)據(jù)，根據(jù)快照恢復(fù)后會(huì)產(chǎn)生部分重復(fù)ID，故RDB不適合實(shí)施持久化Redis數(shù)據(jù)場(chǎng)景。AOF以獨(dú)立日志記錄每次寫(xiě)命令，重啟時(shí)執(zhí)行日志中的命令進(jìn)行數(shù)據(jù)恢復(fù)，不會(huì)出現(xiàn)ID重復(fù)現(xiàn)象，但是會(huì)由于備份命令過(guò)多，導(dǎo)致Redis恢復(fù)數(shù)據(jù)時(shí)間較長(zhǎng)。

以上介紹了五種數(shù)據(jù)庫(kù)主鍵的生成策略，大家可以根據(jù)具體業(yè)務(wù)場(chǎng)景和系統(tǒng)實(shí)際情況選擇一款最適合自己的主鍵策略，提升數(shù)據(jù)庫(kù)性能，保證在高并發(fā)情況下系統(tǒng)運(yùn)行穩(wěn)定性。