分庫分表的 21 條法則，hold 住！

大家好，我是小富～

（一）好好的系統，爲什麼要分庫分表？

本文是《分庫分表 ShardingSphere5.x 原理與實戰》系列的第二篇文章，距離上一篇文章已經過去好久了，慚愧慚愧～

還是不着急實戰，咱們先介紹下在分庫分表架構實施過程中，會接觸到的一些通用概念，瞭解這些概念能夠幫助理解市面上其他的分庫分表工具，儘管它們的實現方法可能存在差異，但整體思路基本一致。因此，在開始實際操作之前，我們有必要先掌握這些通用概念，以便更好地理解和應用分庫分表技術。

我們結合具體業務場景，以t_order表爲例進行架構優化。由於數據量已經達到億級別，查詢性能嚴重下降，因此我們採用了分庫分表技術來處理這個問題。具體而言，我們將原本的單庫分成了兩個庫，分別爲DB_1和DB_2，並在每個庫中再次進行分表處理，生成t_order_1和t_order_2兩張表，實現對訂單表的分庫分表處理。

數據分片

通常我們在提到分庫分表的時候，大多是以水平切分模式（水平分庫、分表）爲基礎來說的，數據分片它將原本一張數據量較大的表 t_order 拆分生成數個表結構完全一致的小數據量表（拆分表） t_order_0、t_order_1、···、t_order_n，每張表只存儲原大表中的一部分數據。

數據節點

數據節點是數據分片中一個不可再分的最小單元（表），它由數據源名稱和數據表組成，例如上圖中 DB_1.t_order_1、DB_2.t_order_2 就表示一個數據節點。

邏輯表

邏輯表是指具有相同結構的水平拆分表的邏輯名稱。

比如我們將訂單表t_order 分表拆分成 t_order_0 ··· t_order_9等 10 張表，這時我們的數據庫中已經不存在 t_order這張表，取而代之的是若干的t_order_n表。

分庫分表通常對業務代碼都是無侵入式的，開發者只專注於業務邏輯 SQL 編碼，我們在代碼中SQL依然按 t_order來寫，而在執行邏輯 SQL 前將其解析成對應的數據庫真實執行的 SQL。此時 t_order 就是這些拆分表的邏輯表。

業務邏輯 SQL

select * from t_order where order_no='A11111'

真實執行 SQL

select * from DB_1.t_order_n where order_no='A11111'

真實表

真實表就是在數據庫中真實存在的物理表DB_1.t_order_n。

廣播表

廣播表是一類特殊的表，其表結構和數據在所有分片數據源中均完全一致。與拆分表相比，廣播表的數據量較小、更新頻率較低，通常用於字典表或配置表等場景。由於其在所有節點上都有副本，因此可以大大降低JOIN關聯查詢的網絡開銷，提高查詢效率。

需要注意的是，對於廣播表的修改操作需要保證同步性，以確保所有節點上的數據保持一致。

廣播表的特點：

• 在所有分片數據源中，廣播表的數據完全一致。因此，對廣播表的操作（如插入、更新和刪除）會實時在每個分片數據源中執行一遍，以保證數據的一致性。

• 對於廣播表的查詢操作，僅需要在任意一個分片數據源中執行一次即可。

• 與任何其他表進行 JOIN 操作都是可行的，因爲由於廣播表的數據在所有節點上均一致，所以可以訪問到任何一個節點上的相同數據。

什麼樣的表可以作爲廣播表呢？

訂單管理系統中，往往需要查詢統計某個城市地區的訂單數據，這就會涉及到省份地區表t_city與訂單流水錶DB_n.t_order_n進行 JOIN 查詢，因此可以考慮將省份地區表設計爲廣播表，核心理念就是避免跨庫 JOIN 操作。

注意：上邊我們提到廣播表在數據插入、更新與刪除會實時在每個分片數據源均執行，也就是說如果你有 1000 個分片數據源，那麼修改一次廣播表就要執行 1000 次 SQL，所以儘量不在併發環境下和業務高峯時進行，以免影響系統的性能。

