由于業(yè)務(wù)需要，需要對(duì)Mysql數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表，故而最近一直在整理分庫(kù)分表的相關(guān)知識(shí)，現(xiàn)手上的工作也告一段落了，抽空將自己最近的學(xué)習(xí)結(jié)果轉(zhuǎn)化為博文，分享給大家，本博文打算做成一個(gè)系列的，首先是分庫(kù)分表的理論知識(shí)的了解，其次是基于Java編程語(yǔ)言的分庫(kù)分表的框架的開發(fā)，最后是分庫(kù)分表的編制。讓大家不僅僅從理論上了解mysql的分庫(kù)分表，通過代碼來更深層次的了解，理論是如何落地到實(shí)踐的。最后非常感謝《可伸縮服務(wù)架構(gòu) 框架與中間件》這本書的作者么，本博文的代碼實(shí)現(xiàn)是參考此書，然后結(jié)合當(dāng)前系統(tǒng)平臺(tái)框架開發(fā)而成。

堅(jiān)持我寫作的一貫風(fēng)格，我們先需要帶著問題來了解mysql的分庫(kù)分表

• 什么是分庫(kù)分表，為什么我們需要分庫(kù)分表
• 如何進(jìn)行分庫(kù)分表，有什么優(yōu)缺點(diǎn)
• 對(duì)于分庫(kù)分表有哪些架構(gòu)設(shè)計(jì)，對(duì)于后期的擴(kuò)容擴(kuò)展怎么樣
• 目前行業(yè)內(nèi)流行的解決方案有哪些？各自有什么特點(diǎn)
• 自己設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)分庫(kù)分表的框架，如何設(shè)計(jì)，需要考慮哪些因素

為什么需要分庫(kù)分表

隨著我們的系統(tǒng)運(yùn)行，存儲(chǔ)在關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)量會(huì)越來越大，系統(tǒng)的訪問的壓力也會(huì)隨之增大，如果一個(gè)庫(kù)中的表數(shù)據(jù)超過了一定的數(shù)量，比如說mysql中的表數(shù)據(jù)達(dá)到千萬(wàn)級(jí)別，就需要考慮進(jìn)行分庫(kù)分表；

其次隨著表數(shù)據(jù)的不斷增大，會(huì)發(fā)現(xiàn)，查詢也隨著變得緩慢，如果添加索引的話，會(huì)發(fā)現(xiàn)影響到了新增和刪除的性能，如果我們將數(shù)據(jù)庫(kù)分散到不同的表上，單表的索引大小就得到了控制，對(duì)索引以及表結(jié)構(gòu)的變更會(huì)變得很方便和高效；

當(dāng)數(shù)據(jù)庫(kù)實(shí)例的吞吐量達(dá)到性能的瓶頸時(shí)，我們需要擴(kuò)展數(shù)據(jù)庫(kù)實(shí)例，讓每個(gè)數(shù)據(jù)庫(kù)實(shí)例承擔(dān)其中一部分?jǐn)?shù)據(jù)庫(kù)的請(qǐng)求，分解總體的大請(qǐng)求量的壓力；

在數(shù)據(jù)庫(kù)進(jìn)行擴(kuò)容的時(shí)候?qū)?yīng)用層的配置改變最少， 就需要在每個(gè)數(shù)據(jù)庫(kù)實(shí)例中預(yù)留足夠的數(shù)據(jù)庫(kù)數(shù)量

以上的情況我們都可以使用分庫(kù)分表，那么什么是分庫(kù)分表呢？

簡(jiǎn)而言之就是數(shù)據(jù)拆分：將一個(gè)表結(jié)構(gòu)分為多個(gè)表，或者將一個(gè)表數(shù)據(jù)分片后放入多個(gè)表，這些表可以放在同一個(gè)數(shù)據(jù)庫(kù)里，也可以放到不同的數(shù)據(jù)庫(kù)中，甚至可以放到不同的數(shù)據(jù)庫(kù)實(shí)例中

數(shù)據(jù)拆分的方式

數(shù)據(jù)拆分有兩種方式：

• 垂直拆分： 根據(jù)業(yè)務(wù)的維度，將原本一個(gè)庫(kù)中的表拆分多個(gè)表，每個(gè)庫(kù)中表與原有的結(jié)構(gòu)不同
• 水平拆分： 根據(jù)分片算法，將一個(gè)庫(kù)拆分成多個(gè)庫(kù)，每個(gè)庫(kù)依舊保留原有的結(jié)構(gòu)

