關于主鍵的知識點有哪些

本篇內容介紹了“關于主鍵的知識點有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1. UUID模式

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

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

2. 步長模式

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

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

3. 號段模式

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

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

基于號段模式有一些成熟方案，且經過實踐驗證：美團的Leaf-segment對號段發放方式進行了雙buffer緩存及高可用容災優化。采用雙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位序列號，按順序遞增，記錄每個節點1毫秒內產生的id，每毫秒可以產生4096個id。

snowflake的優點：

• 主鍵在單個節點上是按序列遞增的，能夠按照時間趨勢進行遞增。

• 主鍵的生成不依賴于數據庫，可以由應用程序生成。

• 在分布式集群內不會產生重復id。

• 可以根據業務需求對bit位進行調整。

snowflake的缺點：

• 對于時間依賴較高，如果時間回撥，則會產生主鍵重復情況。

• 當集群規模較大時，workid配置會增加一定成本。

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

5. Redis模式

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

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

“關于主鍵的知識點有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！