關於大型網站技術演進的思考（四）--儲存的瓶頸（4）

　　如果資料庫需要進行水平拆分，這其實是一件很開心的事情，因為它代表公司的業務正在迅猛的增長，對於開發人員而言那就是有不盡的專案可以做，雖然會感覺很忙，但是人過的充實，心裡也踏實。

　　資料庫水平拆分簡單說來就是先將原資料庫裡的一張表在做垂直拆分出來放置在單獨的資料庫和單獨的表裡後更進一步的把本來是一個整體的表進一步拆分成多張表，每一張表都用獨立的資料庫進行儲存。當表被水平拆分後，原資料表成為了一個邏輯的概念，而這個邏輯表的業務含義需要多張物理表協同完成，因此資料庫的表被水平拆分後，那麼我們對這張表的操作已經超出了資料庫本身提供給我們現有的手段，換句話說我們對錶的操作會超出資料庫本身所擁有的處理能力，這個時候我就需要設計相關的方案來彌補資料庫缺失的能力，這就是資料庫水平拆分最大的技術難點所在。

　　資料庫的水平拆分是資料庫垂直拆分的升級版，它和垂直拆分更像繼承機制裡的父子關係，因此水平拆分後，垂直拆分所遇到的join查詢的問題以及分散式事務的問題任然存在，由於表被物理拆解增加了邏輯表的維度，這也給垂直拆分裡碰到的兩個難題增加了更多的維度，因此水平拆分裡join查詢的問題和分散式事務會變得更加複雜。水平拆分除了垂直拆分兩個難題外，它還會產生新的技術難題，這些難題具體如下：

　　難題一：資料庫的表被水平拆分後，該表的主鍵設計會變得十分困難；

　　難題二：原來單表的查詢邏輯會面臨挑戰。

　　在準備本篇文章時候，我看到一些資料裡還提到了一些難題，這些難題是：

　　難題三：水平拆分表後，外來鍵的設計也會變得十分困難；

　　難題四：這個難題是針對資料的新增操作的，大致的意思是，我們到底按什麼規則把需要儲存的資料儲存在拆分出的那個具體的物理資料表裡。

　　難題三的問題，我在上篇已經給出瞭解答，這裡我進行一定的補充，其實外來鍵問題在垂直拆分就已經存在，不過在講垂直拆分時候我們沒有講到這個問題，這主要是我設定了一個前提，就是資料表在最原始的資料建模階段就要拋棄所有外來鍵的設計，並將外來鍵的邏輯拋給服務層去完成，我們要盡全力減輕資料庫承擔的運算壓力，其實除了減輕資料庫運算壓力外，我們還要將作為儲存原子的表保持相對的獨立性，互不關聯，那麼要做到這點最直接的辦法就是去掉表與表之間關聯的象徵：外來鍵，這樣我們就可以從根基上為將來資料庫做垂直拆分和水平拆分打下堅實的基礎。

　　至於難題四，其實問題的本質是分庫分表後具體的資料在哪裡落地的問題，而資料儲存在表裡的關鍵障礙其實就是主鍵，試想一下，我們設計張表，所有欄位我們都准許可以為空，但是表裡有個欄位是絕對不能為空的，那就是主鍵，主鍵是資料在資料庫裡身份的象徵，因此我們在主鍵設計上是可以體現出該資料的落地規則，那麼難題四也會隨之解決。因此下文我會重點講解前兩個水平拆分的難題。

　　首先是水平拆分裡的主鍵設計問題，拋開所有主鍵所能代表的業務含義，資料庫裡標的主鍵本質是表達表裡的某一條記錄的唯一性，在設計資料庫的時候我們可以由一個絕對不可重複的欄位表示主鍵，也可以使用多個欄位組合起來表達這種唯一性，使用一個欄位表示主鍵，這已經是很原子級的操作，沒法做進一步的修改，但是如果使用多個欄位表示一個主鍵對於水平拆分而言就會碰到問題了，這個問題主要是體現在資料到底落地於哪個資料庫，關於主鍵對資料落地的影響我會在把相關知識講解完畢後再著重闡述，這裡要提的是當碰到聯合主鍵時候我們可以設定一個沒有任何業務含義的欄位來替代，不過這個要看場景了，我傾向於將聯合主鍵各個欄位裡的值合併為一個欄位來表示主鍵，如果有的朋友認為這樣會導致資料冗餘，那麼可以乾脆去掉原來做聯合主鍵的相關欄位就是用一個欄位表示，只不過歸併欄位時候使用一個分隔符，這樣方便服務層進行業務上的拆分。