在實(shí)際的開發(fā)過程中，通常是先進(jìn)行維度拆分形成微服務(wù)結(jié)構(gòu)，然后再進(jìn)行水平拆分

分庫(kù)分表

比如我們有一張表，隨著業(yè)務(wù)的不斷進(jìn)行，mysql中表中數(shù)據(jù)量達(dá)到了10億，若是將數(shù)據(jù)存放在一張表中，則性能一定不會(huì)太好，根據(jù)我們使用的經(jīng)驗(yàn)，mysql數(shù)據(jù)庫(kù)一張表的數(shù)據(jù)記錄極限一般在5000萬(wàn)左右，所以我們需要對(duì)進(jìn)行分片存儲(chǔ)（水平拆分），按照5000萬(wàn)一個(gè)單位來拆分的話，需要切片數(shù)量20個(gè)，也就是20個(gè)數(shù)據(jù)庫(kù)表

如果將20個(gè)相同業(yè)務(wù)表存放在同一個(gè)數(shù)據(jù)庫(kù)中，那么單個(gè)數(shù)據(jù)庫(kù)實(shí)例的網(wǎng)卡I/O、內(nèi)存、CPU和磁盤性能是有限的，隨著數(shù)據(jù)庫(kù)訪問頻率的增加，會(huì)導(dǎo)致單個(gè)數(shù)據(jù)庫(kù)實(shí)例和數(shù)據(jù)庫(kù)達(dá)到性能瓶頸，因此我們需要將20個(gè)表分到多個(gè)數(shù)據(jù)庫(kù)和多個(gè)數(shù)據(jù)庫(kù)實(shí)例中，具體的評(píng)估如下：
【TODO 對(duì)數(shù)據(jù)庫(kù)實(shí)例和數(shù)據(jù)庫(kù)表的數(shù)量的評(píng)估】

image

如何進(jìn)行分庫(kù)分表

分庫(kù)分表是對(duì)數(shù)據(jù)庫(kù)拆分的一種解決方案，根據(jù)實(shí)施切片邏輯的層次不同，我們將分庫(kù)分表方案大致分為三大類：客戶端分片、代理分片和支持事務(wù)的分布式數(shù)據(jù)庫(kù)

• 客戶端分片

所謂的客戶端分片即在使用數(shù)據(jù)庫(kù)的應(yīng)用層直接操作分片邏輯，分片規(guī)則需要在同一個(gè)應(yīng)用的多個(gè)節(jié)點(diǎn)間進(jìn)行同步，每個(gè)應(yīng)用層嵌入一個(gè)操作切片的邏輯實(shí)現(xiàn)。

image

在客戶端分片，目前主要有以下三種方式：

1. 在應(yīng)用層直接實(shí)現(xiàn)

這是一種非常通用的解決方案，直接在應(yīng)用層讀取分片規(guī)則，解析分片規(guī)則，根據(jù)分片規(guī)則實(shí)現(xiàn)切分的路由邏輯，從應(yīng)用層直接決定每次操作應(yīng)該使用哪個(gè)數(shù)據(jù)庫(kù)實(shí)例中的對(duì)應(yīng)的數(shù)據(jù)庫(kù)

這種解決方案雖然有一定的代碼侵入，但是實(shí)現(xiàn)起來比較簡(jiǎn)單，但是切片的邏輯是自己開發(fā)的， 如果生產(chǎn)上遇到了問題，能快速定位解決；

當(dāng)然這種方式也存在缺點(diǎn)：代碼的耦合度比較高，其次這種實(shí)現(xiàn)方式會(huì)讓數(shù)據(jù)庫(kù)保持的鏈接比較多，這要看應(yīng)用服務(wù)的節(jié)點(diǎn)數(shù)量，需要提前進(jìn)行容量上的評(píng)估

2. 通過定制JDBC協(xié)議實(shí)現(xiàn)

這種解決方案主要是為了解決1中解決方案中的代碼耦合，通過定制JDBC協(xié)議來實(shí)現(xiàn)（主要是針對(duì)業(yè)務(wù)邏輯層提供與JDBC一致的接口），讓分庫(kù)分表在JDBC的內(nèi)部實(shí)現(xiàn)

目前當(dāng)當(dāng)網(wǎng)開源的框架：Sharding JDBC 就是使用這種解決方案來實(shí)現(xiàn)的

3. 通過定制ORM框架實(shí)現(xiàn)

