盤點分庫分表中，你一定要避開的那些坑！

• 2019 年 10 月 4 日
• 筆記

例如：單表中出現了，動輒百萬甚至千萬級別的數據。「分表分庫」就成為解決上述問題的有效工具。

今天和大家一起探討：如何進行分表分庫以及期間遇到的問題。

為什麼會分表分庫

資料庫數據會隨著業務的發展而不斷增多，因此數據操作，如增刪改查的開銷也會越來越大。

再加上物理伺服器的資源有限（CPU、磁碟、記憶體、IO 等）。最終資料庫所能承載的數據量、數據處理能力都將遭遇瓶頸。

換句話說需要合理的資料庫架構來存放不斷增長的數據，這個就是分庫分表的設計初衷。目的就是為了緩解資料庫的壓力，最大限度提高數據操作的效率。

數據分表

如果單表的數據量過大，例如千萬級甚至更多，那麼在操作表的時候就會加大系統的開銷。

每次查詢會消耗資料庫大量資源，如果需要多表的聯合查詢，這種劣勢就更加明顯了。

以 MySQL 為例，在插入數據的時候，會對錶進行加鎖，分為表鎖定和行鎖定。

無論是哪種鎖定方式，都意味著前面一條數據在操作表或者行的時候，後面的請求都在排隊，當訪問量增加的時候，都會影響資料庫的效率。

那麼既然一定要分表，那麼每張表分配多大的數據量比較合適呢？這裡建議根據業務場景和實際情況具體分析。

一般來說 MySQL 資料庫單表記錄最好控制在 500 萬條（這是個經驗數字）。既然需要將數據從一個表分別存放到多個表中，那麼來看看下面兩種分表方式吧。

垂直分表

根據業務把一個表中的欄位（Field）分到不同的表中。這些被分出去的數據通常根據業務需要，例如分出去一些不是經常使用的欄位，一些長度較長的欄位。

一般被拆分的表的欄位數比較多。主要是避免查詢的時候出現因為數據量大而造成的「跨頁」問題。

一般這種拆分在資料庫設計之初就會考慮，盡量在系統上線之前考慮調整。已經上線的項目，做這種操作是要慎重考慮的。

水平分表

將一個表中的數據，按照關鍵字（例如：ID）（或取 Hash 之後）對一個具體的數字取模，得到的餘數就是需要存放到的新表的位置。

用 ID 取模的分表方式分配記錄

ID 分別為 01-04 的四條記錄，如果分配到 3 個表中，那麼對 3 取模得到的餘數分別是：

• ID：01 對 3 取模餘數為 1 ，存到「表 1」。
• ID：02 對 3 取模餘數為 2 ，存到「表 2」。
• ID：03 對 3 取模餘數為 3 ，存到「表 3」。
• ID：04 對 3 取模餘數為 1 ，存到「表 1」。

當然這裡只是一個例子，實際情況需要對 ID 做 Hash 之後再計算。同時還可以針對不同表所在的不同的資料庫的資源來設置存儲數據的多少。針對每個表所在的庫的資源設置權值。

用這種方式存放數據以後，在訪問具體數據的時候需要通過一個 Mapping Table 獲取對應要響應的數據來自哪個數據表。目前比較流行的資料庫中間件已經幫助我們實現了這部分的功能。

也就是說不用大家自己去建立這個 Mapping Table，在做查詢的時候中間件幫助你實現了 Mapping Table 的功能。所以，我們這裡只需要了解其實現原理就可以了。

Mapping Table 協助分表

水平拆分還有一種情況是根據數據產生的前後順序來拆分存放。例如，主表只存放最近 2 個月的資訊，其他比較老舊的資訊拆分到其他的表中。通過時間來做數據區分。更有甚者是通過服務的地域來做數據區分的。

按照時間做的數據分表

需要注意的是由於分表造成一系列記錄級別的問題，例如 Join 和 ID 生成，事務處理，同時存在這些表需要跨資料庫的可能性：

