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

[[338977]]

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

1. UUID模式

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

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

2. 步長模式

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

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

3. 號段模式

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

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

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

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

4. snowflake模式(雪花算法)

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

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

snowflake的優(yōu)點：

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

snowflake的缺點：

• 對于時間依賴較高，如果時間回撥，則會產(chǎn)生主鍵重復情況。
• 當集群規(guī)模較大時，workid配置會增加一定成本。

美團的Leaf-snowflake，使用zk解決了snowflake依賴于時鐘，時間回撥產(chǎn)生重復主鍵問題;百度的UidGenerator，支持自定義時間戳、workerId、序列號等。

5. Redis模式

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

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