分布式儲存 Mysql 序列3 分庫分表策略

分庫分表是儲存層設計中乙個普遍而重大的問題，什麼時候分？怎麼分？分完之後引發的新問題，比如不能join、分布式事務？本篇將從最基本的策略出發，逐步深入講解這裡面涉及的一串行策略。

分庫的首先目的就是做「業務分拆「，關於業務分拆，在前面的序列文章「分布式系統－－基本思想彙總「中已經有闡述。通過業務分拆，把乙個大的複雜系統拆成多個業務子系統，之間通過rpc或訊息中介軟體通訊。這樣做既便於團隊成員的職責分工，也便於對未來某個系統做擴充套件。

另外乙個考慮角度是「資料隔離"。如果你把核心業務的資料和非核心業務資料放在乙個庫裡面，不分輕重，同等對待。這樣如果因為非核心業務把db搞掛了，核心業務也受到牽連。分開之後，區別對待，投入的開發和運維人力也不一樣。

對於業務來講，讀多寫少/讀少寫多，所對應的策略是不一樣的。

如果是讀多寫少，那你可以通過加從庫、加快取來解決，不一定要分庫分表。

如果是讀少寫多，或者說寫入的qps已經達到了db的瓶頸，這個時候就得考慮分庫分表了。

對於mysql來講，一般寫入的qps有3k/s左右，讀寫的qps可以達到2萬/s。可見寫入和查詢的吞吐量區別是很大的。

考慮了上面2個策略之後，最後萬不得已，再做分庫分表。因為分庫分表的代價是很大的，意味著**要大規模重構，以前能用的join，事務可能都不能用了，需要用新的辦法解決。

垂直切分一般主要用於表的字段太多（比如上百個字段），這種情形通常就對應著上層業務沒有很好的分拆，解耦。如果做好了上面的「業務分拆」，需要這種「垂直切分」的場景可能就會變得很少。下面主要講「水平切分」。

當表的記錄數太多，幾千萬，上億，並且有很高的寫入qps，這個時候就得考慮水平切分了。

一般思路是：保證單錶的記錄條數不要超過千萬，然後根據總資料量估算出要拆多少個表，再考慮把這些表分散到多少個庫裡面。

水平切分的最關鍵問題就是：拆分維度的選擇。

比如電商的訂單表，至少有3個查詢維度：訂單id，使用者id，商戶id。那你拆分的時候，根據哪個維度進行拆分呢？

假設你按使用者id拆分，同乙個使用者的所有訂單記錄都落到同1個庫的同1張表裡面。那查詢的時候，按user id查，就很容易；

但如果按訂單id，或者商戶id呢？拆分之後，同1個商戶id的訂單，可能被分到了不同的庫、不同的表裡面，根本沒辦法查。

對於這種分庫分表之後，其他維度的查詢，一般有以下幾個辦法：

（1）建立乙個對映表，建立輔助維度和主維度之間的對映關係（也就是商戶id和使用者id之間的對映關係）。

查詢的時候，根據商戶id，查出使用者id。再根據使用者id，來查

（2）業務雙寫

同1份資料，2套分庫分表。1套按user id切分，1套按商戶id 切分。這個其實也就是我在」分布式系統－－基本思想彙總「中所用的「重寫輕讀」

（3）非同步雙寫

還是2套表，只是業務單寫。然後通過binlog同步（比如阿里的canal，點評的puma)，同步到另外一套表上。

（4）2個維度統一到1個維度

這個在特殊的場景下可以使用。比如order id和user id就可以統一成1個維度，把user id作為order id中的某幾位，這樣order id中就包含了user id資訊。

然後按照user id 分庫，當按照order id查詢的時候，截取出user id，在按user id查詢。但反過來就不行，按order id分庫了，再按user id就不能查了。

分庫分表之後，有些join就不能用了，針對這種情況，一般有下面幾種解決辦法：

（1）把join拆成多個單錶查詢，上層業務**進行結果拼裝

（2）提前做寬邊，重寫輕讀

很多時候，你有這樣的情況：需要把join的結果分頁，這個需要利用mysql本身的分頁功能。對於這種不得不用join的情況，可以另外做乙個join表，提前把結果join好。這是「重寫輕讀」，其實也是「空間換時間」的思路。

（3）利用搜尋引擎

對於（2）當中提到的場景，還可以利用lucence，es這種搜尋引擎，把db中資料匯入到搜尋引擎中來查詢，從而解決join問題。

如果實在無法避免，那就需要分布式事務的解決方案了。關於分布式事務，又是乙個系統化的課題，沒有乙個標準答案。

後續文章會詳細闡述這個問題，敬請期待！