在此之前我們介紹了數(shù)據(jù)庫的分庫分表問題，分庫分表可以給我們帶來非常好的擴展性與性能上的提升，但也隨之帶來一些問題，例如數(shù)據(jù)的主鍵ID分配問題。我們以Mysql為例，通常我們使用的是數(shù)據(jù)庫的自增主鍵，我們在分表的時候也盡量保證業(yè)務(wù)上不需要跨表查詢數(shù)據(jù)，但是難免會遇到這樣的場景，這個時候我們就會面臨這樣一個問題，如果兩張表上面的主鍵ID重復(fù)，那么業(yè)務(wù)就會出錯，帶來不可估量的后果。

[[311996]]

那么我們?nèi)绾谓鉀Q主鍵唯一的問題呢?這里我們介紹幾種常見的方法，以及他們的優(yōu)缺點。

方法一

首先我們可以利用隨機方法生成主鍵，通常，只要隨機算法合理，適當?shù)丶狱c鹽，生成的64位的主鍵ID，重復(fù)的概率極低(幾乎可以不用考慮碰撞)，這種方法的優(yōu)點是實現(xiàn)非常簡單，但是存在什么問題呢?首先是ID的長度會非常的長，我們都知道，在數(shù)據(jù)庫中，主鍵ID過長會降低索引的性能。其次，隨機生成主鍵ID是無序的，這就意味著插入新的數(shù)據(jù)的時候，都需要插入索引，我們都知道Mysql的索引是B+樹，B+樹如果不停地插入無序的數(shù)據(jù)，性能會大大降低，造成的結(jié)果就是插入性能降低。聰明的同學可能已經(jīng)想到了，我們也可以生成有序的隨機數(shù)，例如使用Twitter公司的SnowFlake，可以一定程度上避免B+樹插入帶來的影響。

方法二

第二種方法，我們還是可以利用數(shù)據(jù)庫的主鍵遞增特性。在Mysql數(shù)據(jù)庫中，是可以設(shè)置主鍵遞增的步長，也就是我們不必在1,2,3這樣遞增，假如我們設(shè)置步長為10，開始為10，那就是10,20,30了。假如我們分了10張表，那么我們可以讓每個表的起始分別是0到9，然后步長設(shè)置為10，這樣子就可以保證十張表里面的數(shù)據(jù)不會重復(fù)了。這種方法的優(yōu)點同樣非常簡單，只需要簡單的配置而已，那么它存在什么問題呢?首先是擴展非常的不方便，如果我們想要把分表從10改成20呢?會給我們帶來一定的麻煩。

方法三

第三種方法，我們可以維護一個ID分配器，我們可以使用Redis等相關(guān)組件，將提前分配好的ID放在Redis的隊列當中，每次業(yè)務(wù)要插入的時候，先從預(yù)分配的隊列中取一個元素出來，然后再插入數(shù)據(jù)庫當中。當然這種做法需要一定的開發(fā)量，可以相對保證主鍵id的順序，擴展也相對的簡單。

總結(jié)

那么哪一種方法好呢?在計算機程序設(shè)計中，沒有絕對的好也沒有絕對地差，只要能夠貼近業(yè)務(wù)，保證系統(tǒng)平穩(wěn)運行，又不需要較大的開發(fā)與維護成本，那就是好方法，需要根據(jù)自己的業(yè)務(wù)與現(xiàn)在的開發(fā)運維經(jīng)驗進行選擇。歡迎大家關(guān)注我，共同學習，共同進步。大家的支持是我繼續(xù)嘮嗑的動力。