• Join：需要做兩次查詢，把兩次查詢的結果在應用層做合併。這種做法是最簡單的，在應用層設計的時候需要考慮。
• ID：可以使用 UUID，或者用一張表來存放生成的 Sequence，不過效率都不算高。UUID 實現起來比較方便，但是佔用的空間比較大。 Sequence 表的方式節省了空間，但是所有的 ID 都依賴於單表。這裡介紹一個大廠用的 Snowflake 的方式。

Snowflake 是 Twitter 開源的分散式 ID 生成演算法，結果是一個 long 型的 ID。

其核心思想是：使用 41bit 作為毫秒數，10bit 作為機器的 ID（5 個 bit 是數據中心，5 個 bit 的機器 ID），12bit 作為毫秒內的流水號（意味著每個節點在每毫秒可以產生 4096 個 ID），最後還有一個符號位，永遠是 0。

Snowflake 示意圖

排序/分頁：數據分配到水平的幾個表中的時候，做排序和分頁或者一些集合操作是不容易的。

這裡根據經驗介紹兩種方法。對分表的數據先進行排序/分頁/聚合，再進行合併。對分表的數據先進行合併再做排序/分頁/聚合。

事務：存在分散式事務的可能，需要考慮補償事務或者用 TCC（Try Confirm Cancel）協助完成，這部分的內容我們下面會為大家介紹。

數據分庫

說完了分表，再來談談分庫。

每個物理資料庫支援數據都是有限的，每一次的資料庫請求都會產生一次資料庫鏈接，當一個庫無法支援更多訪問的時候，我們會把原來的單個資料庫分成多個，幫助分擔壓力。

這裡有幾類分庫的原則，可以根據具體場景進行選擇：

• 根據業務不同分庫，這種情況都會把主營業務和其他功能分開。例如可以分為訂單資料庫，核算資料庫，評論資料庫。
• 根據冷熱數據進行分庫，用數據訪問頻率來劃分，例如：近一個月的交易數據屬於高頻數據，2-6 個月的交易數據屬於中頻數據，大於 6 個月的數據屬於低頻數據。
• 根據訪問數據的地域/時間範圍進行分庫。

單個表會分到不同的資料庫中

通常數據分庫之後，每一個資料庫包含多個數據表，多個資料庫會組成一個 Cluster/Group，提高了資料庫的可用性，並且可以把讀寫做分離。

Master 庫主要負責寫操作，Slave 庫主要負責讀操作。在應用訪問資料庫的時候會通過一個負載均衡代理，通過判斷讀寫操作把請求路由到對應的資料庫。

如果是讀操作，也會根據資料庫設置的權重或者平均分配請求。另外，還有資料庫健康監控機制，定時發送心跳檢測資料庫的健康狀況。

如果 Slave 出現問題，會啟動熔斷機制停止對其的訪問；如果 Master 出現問題，通過選舉機制選擇新的 Master 代替。

主從資料庫簡圖

資料庫擴容

分庫之後的資料庫會遇到數據擴容或者數據遷移的情況。這裡推薦兩種資料庫擴容的方案。

主從資料庫擴容

我們這裡假設有兩個資料庫集群，每個集群分別有 M1 S1 和 M2 S2 互為主備。

兩個資料庫集群示意圖

由於 M1 和 S1 互為主備所以數據是一樣的，M2 和 S2 同樣。把原有的 ID %2 模式切換成 ID %4 模式，也就是把兩個數據集群擴充到 4 個資料庫集群。

負載均衡器直接把數據路由到原來兩個 S1 和 S2 上面，同時 S1 和 S2 會停止與 M1 和 M2 的數據同步，單獨作為主庫（寫操作）存在。

這些修改不需要重啟資料庫服務，只需要修改代理配置就可以完成。由於 M1 M2 S1 S2 中會存在一些冗餘的數據，可以後台起服務將這些冗餘數據刪除，不會影響數據使用。

兩個集群中的兩個主從，分別擴展成四個集群中的四個主機

此時，再考慮資料庫可用性，將擴展後的 4 個主庫進行主備操作，針對每個主庫都建立對應的從庫，前者負責寫操作，後者負責讀操作。