單表

單表指所有的分片數據源中僅唯一存在的表（沒有分片的表），適用於數據量不大且無需分片的表。

如果一張表的數據量預估在千萬級別，且沒有與其他拆分表進行關聯查詢的需求，建議將其設置爲單表類型，存儲在默認分片數據源中。

分片鍵

分片鍵決定了數據落地的位置，也就是數據將會被分配到哪個數據節點上存儲。因此，分片鍵的選擇非常重要。

比如我們將 t_order 表進行分片後，當插入一條訂單數據執行 SQL 時，需要通過解析 SQL 語句中指定的分片鍵來計算數據應該落在哪個分片中。以表中order_no字段爲例，我們可以通過對其取模運算（比如 order_no % 2）來得到分片編號，然後根據分片編號分配數據到對應的數據庫實例（比如 DB_1 和 DB_2）。拆分表也是同理計算。

在這個過程中，order_no 就是 t_order 表的分片鍵。也就是說，每一條訂單數據的 order_no 值決定了它應該存放的數據庫實例和表。選擇一個適合作爲分片鍵的字段可以更好地利用水平分片帶來的性能提升。

這樣同一個訂單的相關數據就會落在同一個數據庫、表中，查詢訂單時同理計算，就可直接定位數據位置，大幅提升數據檢索的性能，避免了全庫表掃描。

不僅如此 ShardingSphere 還支持根據多個字段作爲分片健進行分片，這個在後續對應章節中會詳細講。

分片策略

分片策略來指定使用哪種分片算法、選擇哪個字段作爲分片鍵以及如何將數據分配到不同的節點上。

分片策略是由分片算法和分片健組合而成，分片策略中可以使用多種分片算法和對多個分片鍵進行運算。

分庫、分表的分片策略配置是相對獨立的，可以各自使用不同的策略與算法，每種策略中可以是多個分片算法的組合，每個分片算法可以對多個分片健做邏輯判斷。

分片算法

分片算法則是用於對分片鍵進行運算，將數據劃分到具體的數據節點中。

常用的分片算法有很多：

• 哈希分片：根據分片鍵的哈希值來決定數據應該落到哪個節點上。例如，根據用戶 ID 進行哈希分片，將屬於同一個用戶的數據分配到同一個節點上，便於後續的查詢操作。

• 範圍分片：分片鍵值按區間範圍分配到不同的節點上。例如，根據訂單創建時間或者地理位置來進行分片。

• 取模分片：將分片鍵值對分片數取模，將結果作爲數據應該分配到的節點編號。例如， order_no % 2 將訂單數據分到兩個節點之一。

• .....

實際業務開發中分片的邏輯要複雜的多，不同的算法適用於不同的場景和需求，需要根據實際情況進行選擇和調整。

綁定表

綁定表是那些具有相同分片規則的一組分片表，由於分片規則一致所產生的的數據落地位置相同，在JOIN聯合查詢時能有效避免跨庫操作。

比如：t_order 訂單表和 t_order_item 訂單項目表，都以 order_no 字段作爲分片鍵，並且使用 order_no 進行關聯，因此兩張表互爲綁定表關係。

使用綁定表進行多表關聯查詢時，必須使用分片鍵進行關聯，否則會出現笛卡爾積關聯或跨庫關聯，從而影響查詢效率。

當使用 t_order 和 t_order_item 表進行多表聯合查詢，執行如下聯合查詢的邏輯 SQL。

SELECT * FROM t_order o JOIN t_order_item i ON o.order_no=i.order_no

如果不配置綁定表關係，兩個表的數據位置不確定就會全庫表查詢，出現笛卡爾積關聯查詢，將產生如下四條SQL。

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_no=i.order_no 
SELECT * FROM t_order_0 o JOIN t_order_item_1 i ON o.order_no=i.order_no 
SELECT * FROM t_order_1 o JOIN t_order_item_0 i ON o.order_no=i.order_no 
SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_no=i.order_no

