關(guān)于主鍵的知識(shí)點(diǎn)有哪些

本篇內(nèi)容介紹了“關(guān)于主鍵的知識(shí)點(diǎn)有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

1. UUID模式

通用唯一識(shí)別碼(Universally Unique  Identifier)，根據(jù)標(biāo)準(zhǔn)方法生成，不依賴中央機(jī)構(gòu)的注冊和分配，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ù)場景下；Version  4建議不要使用(隨機(jī)數(shù)有可能出現(xiàn)重復(fù)，但是重復(fù)的概率極低，在設(shè)計(jì)時(shí)需要考慮到這一點(diǎn))。

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

2. 步長模式

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

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

3. 號(hào)段模式

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

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

基于號(hào)段模式有一些成熟方案，且經(jīng)過實(shí)踐驗(yàn)證：美團(tuán)的Leaf-segment對號(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ù)庫請求id時(shí)，因?yàn)閕d號(hào)段沒有取回來，導(dǎo)致線程阻塞。

滴滴的TinyId參照了美團(tuán)Leaf的實(shí)現(xiàn)方式，并對其做了擴(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í)間趨勢進(jìn)行遞增。

• 主鍵的生成不依賴于數(shù)據(jù)庫，可以由應(yīng)用程序生成。

• 在分布式集群內(nèi)不會(huì)產(chǎn)生重復(fù)id。

• 可以根據(jù)業(yè)務(wù)需求對bit位進(jìn)行調(diào)整。

snowflake的缺點(diǎn)：

• 對于時(shí)間依賴較高，如果時(shí)間回?fù)埽瑒t會(huì)產(chǎn)生主鍵重復(fù)情況。

• 當(dāng)集群規(guī)模較大時(shí)，workid配置會(huì)增加一定成本。

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

5. Redis模式

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

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

“關(guān)于主鍵的知識(shí)點(diǎn)有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！