下次如果需要擴容也可以按照類似的操作進行。

從兩個集群擴展成四個集群

雙寫資料庫擴容

在沒有資料庫主從配置的情況下的擴容，假設有資料庫 M1 M2 如下圖：

擴展前的兩個主庫

需要對目前的兩個資料庫做擴容，擴容之後是 4 個庫如下圖。新增的庫是 M3，M4 路由的方式分別是 ID%2=0 和 ID%2=1。

新增兩個主庫

這個時候新的數據會同時進入 M1 M2 M3 M4 四個庫中，而老數據的使用依舊從 M1 M2 中獲取。

與此同時，後台服務對 M1 M3，M2 M4 做數據同步，建議先做全量同步再做數據校驗。

老庫給新庫做數據同步

當完成數據同步之後，四個庫的數據保持一致了，修改負載均衡代理的配置為 ID%4 的模式。此時擴容就完成了，從原來的 2 個資料庫擴展成 4 個資料庫。

當然會存在部分的數據冗餘，需要像上面一個方案一樣通過後台服務刪除這些冗餘數據，刪除的過程不會影響業務。

數據同步以後做 Hash 切分

分散式事務原理

架構設計的分表分庫帶來的結果是我們不得不考慮分散式事務，今天我們來看看分散式事務需要記住哪兩個原理。

CAP

互聯網應用大多會使用分表分庫的操作，這個時候業務程式碼很可能會同時訪問兩個不同的資料庫，做不同的操作。同時這兩個操作有可能放在同一個事務中處理。

這裡引出分散式系統的 CAP 理論，他包括以下三個屬性：

一致性（Consistency）：分散式系統中的所有數據，同一時刻有同樣的值。

業務程式碼往資料庫 01 這個節點寫入記錄 A，資料庫 01 把 A 記錄同步到資料庫 02，業務程式碼再從資料庫 02 中讀出的記錄也是 A。那麼兩個資料庫存放的數據就是一致的。

一致性簡圖

可用性（Availability）：分散式系統中一部分節點出現故障，分散式系統仍舊可以響應用戶的請求。

假設資料庫 01 和 02 同時存放記錄 A，由於資料庫 01 掛掉了，業務程式碼不能從中獲取數據。

那麼業務程式碼可以從資料庫 02 中獲取記錄 A。也就是在節點出現問題的時候，還保證數據的可用性。

可用性簡圖

分區容錯性（Partition tolerance）：假設兩個資料庫節點分別在兩個區，而兩個區的通訊發生了問題。就不能達成數據一致，這就是分區的情況，我就需要從 C 和 A 之間做出選擇。

是選擇可用性（A），獲取其中一個區的數據。還是選擇一致性（C），等待兩個區的數據同步了再去獲取數據。

這種情況的前提是兩個節點的通訊失敗了，寫入資料庫 01 記錄的時候，需要鎖住資料庫 02 記錄不讓其他的業務程式碼修改，直到資料庫 01 記錄完成修改。因此 C 和 A 在此刻是矛盾的。兩者不能兼得。

分區容錯簡圖

BASE

Base 原理廣泛應用在數據量大，高並發的互聯網場景。一起來看看都包含哪些：

基本可用（Basically Available）： 不會因為某個節點出現問題就影響用戶的請求。

即使在流量激增的情況下，也會考慮通過限流降級的辦法保證用戶的請求是可用的。

比如，電商系統在流量激增的時候，資源會向核心業務傾斜，其他的業務降級處理。

軟狀態（ Soft State）：一條數據如果存在多個副本，允許副本之間同步的延遲，在較短時間內能夠容忍不一致。這個正在同步並且還沒有完成同步的狀態稱為軟狀態。

最終一致性（ Eventual Consistency）：最終一致性是相對於強一致性來說的，強一致性是要保證所有的數據都是一致的，是實時同步。

而最終一致性會容忍一小段時間數據的不一致，但過了這段時間以後數據會保證一致。其包含以下幾種「一致性」：

①因果一致性（Causal Consistency）