而配置綁定表關係後再進行關聯查詢時，分片規則一致產生的數據就會落到同一個庫表中，那麼只需在當前庫中 t_order_n 和 t_order_item_n 表關聯即可。

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id 
SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id

注意：在關聯查詢時 t_order 它作爲整個聯合查詢的主表。所有相關的路由計算都只使用主表的策略，t_order_item 表的分片相關的計算也會使用 t_order 的條件，所以要保證綁定表之間的分片鍵要完全相同。

SQL 解析

分庫分表後在應用層面執行一條 SQL 語句時，通常需要經過以下六個步驟：SQL 解析 -> 執⾏器優化 -> SQL 路由 -> SQL 改寫 -> SQL 執⾏ -> 結果歸併 。

在這裏插入圖片描述

SQL 解析過程分爲詞法解析和語法解析兩步，比如下邊查詢用戶訂單的 SQL，先用詞法解析將這條 SQL 拆解成不可再分的原子單元。在根據不同數據庫方言所提供的字典，將這些單元歸類爲關鍵字，表達式，變量或者操作符等類型。

SELECT order_no FROM t_order where  order_status > 0  and user_id = 10086

接着語法解析會將拆分後的 SQL 關鍵字轉換爲抽象語法樹，通過對抽象語法樹遍歷，提煉出分片所需的上下文，上下文包含查詢字段信息（Field）、表信息（Table）、查詢條件（Condition）、排序信息（Order By）、分組信息（Group By）以及分頁信息（Limit）等，並標記出 SQL 中有可能需要改寫的位置。

抽象語法樹

執⾏器優化

執⾏器優化是根據 SQL 查詢特點和執行統計信息，選擇最優的查詢計劃並執行，比如user_id字段有索引，那麼會調整兩個查詢條件的位置，主要是提高 SQL 的執行效率。

SELECT order_no FROM t_order where user_id = 10086 and order_status > 0

SQL 路由

通過上邊的 SQL 解析得到了分片上下文數據，在匹配用戶配置的分片策略和算法，就可以運算生成路由路徑，將 SQL 語句路由到相應的數據節點上。

簡單點理解就是拿到分片策略中配置的分片鍵等信息，在從 SQL 解析結果中找到對應分片鍵字段的值，計算出 SQL 該在哪個庫的哪個表中執行，SQL 路由又根據有無分片健分爲 分片路由 和 廣播路由。

有分⽚鍵的路由叫分片路由，細分爲直接路由、標準路由和笛卡爾積路由這 3 種類型。

標準路由

標準路由是最推薦也是最爲常⽤的分⽚⽅式，它的適⽤範圍是不包含關聯查詢或僅包含綁定表之間關聯查詢的 SQL。

當 SQL 分片健的運算符爲 = 時，路由結果將落⼊單庫（表），當分⽚運算符是 BETWEEN 或 IN 等範圍時，路由結果則不⼀定落⼊唯⼀的庫（表），因此⼀條邏輯 SQL 最終可能被拆分爲多條⽤於執⾏的真實 SQL。

SELECT * FROM t_order  where t_order_id in (1,2)

SQL 路由處理後

SELECT * FROM t_order_0  where t_order_id in (1,2)
SELECT * FROM t_order_1  where t_order_id in (1,2)

直接路由

直接路由是直接將 SQL 路由到指定⾄庫、表的一種分⽚方式，而且直接路由可以⽤於分⽚鍵不在 SQL 中的場景，還可以執⾏包括⼦查詢、⾃定義函數等複雜情況的任意 SQL。

笛卡爾積路由

笛卡爾路由是由⾮綁定表之間的關聯查詢產生的，比如訂單表t_order 分片鍵是t_order_id 和用戶表t_user分片鍵是t_order_id ，兩個表的分片鍵不同，要做聯表查詢，會執行笛卡爾積路由，查詢性能較低儘量避免走此路由模式。

