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

[[338977]]

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

1. UUID模式

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

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

2. 步長模式

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

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

3. 號段模式

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

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

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

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

4. snowflake模式(雪花算法)

Twitter實現的分布式ID生成算法。結構如下：0-00000000000000000000000000000000000000000-00000-00000-000000000000

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

snowflake的優(yōu)點：

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

snowflake的缺點：

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

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

5. Redis模式

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

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