如果有兩個進程 1 和 2 都對變數 X 進行操作，「進程 1」 寫入變數 X，「進程 2」需要讀取變數 X，然後用這個 X 來計算 X+2。

這裡「進程 1」和「進程 2」 的操作就存在因果關係。「進程 2」 的計算依賴於進程 1 寫入的 X，如果沒有 X 的值，「進程 2」無法計算。

兩個進程對同一變數進行操作

②讀己之所寫（Read Your Writes）

「進程 1」寫入變數 X 之後，該進程可以獲取自己寫入的這個值。

進程寫入的值的同時獲取值

③會話一致性（Session Consistency）

如果一個會話中實現來讀己之所寫。一旦數據更新，客戶端只要在同一個會話中就可以看到這個更新的值。

多進程在同一會話需要看到相同的值

④單調寫一致性（Monotonic Write Consistency）

「進程 1」如果有三個操作分別是 1，2，3。「進程 2」有兩個操作分別是 1，2。當進程請求系統時，系統會保證按照進程中操作的先後順序來執行。

多進程多操作通過隊列方式執行

分散式事務方案

說完了分散式的原理，再來提一下分散式的方案。由於所處場景不一樣，所以方案也各有不同，這裡介紹兩種比較流行的方案，兩段式和 TCC（Try，Confirm，Cancel）。

兩階段提交

顧名思義，事務會進行兩次提交。這裡需要介紹兩個概念，一個是事務協調者，也叫事物管理器。

它是用來協調事務的，所有事務什麼時候準備好了，什麼時候可以提交了，都由它來協調和管理。

另一個是參與者，也叫資源管理器。它主要是負責處理具體事務的，管理者需要處理的資源。例如：訂票業務，扣款業務。

第一階段（準備階段）：事務協調者（事務管理器）給每個參與者（資源管理器）發送 Prepare 消息，發這個消息的目的是問「大家是不是都準備好了，我們馬上就要執行事務了」。

參與者會根據自身業務和資源情況進行檢查，然後給出回饋。這個檢查過程根據業務內容不同而不同。

例如：訂票業務，就要檢查是否有剩餘票。扣款業務就要檢查，餘額是否足夠。一旦檢查通過了才能返回就緒（Ready）資訊。

否則，事務將終止，並且等待下次詢問。由於這些檢查需要做一些操作，這些操作可能再之後回滾時用到，所以需要寫 redo 和 undo 日誌，當事務失敗重試，或者事務失敗回滾的時候使用。

第二階段（提交階段）：如果協調者收到了參與者失敗或者超時的消息，會給參與者發送回滾（rollback）消息；否則，發送提交（commit）消息。

兩種情況處理如下：

情況 1，當所有參與者均回饋 yes，提交事務：

• 協調者向所有參與者發出正式提交事務的請求（即 commit 請求）。
• 參與者執行 commit 請求，並釋放整個事務期間佔用的資源。
• 各參與者向協調者回饋 ack（應答）完成的消息。
• 協調者收到所有參與者回饋的 ack 消息後，即完成事務提交。

情況 2，當有一個參與者回饋 no，回滾事務：

• 協調者向所有參與者發出回滾請求（即 rollback 請求）。
• 參與者使用第一階段中的 undo 資訊執行回滾操作，並釋放整個事務期間佔用的資源。
• 各參與者向協調者回饋 ack 完成的消息。
• 協調者收到所有參與者回饋的 ack 消息後，即完成事務。

兩個階段提交事務示意圖

TCC（Try，Confirm，Cancel）

對於一些要求高一致性的分散式事務，例如：支付系統，交易系統，我們會採用 TCC。

它包括，Try 嘗試，Confirm 確認，Cancel 取消。看下面一個例子能否幫助大家理解。

假設我們有一個轉賬服務，需要把「A 銀行」「A 賬戶」中的錢分別轉到「B銀行」「B 賬戶」和「C 銀行」「C 賬戶」中去。

假設這三個銀行都有各自的轉賬服務，那麼這次轉賬事務就形成了一次分散式事務。

我們來看看用 TCC 的方式如何解決：