SELECT * FROM t_order_0 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_0 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1

無分⽚鍵的路由又叫做廣播路由，可以劃分爲全庫表路由、全庫路由、 全實例路由、單播路由和阻斷路由這 5 種類型。

全庫表路由

全庫表路由針對的是數據庫 DQL 和 DML，以及 DDL等操作，當我們執行一條邏輯表 t_order SQL 時，在所有分片庫中對應的真實表 t_order_0 ···  t_order_n 內逐一執行。

全庫路由

全庫路由主要是對數據庫層面的操作，比如數據庫 SET 類型的數據庫管理命令，以及 TCL 這樣的事務控制語句。

對邏輯庫設置 autocommit 屬性後，所有對應的真實庫中都執行該命令。

SET autocommit=0;

全實例路由

全實例路由是針對數據庫實例的 DCL 操作（設置或更改數據庫用戶或角色權限），比如：創建一個用戶 order ，這個命令將在所有的真實庫實例中執行，以此確保 order 用戶可以正常訪問每一個數據庫實例。

CREATE USER order@127.0.0.1 identified BY '程序員小富';

單播路由

單播路由用來獲取某一真實表信息，比如獲得表的描述信息：

DESCRIBE t_order;

t_order 的真實表是 t_order_0 ···· t_order_n，他們的描述結構相完全同，我們只需在任意的真實表執行一次就可以。

阻斷路由

⽤來屏蔽 SQL 對數據庫的操作，例如：

USE order_db;

這個命令不會在真實數據庫中執⾏，因爲 ShardingSphere 採⽤的是邏輯 Schema（數據庫的組織和結構） ⽅式，所以無需將切換數據庫的命令發送⾄真實數據庫中。

SQL 改寫

SQL 經過解析、優化、路由後已經明確分片具體的落地執行的位置，接着就要將基於邏輯表開發的 SQL 改寫成可以在真實數據庫中可以正確執行的語句。比如查詢 t_order 訂單表，我們實際開發中 SQL 是按邏輯表 t_order 寫的。

SELECT * FROM t_order

這時需要將分表配置中的邏輯表名稱改寫爲路由之後所獲取的真實表名稱。

SELECT * FROM t_order_n

SQL 執⾏

將路由和改寫後的真實 SQL 安全且高效發送到底層數據源執行。但這個過程並不能將 SQL 一股腦的通過 JDBC 直接發送至數據源執行，需平衡數據源連接創建以及內存佔用所產生的消耗，它會自動化的平衡資源控制與執行效率。

結果歸併

將從各個數據節點獲取的多數據結果集，合併成一個大的結果集並正確的返回至請求客戶端，稱爲結果歸併。而我們 SQL 中的排序、分組、分頁和聚合等語法，均是在歸併後的結果集上進行操作的。

分佈式主鍵

數據分⽚後，一個邏輯表（t_order）對應諸多的真實表（t_order_n），它們之間由於⽆法互相感知，主鍵 ID 都從初始值累加，所以必然會產⽣重複主鍵 ID，此時主鍵不再唯一那麼對於業務來說也就沒意義了。

儘管可通過設置表⾃增主鍵 初始值 和 步⻓ 的⽅式避免 ID 碰撞，但這樣會使維護成本加大，可擴展性差。

這個時候就需要我們手動爲一條數據記錄，分配一個全局唯一的 ID，這個 ID 被叫做分佈式 ID，而生產這個 ID 的系統通常被叫做發號器。

大家可以參考我之前發佈的這篇文章 9 種分佈式 ID 生成方案

數據脫敏

分庫分表數據脫敏是一種有效的數據保護措施，可以確保敏感數據的機密性和安全性，減少數據泄露的風險。

比如，我們在分庫分表時可以指定表的哪些字段爲脫敏列，並設置對應的脫敏算法，在數據分片時解析到執行 SQL 中有待脫敏字段，會直接將字段值脫敏後的寫入庫表內。

