水平分庫分表的關鍵問題及解決思路

在以前的文章中，我介紹了分庫分表的幾種表現形式和玩法，也重點介紹了垂直分庫所帶來的問題和解決方法。本篇中，咱們將聊聊水平分庫分表的一些技巧。

01

分片技術的由來

關係型數據庫自己比較容易成爲系統性能瓶頸，單機存儲容量、鏈接數、處理能力等都頗有限，數據庫自己的「有狀態性」致使了它並不像Web和應用服務器那麼容易擴展。在互聯網行業海量數據和高併發訪問的考驗下，聰明的技術人員提出了分庫分表技術（有些地方也稱爲Sharding、分片）。同時，流行的分佈式系統中間件（例如MongoDB、ElasticSearch等）均自身友好支持Sharding，其原理和思想都是大同小異的。

02

分佈式全局惟一ID

在不少中小項目中，咱們每每直接使用數據庫自增特性來生成主鍵ID，這樣確實比較簡單。而在分庫分表的環境中，數據分佈在不一樣的分片上，不能再借助數據庫自增加特性直接生成，不然會形成不一樣分片上的數據表主鍵會重複。簡單介紹下使用和瞭解過的幾種ID生成算法。

1. Twitter的Snowflake（又名「雪花算法」）

2. UUID/GUID（通常應用程序和數據庫均支持）

3. MongoDB ObjectID（相似UUID的方式）

4. Ticket Server（數據庫生存方式，Flickr採用的就是這種方式） 

03

常見分片規則和策略

分片字段該如何選擇

在開始分片以前，咱們首先要肯定分片字段（也可稱爲「片鍵」）。不少常見的例子和場景中是採用ID或者時間字段進行拆分。這也並不絕對的，個人建議是結合實際業務，經過對系統中執行的sql語句進行統計分析，選擇出須要分片的那個表中最頻繁被使用，或者最重要的字段來做爲分片字段。

常見分片規則

常見的分片策略有隨機分片和連續分片這兩種，以下圖所示：

 

當須要使用分片字段進行範圍查找時，連續分片能夠快速定位分片進行高效查詢，大多數狀況下能夠有效避免跨分片查詢的問題。後期若是想對整個分片集羣擴容時，只須要添加節點便可，無需對其餘分片的數據進行遷移。可是，連續分片也有可能存在數據熱點的問題，就像圖中按時間字段分片的例子，有些節點可能會被頻繁查詢壓力較大，熱數據節點就成爲了整個集羣的瓶頸。而有些節點可能存的是歷史數據，不多須要被查詢到。

隨機分片其實並非隨機的，也遵循必定規則。一般，咱們會採用Hash取模的方式進行分片拆分，因此有些時候也被稱爲離散分片。隨機分片的數據相對比較均勻，不容易出現熱點和併發訪問的瓶頸。可是，後期分片集羣擴容起來須要遷移舊的數據。使用一致性Hash算法可以很大程度的避免這個問題，因此不少中間件的分片集羣都會採用一致性Hash算法。離散分片也很容易面臨跨分片查詢的複雜問題。

數據遷移，容量規劃，擴容等問題

不多有項目會在初期就開始考慮分片設計的，通常都是在業務高速發展面臨性能和存儲的瓶頸時纔會提早準備。所以，不可避免的就須要考慮歷史數據遷移的問題。通常作法就是經過程序先讀出歷史數據，而後按照指定的分片規則再將數據寫入到各個分片節點中。

此外，咱們須要根據當前的數據量和QPS等進行容量規劃，綜合成本因素，推算出大概須要多少分片（通常建議單個分片上的單表數據量不要超過1000W）。

若是是採用隨機分片，則須要考慮後期的擴容問題，相對會比較麻煩。若是是採用的範圍分片，只須要添加節點就能夠自動擴容。

04

跨分片技術問題

跨分片的排序分頁

通常來說，分頁時須要按照指定字段進行排序。當排序字段就是分片字段的時候，咱們經過分片規則能夠比較容易定位到指定的分片，而當排序字段非分片字段的時候，狀況就會變得比較複雜了。爲了最終結果的準確性，咱們須要在不一樣的分片節點中將數據進行排序並返回，並將不一樣分片返回的結果集進行彙總和再次排序，最後再返回給用戶。以下圖所示：

 

上面圖中所描述的只是最簡單的一種狀況（取第一頁數據），看起來對性能的影響並不大。可是，若是想取出第10頁數據，狀況又將變得複雜不少，以下圖所示：

 

有些讀者可能並不太理解，爲何不能像獲取第一頁數據那樣簡單處理（排序取出前10條再合併、排序）。其實並不難理解，由於各分片節點中的數據多是隨機的，爲了排序的準確性，必須把全部分片節點的前N頁數據都排序好後作合併，最後再進行總體的排序。很顯然，這樣的操做是比較消耗資源的，用戶越日後翻頁，系統性能將會越差。

跨分片的函數處理

在使用Max、Min、Sum、Count之類的函數進行統計和計算的時候，須要先在每一個分片數據源上執行相應的函數處理，而後再將各個結果集進行二次處理，最終再將處理結果返回。以下圖所示：

 

跨分片join

Join是關係型數據庫中最經常使用的特性，可是在分片集羣中，join也變得很是複雜。應該儘可能避免跨分片的join查詢（這種場景，比上面的跨分片分頁更加複雜，並且對性能的影響很大）。一般有如下幾種方式來避免：

全局表

全局表的概念以前在「垂直分庫」時提過。基本思想一致，就是把一些相似數據字典又可能會產生join查詢的表信息放到各分片中，從而避免跨分片的join。