　　由上所述，這裡我給出水平拆分主鍵設計的第一個原則：被水平拆分的表的主鍵設計最好使用一個欄位表示。

　　如果我們的主鍵只是表達記錄唯一性的話，那麼水平拆分時候相對要簡單的多，例如在Oracle資料庫裡有一個sequence機制，這其實就是一個自增數的演算法，自增機制幾乎所有關聯式資料庫都有，也是我們平時最喜歡使用的主鍵欄位設計方案，如果我們要拆分的表，使用了自增欄位，同時這個自增欄位只是用來表達記錄唯一性，那麼水平拆分時候處理起來就簡單多了，我這裡給出兩個經典方案，方案如下：

　　方案一：自增列都有設定步長的特性，假如我們打算把一張表只拆分為兩個物理表，那麼我們可以在其中一張表裡把主鍵的自增列的步長設計為2，起始值為1，那麼它的自增規律就是1,3,5,7依次類推，另外一張物理表的步長我們也可以設定為2，如果起始值為2，那麼自增規律就是2,4,6,8以此類推，這樣兩張表的主鍵就絕對不會重複了，而且我們也不用另外做兩張物理表相應的邏輯關聯了。這種方案還有個潛在的好處，那就是步長的大小和水平資料拆分的粒度關聯，也是我們為水平拆分的擴容留有餘量，例如我們把步長設計為9，那麼理論上水平拆分的物理表可以擴容到9個。

　　方案二：拆分出的物理表我們允許它最多儲存多少資料，我們其實事先通過一定業務技術規則大致估算出來，假如我們估算一張表我們最多讓它儲存2億條，那麼我們可以這麼設定自增列的規律，第一張物理表自增列從1開始，步長就設為1，第二種物理表的自增列則從2億開始，步長也設為1，自增列都做最大值的限制，其他的依次類推。

　　那麼如果表的主鍵不是使用自增列，而是業務設計的唯一欄位，那麼我們又如何處理主鍵分佈問題了？這種場景很典型，例如交易網站裡一定會有訂單表，流水錶這樣的設計，訂單表裡有訂單號，流水錶裡有流水號，這些編號都是按一定業務規則定義並且保證它的唯一性，那麼前面的自增列的解決方案就沒法完成它們做水平拆分的主鍵問題，那麼碰到這個情況我們又該如何解決了？我們仔細回味下資料庫的水平拆分，它其實和分散式快取何其的類似，資料庫的主鍵就相當於分散式快取裡的鍵值，那麼我們可以按照分散式快取的方案來設計主鍵的模型，方案如下：

　　方案一：使用整數雜湊求餘的演算法，字串如果進行雜湊運算會得出一個值，這個值是該字串的唯一標誌，如果我們稍微改變下字串的內容，計算的雜湊值肯定是不同，兩個不同的雜湊值對應兩個不同字串，一個雜湊值有且只對應唯一一個字串，加密演算法裡的MD5，SHA都是使用雜湊演算法的原理計算出一個唯一標示的雜湊值，通過雜湊值的匹配可以判斷資料是否被篡改過。不過大多數雜湊演算法最後得出的值都是一個字元加數字的組合，這裡我使用整數雜湊演算法，這樣計算出的雜湊值就是一個整數。接下來我們就要統計下我們用於做水平拆分的伺服器的數量，假如伺服器的數量是3個，那麼接著我們將計算的整數雜湊值除以伺服器的數量即取模計算，通過得到的餘數來選擇伺服器，該演算法的原理圖如下所示：

　　方案二：就是方案一的升級版一致性雜湊，一致性雜湊最大的作用是保證當我們要擴充套件物理資料表的數量時候以及物理表叢集中某臺伺服器失效時候才會體現，這個問題我後續文章會詳細討論物理資料庫擴容的問題，因此這裡先不展開討論了。

