數(shù)據(jù)庫自增 ID

搞一個數(shù)據(jù)庫，什么也不干，就用于生成主鍵。

你的系統(tǒng)里每次得到一個 id，都需要往那個專門生成主鍵的數(shù)據(jù)庫中通過插入獲取一個自增的ID，拿到這個 id 之后再往對應(yīng)的分庫分表里去寫入。

優(yōu)點(diǎn)：方便簡單。

缺點(diǎn)：單庫生成自增 id，要是高并發(fā)的話，就會有瓶頸的；如果你硬是要改進(jìn)一下，那么就專門開一個服務(wù)出來，這個服務(wù)每次就拿到當(dāng)前 id 最大值，然后自己遞增幾個 id，一次性返回一批 id，然后再把當(dāng)前最大 id 值修改成遞增幾個 id 之后的一個值；但是無論如何都是基于單個數(shù)據(jù)庫。

適合的場景：系統(tǒng)并發(fā)不大，只是因為數(shù)據(jù)量大的原因而去做的分庫分表的話，可以采用這種方式。

設(shè)置數(shù)據(jù)庫 sequence 或者表自增字段步長

可以通過設(shè)置數(shù)據(jù)庫 sequence 或者表的自增字段步長來進(jìn)行水平伸縮。

比如說，現(xiàn)在有 8 個服務(wù)節(jié)點(diǎn)，每個服務(wù)節(jié)點(diǎn)使用一個 sequence 功能來產(chǎn)生 ID，每個 sequence 的起始 ID 不同，并且依次遞增，步長都是8

適合的場景：在用戶防止產(chǎn)生的 ID 重復(fù)時，這種方案實現(xiàn)起來比較簡單，也能達(dá)到性能目標(biāo)。但是服務(wù)節(jié)點(diǎn)固定，步長也固定，將來如果還要增加服務(wù)節(jié)點(diǎn)，就不好搞了。

UUID

優(yōu)點(diǎn)：本地生成，不需要基于數(shù)據(jù)庫；

缺點(diǎn)：UUID 太長了、占用空間大；作為主鍵性能太差：UUID 不具有有序性，會導(dǎo)致 B+ 樹索引在寫的時候有過多的隨機(jī)寫操作（連續(xù)的 ID 可以產(chǎn)生部分順序?qū)懀?，還有，由于在寫的時候不能產(chǎn)生有順序的 append 操作，而需要進(jìn)行 insert 操作，導(dǎo)致頻繁的進(jìn)行頁分裂，性能下降明顯。

適合的場景：如果你是要隨機(jī)生成個什么文件名、編號之類的，你可以用 UUID，但是作為InnoDB表的主鍵是不能用 UUID 的。

UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf

系統(tǒng)當(dāng)前時間戳+XXX

適合的場景：一般如果用這個方案，是將當(dāng)前時間戳跟很多其他的業(yè)務(wù)字段拼接起來，作為一個 id，如果業(yè)務(wù)上你覺得可以接受，那么也是可以的。你可以將別的業(yè)務(wù)字段值跟當(dāng)前時間拼接起來，組成一個全局唯一的編號。

Snowflake 算法

snowflake 算法是 twitter 開源的分布式 id 生成算法，采用 Scala 語言實現(xiàn)，是把一個 64 位的 long 型的 id，1 個 bit 是不用的，用其中的 41 bit 作為時間戳（毫秒數(shù)），用 10 bit 作為工作機(jī)器 id，12 bit 作為序列號。

• 1 bit：不用，為啥呢？因為二進(jìn)制里第一個 bit 為如果是 1，那么都是負(fù)數(shù)，但是我們生成的 id 都是正數(shù)，所以第一個 bit 統(tǒng)一都是 0。
• 41 bit：表示的是時間戳，單位是毫秒。41 bit 可以表示的數(shù)字多達(dá) 2^41 - 1，也就是可以標(biāo)識 2^41 - 1 個毫秒值，換算成年就是表示69年的時間。
• 10 bit：記錄工作機(jī)器 id，代表的是這個服務(wù)最多可以部署在 2^10臺機(jī)器上哪，也就是1024臺機(jī)器。但是 10 bit 里 5 個 bit 代表機(jī)房 id，5 個 bit 代表機(jī)器 id。意思就是最多代表 2^5個機(jī)房（32個機(jī)房），每個機(jī)房里可以代表 2^5 個機(jī)器（32臺機(jī)器）。
• 12 bit：這個是用來記錄同一個毫秒內(nèi)產(chǎn)生的不同 id，12 bit 可以代表的最大正整數(shù)是 2^12 - 1 = 4096，也就是說可以用這個 12 bit 代表的數(shù)字來區(qū)分同一個毫秒內(nèi)的 4096 個不同的 id。

0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000

到此這篇關(guān)于Mysql分庫分表之后主鍵處理的幾種方法的文章就介紹到這了,更多相關(guān)Mysql分庫分表主鍵內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論