建站
咨詢
售后
建站咨詢
新聞中心
本篇內(nèi)容介紹了“關(guān)于主鍵的知識點有哪些”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！
安州網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、響應式網(wǎng)站建設等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)從2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)。
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適合應用于分布式計算環(huán)境下，具有高度的唯一性;Version 3/5適合于需要相同內(nèi)容生成相同UUID的業(yè)務場景下；Version 4建議不要使用(隨機數(shù)有可能出現(xiàn)重復，但是重復的概率極低，在設計時需要考慮到這一點)。
UUID雖然解決了依賴于數(shù)據(jù)庫生成主鍵的策略，但是也存在一些不足：占用存儲空間大;隨機生成，不具有連續(xù)性，作為主鍵時性能較差;無法根據(jù)主鍵進行排序，確定記錄插入的先后順序;對于開發(fā)人員不友好;如果生成過程中使用了機器MAC地址，存在一定安全隱患。
2. 步長模式
即Flickr的sharding主鍵生成方案。使用多臺數(shù)據(jù)庫服務器，通過設置不同的起始值、一致自增步長，讓每個數(shù)據(jù)庫中各表主鍵保持唯一。如圖所示：
步長方式在一定程度上解決了高并發(fā)的問題，但是也存在一些問題如：擴展困難，設置好步長后，再進行擴展將會比較困難;ID并不是按順序嚴格單調(diào)遞增的特性，只是趨勢遞增;每次獲取ID仍然需要讀寫一次數(shù)據(jù)庫，仍然存在瓶頸。
3. 號段模式
即每次從數(shù)據(jù)庫獲取id時，從數(shù)據(jù)庫取到當前id最大值，然后返回max+step，當應用程序用完這個號段后，再從數(shù)據(jù)庫獲取下一個長度為step的號段。為此需要專門設計一張用以記錄id的表，在應用服務為集群，而主鍵服務器為單點時，多個應用服務節(jié)點同時獲取id時，會產(chǎn)生沖突，可以增加version字段從而使用樂觀鎖進行并發(fā)訪問控制。
號段模式將主鍵緩存在應用服務端，從而減少對數(shù)據(jù)庫的訪問頻率;在數(shù)據(jù)庫數(shù)據(jù)庫不可用時，應用服務仍然可以持續(xù)運行一段時間直到當前號段用完;但是在應用服務重啟時有可能丟失部分id，導致id增長不連續(xù)。
基于號段模式有一些成熟方案，且經(jīng)過實踐驗證：美團的Leaf-segment對號段發(fā)放方式進行了雙buffer緩存及高可用容災優(yōu)化。采用雙buffer模式，在當前號段消費到某個點時就異步的把下一個號段加載到內(nèi)存中。而不需要等到號段用盡的時候才去更新號段，不會在應用服務器向數(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ù)庫，可以由應用程序生成。
在分布式集群內(nèi)不會產(chǎn)生重復id。
可以根據(jù)業(yè)務需求對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è)務場景和系統(tǒng)實際情況選擇一款最適合自己的主鍵策略，提升數(shù)據(jù)庫性能，保證在高并發(fā)情況下系統(tǒng)運行穩(wěn)定性。
“關(guān)于主鍵的知識點有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！
當前文章：關(guān)于主鍵的知識點有哪些
標題網(wǎng)址：http://fisionsoft.com.cn/article/jdsgei.html