對於用戶的個人信息，如姓名、地址和電話號碼等，可以通過加密、隨機化或替換成僞隨機數據的方式進行脫敏，以確保用戶的隱私得到保護。

大家可以參考我之前發佈的這篇文章 大廠也在用的 6 種 數據脫敏方案

分佈式事務

分佈式事務的核心問題是如何實現跨多個數據源的原子性操作。

由於不同的服務通常會使用不同的數據源來存儲和管理數據，因此，跨數據源的操作可能會導致數據不一致性或丟失的風險。因此，保證分佈式事務的一致性是非常重要的。

以訂單系統爲例，它需要調用支付系統、庫存系統、積分系統等多個系統，而每個系統都維護自己的數據庫實例，系統間通過 API 接口交換數據。

爲了保證下單後多個系統同時調用成功，可以使用強一致性事務的 XA 協議，或者柔性事務的代表工具 Seata，來實現分佈式事務的一致性。這些工具可以幫助開發人員簡化分佈式事務的實現，減少錯誤和漏洞的出現，提高系統的穩定性和可靠性。

經過分庫分表之後，問題的難度進一步提升。自身訂單服務，也需要處理跨數據源的操作。這樣一來，系統的複雜度顯著增加。因此，不到萬不得已的情況下，最好避免採用分庫分表的解決方案。

關於分佈式事務詳細的介紹，大家可以參考我之前發佈的這篇文章 對比 5 種分佈式事務方案，還是寵幸了阿里的 Seata（原理 + 實戰）

數據遷移

分庫分表後還有個讓人頭疼的問題，那就是數據遷移，爲了不影響現有的業務系統，通常會新建數據庫集羣遷移數據。將數據從舊集羣的數據庫、表遷移到新集羣的分庫、分表中。這是一個比較複雜的過程，在遷移過程中需要考慮數據量、數據一致性、遷移速度等諸多因素。

遷移主要針對 存量數據 和 增量數據 的處理，存量數據指舊數據源中已經存在且有價值的歷史數據，增量數據指當下持續增長以及未來產生的業務數據。

存量數據可以採用定時、分批次的遷移，遷移過程可能會持續幾天。

增量數據可以採用新、舊數據庫集羣雙寫模式。待數據遷移完畢，業務驗證了數據一致性，應用直接切換數據源即可。

後續我們會結合三方工具，來演示遷移的過程。

影子庫

什麼是影子庫（Shadow Table）？

影子庫是一個與生產環境數據庫結構完全相同的實例，它存在的意義是爲了在不影響線上系統的情況下，驗證數據庫遷移或者其他數據庫變更操作的正確性，以及全鏈路壓測。影子庫中存儲的數據是從生產環境中定期複製過來的，但是它不對線上業務產生任何影響，僅用於測試，驗證和調試。

在進行數據庫升級、版本變更、參數調優等操作前，通過在影子庫上模擬這些操作，可以發現潛在的問題，因爲測試環境的數據是不可靠的。

在使用影子庫時，需要遵循以下幾個原則：

• 與生產環境數據庫的結構應該完全一致，包括表結構、索引、約束等；

• 數據要與生產環境保持一致，可以通過定期同步方式實現；

• 讀寫操作不會影響生產環境，一般情況下應該禁止在影子庫上執行更新、刪除等操作；

• 由於影子庫的數據特點，訪問權限應該嚴格控制，只允許授權人員進行訪問和操作；

總結

本文介紹了關於分庫分表架構的 21 個通用概念，有一定的瞭解之後，接下來我們將進入更深度的內容，包括讀寫分離、數據脫敏、分佈式主鍵、分佈式事務、配置中心、註冊中心、Proxy服務等實戰案例的講解和源碼分析。

下期文章將是《分庫分表 ShardingSphere5.x 原理與實戰》系列的第三篇，《快速實現分庫分表的 2 種方式》。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/aRQLKGzFHcX7zQLqa6FIbA