目前ORM框架非常流行，流行的JPA、Mybatis和Hibernate都是優(yōu)秀的ORM框架，通過定制ORM框架來實(shí)現(xiàn)分庫(kù)分表方案，常見的有基于Mybatis的分庫(kù)分表方案的解決；

    <select id="selectUser" parameterType="java.util.Map" resultType="User">
        select user_id as userId,user_name as userName
        from user_#{index}
        where user_id = #{userId}
    </select>

• 代理分片

代理分片就是在應(yīng)用層和數(shù)據(jù)庫(kù)層之間添加一個(gè)代理層，把分片的路由規(guī)則配置在代理層，代理層對(duì)外提供與JDBC兼容的接口給應(yīng)用層，在業(yè)務(wù)實(shí)現(xiàn)之后，在代理層配置路由規(guī)則即可；

image

這種方案的優(yōu)點(diǎn)：讓應(yīng)用層的開發(fā)人員專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)，把分庫(kù)分表的配置留給代理層處理
同樣的業(yè)務(wù)存在缺點(diǎn)：增加了代理層，這樣的話對(duì)每個(gè)數(shù)據(jù)庫(kù)操作都增加了一層網(wǎng)絡(luò)傳輸，這對(duì)性能是有影響的，同時(shí)需要維護(hù)增加的代理層，也有了硬件成本，線上生產(chǎn)環(huán)境出現(xiàn)了問題，不能迅速定位，需要有一定的技術(shù)專家來維護(hù)

我們常見的 Mycat就是基于此種解決方案來實(shí)現(xiàn)的

• 支持事務(wù)的分布式數(shù)據(jù)庫(kù)

支持分布式事務(wù)的框架，目前有OceanBase、TiDB框架，這些框架將可伸縮特定和分布式事務(wù)的實(shí)現(xiàn)包裝到了分布式數(shù)據(jù)庫(kù)內(nèi)部實(shí)現(xiàn)，對(duì)使用者透明，使用者不需要直接控制這些特性，但是對(duì)事務(wù)的支持不如關(guān)系型數(shù)據(jù)，適合大數(shù)據(jù)日志系統(tǒng)、統(tǒng)計(jì)系統(tǒng)、查詢系統(tǒng)、社交網(wǎng)站等

分庫(kù)分表的架構(gòu)設(shè)計(jì)

上面我們介紹過數(shù)據(jù)拆分的兩種方式：垂直拆分和水平拆分；

綜上所述，我們發(fā)現(xiàn)垂直拆分和水平拆分具有共同點(diǎn)：

1. 存在分布式事務(wù)問題
2. 存在跨節(jié)點(diǎn)join的問題
3. 存在跨節(jié)點(diǎn)合并排序、分頁(yè)的問題
4. 存在多數(shù)據(jù)源管理的問題

垂直拆分更偏向于業(yè)務(wù)拆分的過程，在技術(shù)上我們更傾向于水平切分的方案；

常見的分片策略：

• 按照哈希切片

對(duì)數(shù)據(jù)庫(kù)的某個(gè)字段進(jìn)行來求哈希，再除以分片總數(shù)后取模，取模后相同的數(shù)據(jù)為一個(gè)分片，這樣將數(shù)據(jù)分成多個(gè)分片的方法叫做哈希分片

我們大多數(shù)在數(shù)據(jù)沒有時(shí)效性的情況下使用哈希分片，就是數(shù)據(jù)不管是什么時(shí)候產(chǎn)生的，系統(tǒng)都需要處理或者查詢；

• 按照時(shí)間切片

按照時(shí)間的范圍將數(shù)據(jù)分布到不同的分片上，比如我們可以將交易數(shù)據(jù)按照與進(jìn)行切片，或者按照季度進(jìn)行切片，由交易數(shù)據(jù)的多少來決定按照什么樣的時(shí)間周期來進(jìn)行切片

這種切片方式適合明顯時(shí)間特點(diǎn)的數(shù)據(jù)，常見的就是訂單歷史查詢

分布式事務(wù)

本博文不進(jìn)行分布式事務(wù)的分析和實(shí)踐，后期我會(huì)更新一系列的分布式事務(wù)的博文，一起探討分布式事務(wù)的原理、解決方案和代碼實(shí)踐等，本博文簡(jiǎn)單介紹了分布式事務(wù)的解決方案；

上面說到的，不管是垂直拆分還是水平拆分，都有一個(gè)共同的問題：分布式事務(wù)