轉賬業務示意圖

首先是 Try 階段，主要檢測資源是否可用，例如檢查賬戶餘額是否足夠，快取，資料庫，隊列是否可用等等。

並不執行具體的邏輯。如上圖，這裡從「A 賬戶」轉出之前要檢查，賬戶的總金額是否大於 100，並且記錄轉出金額和剩餘金額。

對於「B 賬戶」和「C 賬戶」來說需要知道賬戶原有總金額和轉入的金額，從而可以計算轉入後的金額。

這裡的交易資料庫設計除了有金額欄位，還要有轉出金額或者轉入金額的欄位，在 Cancel 回滾的時候使用。

Try 階段示意圖

如果 Try 階段成功，那麼就進入 Confirm 階段，也就是執行具體的業務邏輯。

這裡從「A 賬戶」轉出 100 元成功，剩餘總金額=220-100=120，把這個剩餘金額寫入到總金額中保存，並且把交易的狀態設置為「轉賬成功」。

「B 賬戶」和「C 賬戶」分別設置總金額為 80=50+30 和 130=60+70，也把交易狀態設置為「轉賬成功」。則整個事務完成。

Confirm 階段示意圖

如果 Try 階段沒有成功，那麼服務 A B C 都要做回滾的操作。對於「A賬戶」來說需要把扣除的 100 元加回，所以總金額 220=120+100。

那麼「B 服務」和「C 服務」需要把入賬的金額從總金額裡面減去，也就是 50=80-30 和 60=130-70。

Cancel 階段示意圖

TCC 介面實現

這裡需要注意的是，需要針對每個服務去實現 Try，Confirm，Cancel 三個階段的程式碼。

例如上面所說的檢查資源，執行業務，回滾業務等操作。目前有很多開源的架構例如：ByteTCC、TCC-transaction 可以借鑒。

TCC 實現介面示意圖

TCC 可靠性

TCC 通過記錄事務處理日誌來保證可靠性。一旦 Try，Confirm，Cancel 操作的時候服務掛掉或者出現異常，TCC 會提供重試機制。

另外如果服務存在非同步的情況可以採用消息隊列的方式通訊保持事務一致。

重試機制示意圖

分庫表中間件介紹

如果覺得分表分庫之後，需要考慮的問題很多，可以使用市面上的現成的中間件幫我們實現。

這裡介紹幾個比較常用的中間件：

• 基於代理方式的有 MySQL Proxy 和 Amoeba。
• 基於 Hibernate 框架的有 Hibernate Shards。
• 基於 JDBC 的有噹噹 Sharding-JDBC。
• 基於 MyBatis 的類似 Maven 插件式的蘑菇街 TSharding。

另外著重介紹 Sharding-JDBC 的架構，它的構成和「服務註冊中心」很像。

Sharding-JDBC 會提供一個 Sharding-Proxy 做代理，他會連接一個註冊中心（registry center），一旦資料庫的節點掛接到系統中，會在這個中心註冊，同時也會監控資料庫的健康狀況做心跳檢測。

而 Sharding-Proxy 本身在業務程式碼（Business Code）請求資料庫的時候可以協助做負載均衡和路由。

同時 Sharding-Proxy 本身也可以支援被 MySQL Cli 和 MySQL Workbench 查看。

實際上如果我們理解了分表分庫的原理之後，實現並不難，很多大廠都提供了產品。

Sharding-Proxy 實現原理圖

總結

因為數據量的上升，為了提高性能會對系統進行分表分庫。從分表來說，有水平分表和垂直分表兩種方式。

可以根據業務，冷熱數據等來進行分庫，分庫以後通過主從庫來實現讀寫分離。

如果對分庫之後資料庫做擴容，有兩種方式，主從資料庫擴容和雙寫資料庫擴容。

分表分庫會帶來分散式事務，我們需要掌握 CAP 和 BASE 原理，同時介紹了兩階段提交和 TCC 兩個分散式事務方案。最後，介紹了流行的分表分庫中間件，以及其實現原理。

END

出處：51CTO技術棧 作者：崔皓