ER分片

在關係型數據庫中，表之間每每存在一些關聯的關係。若是咱們能夠先肯定好關聯關係，並將那些存在關聯關係的表記錄存放在同一個分片上，那麼就能很好的避免跨分片join問題。在一對多關係的狀況下，咱們一般會選擇按照數據較多的那一方進行拆分。以下圖所示：

 

這樣一來，Data Node1上面的訂單表與訂單詳細表就能夠直接關聯，進行局部的join查詢了，Data Node2上也同樣。基於ER分片的這種方式，可以有效避免大多數業務場景中的跨分片join問題。

內存計算

隨着spark內存計算的興起，理論上來說，不少跨數據源的操做問題看起來彷佛都可以獲得解決。能夠將數據丟給spark集羣進行內存計算，最後將計算結果返回。

05

跨分片事務問題

跨分片事務也分佈式事務，想要了解分佈式事務，就須要瞭解「XA接口」和「兩階段提交」。值得提到的是，MySQL5.5x和5.6x中的xa支持是存在問題的，會致使主從數據不一致。直到5.7x版本中才獲得修復。Java應用程序能夠採用Atomikos框架來實現XA事務（J2EE中JTA）。感興趣的讀者能夠自行參考《分佈式事務一致性解決方案》，連接地址：

http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency

06

咱們的系統真的須要分庫分表嗎

讀完上面內容，不由引發有些讀者的思考，咱們的系統是否須要分庫分表嗎？

其實這點沒有明確的判斷標準，比較依賴實際業務狀況和經驗判斷。依照筆者我的的經驗，通常MySQL單表1000W左右的數據是沒有問題的（前提是應用系統和數據庫等層面設計和優化的比較好）。固然，除了考慮當前的數據量和性能狀況時，做爲架構師，咱們須要提早考慮系統半年到一年左右的業務增加狀況，對數據庫服務器的QPS、鏈接數、容量等作合理評估和規劃，並提早作好相應的準備工做。若是單機沒法知足，且很難再從其餘方面優化，那麼說明是須要考慮分片的。這種狀況能夠先去掉數據庫中自增ID，爲分片和後面的數據遷移工做提早作準備。

不少人以爲「分庫分表」是宜早不宜遲，應該儘早進行，由於擔憂越日後公司業務發展越快、系統愈來愈複雜、系統重構和擴展越困難…這種話聽起來是有那麼一點道理，但個人觀點剛好相反，對於關係型數據庫來說，我認爲「能不分片就別分片」，除非是系統真正須要，由於數據庫分片並不是低成本或者免費的。

這裏筆者推薦一個比較靠譜的過渡技術–「表分區」。主流的關係型數據庫中基本都支持。不一樣的分區在邏輯上還是一張表，可是物理上倒是分開的，能在必定程度上提升查詢性能，並且對應用程序透明，無需修改任何代碼。筆者曾經負責優化過一個系統，主業務表有大約8000W左右的數據，考慮到成本問題，當時就是採用「表分區」來作的，效果比較明顯，且系統運行的很穩定。

07

小結

最後，有不少讀者都想了解當前社區中有沒有開源免費的分庫分表解決方案，畢竟站在巨人的肩膀上能省力不少。當前主要有兩類解決方案：

1. 基於應用程序層面的DDAL（分佈式數據庫訪問層） 

比較典型的就是淘寶半開源的TDDL，噹噹網開源的Sharding-JDBC等。分佈式數據訪問層無需硬件投入，技術能力較強的大公司一般會選擇自研或參照開源框架進行二次開發和定製。對應用程序的侵入性通常較大，會增長技術成本和複雜度。一般僅支持特定編程語言平臺（Java平臺的居多），或者僅支持特定的數據庫和特定數據訪問框架技術（通常支持MySQL數據庫，JDBC、MyBatis、Hibernate等框架技術）。

2. 數據庫中間件，比較典型的像mycat（在阿里開源的cobar基礎上作了不少優化和改進，屬於後起之秀，也支持不少新特性），基於Go語言實現kingSharding，比較老牌的Atlas（由360開源）等。這些中間件在互聯網企業中大量被使用。另外，MySQL 5.x企業版中官方提供的Fabric組件也號稱支持分片技術，不過國內使用的企業較少。

中間件也能夠稱爲「透明網關」，大名鼎鼎的mysql_proxy大概是該領域的鼻祖（由MySQL官方提供，僅限於實現「讀寫分離」）。中間件通常實現了特定數據庫的網絡通訊協議，模擬一個真實的數據庫服務，屏蔽了後端真實的Server，應用程序一般直接鏈接中間件便可。而在執行SQL操做時，中間件會按照預先定義分片規則，對SQL語句進行解析、路由，並對結果集作二次計算再最終返回。引入數據庫中間件的技術成本更低，對應用程序來說侵入性幾乎沒有，能夠知足大部分的業務。增長了額外的硬件投入和運維成本，同時，中間件自身也存在性能瓶頸和單點故障問題，須要可以保證中間件自身的高可用、可擴展。

總之，無論是使用分佈式數據訪問層仍是數據庫中間件，都會帶來必定的成本和複雜度，也會有必定的性能影響。因此，還需讀者根據實際狀況和業務發展須要慎重考慮和選擇。

擴展閱讀

Redis 分佈式鎖：樂觀鎖的實現，以秒殺系統爲例

基於redis的分佈式鎖的分析與實踐

關於Java鎖機制面試官會怎麼問

Java讀寫鎖實現原理

完全理解Netty，這一篇文章就夠了

做者：丁浪

來源：https://www.cnblogs.com/dinglang/p/6084306.html