我們將單表的數(shù)據(jù)切片后存儲(chǔ)在多個(gè)數(shù)據(jù)庫(kù)甚至是多個(gè)數(shù)據(jù)庫(kù)實(shí)例中，所以依靠數(shù)據(jù)庫(kù)本身的事務(wù)機(jī)制不能滿足需要，這時(shí)就需要用到分布式事務(wù)來解決了

三種解決方案

• 兩階段提交協(xié)議

兩階段提交協(xié)議中的兩階段是：準(zhǔn)備階段和提交階段，兩個(gè)階段都是由事務(wù)管理器（協(xié)調(diào)者）發(fā)起，事務(wù)管理器能最大限度的保證跨數(shù)據(jù)庫(kù)操作的事務(wù)的原子性。

具體的交互邏輯如下：

image

• 最大努力保證模式

這是一種非常通用的保證分布式一致性的模式，適合對(duì)一致性要求不是十分嚴(yán)格的但是對(duì)性能要求比較高的場(chǎng)景

最大努力保證模式：在更新多個(gè)資源時(shí)，將多個(gè)資源的提交盡量延后到最后一刻進(jìn)行處理，這樣的話，如果業(yè)務(wù)流程出現(xiàn)問題，則所有的資源更新都可以回滾，事務(wù)仍然保持一致。

最大努力保證模式在發(fā)生系統(tǒng)問題，比如網(wǎng)絡(luò)問題等會(huì)出現(xiàn)問題，造成數(shù)據(jù)一致性的問題 ，這是就需要進(jìn)行實(shí)時(shí)補(bǔ)償，將已提交的事務(wù)進(jìn)行回滾

一般情況下，使用消息中間件來完成消費(fèi)者之間的事務(wù)協(xié)調(diào)，客戶端從消息中間件的隊(duì)列中消費(fèi)消息，更新數(shù)據(jù)庫(kù)，此時(shí)會(huì)涉及到兩個(gè)操作，一是從消息中間件消費(fèi)消息，二是更新數(shù)據(jù)庫(kù)，具體的操作步驟如下：

1. 開啟消息事務(wù)
2. 接收消息
3. 開啟數(shù)據(jù)庫(kù)事務(wù)
4. 更新數(shù)據(jù)庫(kù)
5. 提交數(shù)據(jù)庫(kù)事務(wù)
6. 提交消息事務(wù)

上述步驟最關(guān)鍵的地方在5和6，如果5成功了，但是6出現(xiàn)了問題，導(dǎo)致消息中間件認(rèn)為消息沒有被成功消費(fèi)，既有的機(jī)制會(huì)重新再消費(fèi)消息，就會(huì)出現(xiàn)消息重復(fù)消費(fèi)，這是需要冪等處理來避免消息的重新消費(fèi)

其次我們還需要注意消息消費(fèi)的順序性問題，以及消費(fèi)過程中是否調(diào)用遠(yuǎn)程接口等耗時(shí)操作

• 事務(wù)補(bǔ)償機(jī)制

以上提到的兩種解決方案：兩階段提交協(xié)議對(duì)系統(tǒng)的性能影響較大，最大努力保證模式會(huì)是多個(gè)分布式操作互相嵌套，有可能互相影響，那么我們采用事務(wù)補(bǔ)償機(jī)制：

事務(wù)補(bǔ)償即在事務(wù)鏈中的任何一個(gè)正向事務(wù)操作，都必須存在一個(gè)完全符合回滾規(guī)則的可逆事務(wù)。如果是一個(gè)完整的事務(wù)鏈，則必須事務(wù)鏈中的每一個(gè)業(yè)務(wù)服務(wù)或操作都有對(duì)應(yīng)的可逆服務(wù)。對(duì)于Service服務(wù)本身無(wú)狀態(tài)，也不容易實(shí)現(xiàn)前面討論過的通過DTC或XA機(jī)制實(shí)現(xiàn)的跨應(yīng)用和資源的事務(wù)管理，建立跨資源的事務(wù)上下文.

我們通過跨銀行轉(zhuǎn)賬來說明：

首先調(diào)用取款服務(wù)，完全調(diào)用成功并返回，數(shù)據(jù)已經(jīng)持久化。然后調(diào)用異地的存款服務(wù)，如果也調(diào)用成功，則本身無(wú)任何問題。如果調(diào)用失敗，則需要調(diào)用本地注冊(cè)的逆向服務(wù)（本地存款服務(wù)），如果本地存款服務(wù)調(diào)用失敗，則必須考慮重試，如果約定重試次數(shù)仍然不成功，則必須log到完整的不一致信息。也可以是將本地存款服務(wù)作為消息發(fā)送到消息中間件，由消息中間件接管后續(xù)操作。