　　由上所述，我們發現在資料庫進行水平拆分時候，我們設定的演算法都是通過主鍵唯一性進行的，根據主鍵唯一性設計的特點，最終資料落地於哪個物理資料庫也是由主鍵的設計原則所決定的，回到上文裡我提到的如果原庫的資料表使用聯合欄位設計主鍵，那麼我們就必須首先合併聯合主鍵欄位，然後通過上面的演算法來確定資料的落地規則，雖然不合並一個欄位看起來也不是太麻煩，但是在我多年開發裡，把唯一性的欄位分割成多個欄位，就等於給主鍵增加了維度，欄位越多，維度也就越大，到了具體的業務計算了我們不得不時刻留心這些維度，結果就很容易出錯，我個人認為如果資料庫已經到了水平拆分階段了，那麼就說明資料庫的儲存的重要性大大增強，為了讓資料庫的儲存特性變得純粹乾淨，我們就得盡力避免增加資料庫設計的複雜性，例如去掉外來鍵，還有這裡的合併聯合欄位為一個欄位，其實為了降低難度，哪怕做點必要的冗餘也是值得。

　　解決資料庫表的水平拆分後的主鍵唯一性問題有一個更加直接的方案，這也是很多人碰到此類問題很自然想到的方法，那就是把主鍵生成規則做成一個主鍵生成系統，放置在單獨一臺伺服器上統一生成，每次新增資料主鍵都從這個伺服器裡獲取，主鍵生成的演算法其實很簡單，很多語言都有計算UUID的功能，UUID是根據所在伺服器的相關的硬體資訊計算出的全球唯一的標示，但是這裡我並沒有首先拿出這個方案，因為它相比如我前面的方案缺點太多了，下面我要細數下它的缺點，具體如下：

　　缺點一：把主鍵生成放到外部伺服器進行，這樣我們就不得不通過網路通訊完成主鍵值的傳遞，而網路是計算機體系裡效率最低效的方式，因此它會影響資料新增的效率，特別是資料量很大時候，新增操作很頻繁時候，該缺點會被放大很多；

　　缺點二：如果我們使用UUID演算法做主鍵生成的演算法，因為UUID是依賴單臺伺服器進行，那麼整個水平拆分的物理資料庫叢集，主鍵生成器就變成整個體系的短板，而且是關鍵短板，主鍵生成伺服器如果失效，整個系統都會無法使用，而一張表需要被水平拆分，而且拆分的表是業務表的時候，那麼這張表在整個系統裡的重要度自然很高，它如果做了水平拆分後出現單點故障，這對於整個系統都是致命的。當然有人肯定說，既然有單點故障，那麼我們就做個叢集系統，問題不是解決了嗎？這個想法的確可以解決我上面闡述的問題，但是我前文講到過，現實的軟體系統開發裡我們要堅守一個原則那就是有簡單方案儘量選擇簡單的方案解決問題，引入叢集就是引入了分散式系統，這樣就為系統開發增加了開發難度和運維風險，如果我們上文的方案就能解決我們的問題，我們何必自討苦吃做這麼複雜的方案呢？

　　缺點三：使用外部系統生成主鍵使得我們的水平拆分資料庫的方案增加了狀態性，而我上面提到的方案都是無狀態的，有狀態的系統會相互影響，例如使用外部系統生成主鍵，那麼當資料操作增大時候，必然會造成在主鍵系統上資源競爭的事情發生，如果我們對主鍵系統上的競爭狀態處理不好，很有可能造成主鍵系統被死鎖，這也就會產生我前文裡說到的503錯誤，而無狀態的系統是不存在資源競爭和死鎖的問題，這洋就提升了系統的健壯性，無狀態系統另一個優勢就是水平擴充套件很方便。

　　這裡我列出單獨主鍵生成系統的缺點不是想說明我覺得這種解決方案完全不可取，這個要看具體的業務場景，根據作者我的經驗還沒有找到一個很合適使用單獨主鍵生成器的場景。

　　上文裡我提出的方案還有個特點就是能保證資料在不同的物理表裡均勻的分佈，均勻分佈能保證不同物理表的負載均衡，這樣就不會產生系統熱點，也不會讓某臺伺服器比其他伺服器做的事情少而閒置資源，均勻分配資源可以有效的利用資源，降低生產的成本提高生產的效率，但是均勻分散式資料往往會給我們業務運算帶來很多麻煩。

　　水平拆分資料庫後我們還要考慮水平擴充套件問題，例如如果我們事先使用了3臺伺服器完成了水平拆分，如果系統執行到一定階段，該表又遇到儲存瓶頸了，我們就得水平擴容資料庫，那麼如果我們的水平拆分方案開始設計的不好，那麼擴容時候就會碰到很多的麻煩。

關於大型網站技術演進的思考（四）--儲存的瓶頸（4）

相關文章