最后添加的重試機(jī)制是最大程度的確保補(bǔ)償服務(wù)執(zhí)行，保持?jǐn)?shù)據(jù)的一致性，如果重試之后還是失敗，則將操作保存在消息中間件中，等待后續(xù)處理，這樣就更多了一重保障

image

分庫(kù)分表引起的問題

由于將完整的數(shù)據(jù)分成若干份，在以下的場(chǎng)景中會(huì)產(chǎn)生多種問題

• 擴(kuò)容與遷移

在分庫(kù)分表中，如果涉及的分片已經(jīng)達(dá)到了承載數(shù)據(jù)的最大值，就需要對(duì)集群進(jìn)行擴(kuò)容，通常包括以下的步驟

1. 按照新舊分片規(guī)則，對(duì)新舊數(shù)據(jù)庫(kù)進(jìn)行雙寫
2. 將雙寫前按照舊分片規(guī)則寫入的歷史數(shù)據(jù)，根據(jù)新分片規(guī)則遷移寫入新的數(shù)據(jù)庫(kù)
3. 將按照舊的分片規(guī)則查詢改為按照新的分片規(guī)則查詢
4. 將雙寫數(shù)據(jù)庫(kù)邏輯從代碼中下線，只按照新的分片規(guī)則寫入數(shù)據(jù)
5. 刪除按照舊分片規(guī)則寫入的歷史數(shù)據(jù)

2步驟中遷移數(shù)據(jù)時(shí)，數(shù)據(jù)量非常大，通常會(huì)導(dǎo)致不一致，因此需要先遷移舊的數(shù)據(jù)，洗完后再遷移到新規(guī)則的新數(shù)據(jù)庫(kù)下，再做全量對(duì)比，對(duì)比評(píng)估在遷移過程中是否有數(shù)據(jù)的更新，如果有的話就再清洗、遷移，最后以對(duì)比沒有差距為準(zhǔn)

• 分庫(kù)分表維度導(dǎo)致的查詢問題

進(jìn)行了分庫(kù)分表以后，如果查詢的標(biāo)準(zhǔn)是分片的主鍵，則可以通過分片規(guī)則再次路由并查詢，但是對(duì)于其他主鍵的查詢、范圍查詢、關(guān)聯(lián)查詢、查詢結(jié)果排序等，并不是按照分庫(kù)分表維度查詢的；

這樣的話，解決方案有以下三種：

1. 在多個(gè)分片表中查詢后合并數(shù)據(jù)集，這種方式的效率最低
2. 冗余記錄多份數(shù)據(jù)，方便查詢， 缺點(diǎn)是需要額外維護(hù)一份數(shù)據(jù)，浪費(fèi)資源
3. 通過搜索引擎解決，但如果實(shí)時(shí)性要求很高，就需要實(shí)現(xiàn)實(shí)時(shí)搜索，可以利用大數(shù)據(jù)相關(guān)特性來解決

• 跨庫(kù)事務(wù)難以實(shí)現(xiàn)

同時(shí)操作多個(gè)庫(kù)，則會(huì)出現(xiàn)數(shù)據(jù)不一致的情況，此時(shí)可以引用分布式事務(wù)來解決

• 同組數(shù)據(jù)跨庫(kù)問題

要盡量把同一組數(shù)據(jù)放到同一數(shù)據(jù)庫(kù)服務(wù)器上，不但在某些場(chǎng)景下可以利用本地事務(wù)的強(qiáng)一致性，還可以是這組數(shù)據(jù)自治

主流的解決方案

目前針對(duì)mysql的分庫(kù)分表，行業(yè)內(nèi)主流的解決方案有：ShardingJDBC、Mycat

Mycat代理分片框架

Mycat是一款面向企業(yè)級(jí)應(yīng)用的開源數(shù)據(jù)庫(kù)中間件產(chǎn)品，他目前支持?jǐn)?shù)據(jù)庫(kù)集群，分布式事務(wù)與ACID，被普遍視為基于Mysql技術(shù)的集群分布式數(shù)據(jù)庫(kù)解決方案

Mycat支持多種分片規(guī)則：

• 枚舉法
• 固定分片的hash算法
• 范圍約定
• 求模法
• 日期列分區(qū)法
• 通配取模
• ASCII碼求模通配
• 編程指定
• 截取數(shù)據(jù)哈希解析
• 一致性Hash

具體的Mycat使用方法，以后應(yīng)該會(huì)有一博文來整理，敬請(qǐng)期待啊~~~