（一）好好的系統(tǒng)，為什么要分庫分表？
本文是《分庫分表ShardingSphere5.x原理與實戰(zhàn)》系列的第二篇文章，距離上一篇文章已經(jīng)過去好久了，慚愧慚愧～
還是不著急實戰(zhàn)，咱們先介紹下在分庫分表架構實施過程中，會接觸到的一些通用概念，了解這些概念能夠幫助理解市面上其他的分庫分表工具，盡管它們的實現(xiàn)方法可能存在差異，但整體思路基本一致。因此，在開始實際操作之前，我們有必要先掌握這些通用概念，以便更好地理解和應用分庫分表技術。
我們結合具體業(yè)務場景，以t_order表為例進行架構優(yōu)化。由于數(shù)據(jù)量已經(jīng)達到億級別，查詢性能嚴重下降，因此我們采用了分庫分表技術來處理這個問題。具體而言，我們將原本的單庫分成了兩個庫，分別為DB_1和DB_2，并在每個庫中再次進行分表處理，生成t_order_1和t_order_2兩張表，實現(xiàn)對訂單表的分庫分表處理。
數(shù)據(jù)分片 通常我們在提到分庫分表的時候，大多是以水平切分模式（水平分庫、分表）為基礎來說的，數(shù)據(jù)分片它將原本一張數(shù)據(jù)量較大的表 t_order 拆分生成數(shù)個表結構完全一致 的小數(shù)據(jù)量表（拆分表） t_order_0、t_order_1、···、t_order_n，每張表只存儲原大表中的一部分數(shù)據(jù)。
數(shù)據(jù)節(jié)點 數(shù)據(jù)節(jié)點是數(shù)據(jù)分片中一個不可再分的最小單元（表），它由數(shù)據(jù)源名稱和數(shù)據(jù)表組成，例如上圖中 DB_1.t_order_1、DB_2.t_order_2 就表示一個數(shù)據(jù)節(jié)點。
邏輯表 邏輯表是指具有相同結構的水平拆分表的邏輯名稱。
比如我們將訂單表t_order 分表拆分成 t_order_0 ··· t_order_9等10張表，這時我們的數(shù)據(jù)庫中已經(jīng)不存在 t_order這張表，取而代之的是若干的t_order_n表。
分庫分表通常對業(yè)務代碼都是無侵入式的，開發(fā)者只專注于業(yè)務邏輯SQL編碼，我們在代碼中SQL依然按 t_order來寫，而在執(zhí)行邏輯SQL前將其解析成對應的數(shù)據(jù)庫真實執(zhí)行的SQL。此時 t_order 就是這些拆分表的邏輯表。
業(yè)務邏輯SQL
select * from t_order where order_no='A11111' 真實執(zhí)行SQL
select * from DB_1.t_order_n where order_no='A11111' 真實表 真實表就是在數(shù)據(jù)庫中真實存在的物理表DB_1.t_order_n。
廣播表 廣播表是一類特殊的表，其表結構和數(shù)據(jù)在所有分片數(shù)據(jù)源中均完全一致。與拆分表相比，廣播表的數(shù)據(jù)量較小、更新頻率較低，通常用于字典表或配置表等場景。由于其在所有節(jié)點上都有副本，因此可以大大降低JOIN關聯(lián)查詢的網(wǎng)絡開銷，提高查詢效率。
需要注意的是，對于廣播表的修改操作需要保證同步性，以確保所有節(jié)點上的數(shù)據(jù)保持一致。
廣播表的特點 ：
在所有分片數(shù)據(jù)源中，廣播表的數(shù)據(jù)完全一致。因此，對廣播表的操作（如插入、更新和刪除）會實時在每個分片數(shù)據(jù)源中執(zhí)行一遍，以保證數(shù)據(jù)的一致性。
對于廣播表的查詢操作，僅需要在任意一個分片數(shù)據(jù)源中執(zhí)行一次即可。
與任何其他表進行JOIN操作都是可行的，因為由于廣播表的數(shù)據(jù)在所有節(jié)點上均一致，所以可以訪問到任何一個節(jié)點上的相同數(shù)據(jù)。
什么樣的表可以作為廣播表呢？
訂單管理系統(tǒng)中，往往需要查詢統(tǒng)計某個城市地區(qū)的訂單數(shù)據(jù)，這就會涉及到省份地區(qū)表t_city與訂單流水表DB_n.t_order_n進行JOIN查詢，因此可以考慮將省份地區(qū)表設計為廣播表，核心理念就是避免跨庫JOIN操作 。
注意 ：上邊我們提到廣播表在數(shù)據(jù)插入、更新與刪除會實時在每個分片數(shù)據(jù)源均執(zhí)行，也就是說如果你有1000個分片數(shù)據(jù)源，那么修改一次廣播表就要執(zhí)行1000次SQL，所以盡量不在并發(fā)環(huán)境下和業(yè)務高峰時進行，以免影響系統(tǒng)的性能。
單表 單表指所有的分片數(shù)據(jù)源中僅唯一存在的表（沒有分片的表），適用于數(shù)據(jù)量不大且無需分片的表。
如果一張表的數(shù)據(jù)量預估在千萬級別，且沒有與其他拆分表進行關聯(lián)查詢的需求，建議將其設置為單表類型，存儲在默認分片數(shù)據(jù)源中。
分片鍵 分片鍵決定了數(shù)據(jù)落地的位置，也就是數(shù)據(jù)將會被分配到哪個數(shù)據(jù)節(jié)點上存儲。因此，分片鍵的選擇非常重要。
比如我們將 t_order 表進行分片后，當插入一條訂單數(shù)據(jù)執(zhí)行SQL時，需要通過解析SQL語句中指定的分片鍵來計算數(shù)據(jù)應該落在哪個分片中。以表中order_no字段為例，我們可以通過對其取模運算（比如 order_no % 2）來得到分片編號，然后根據(jù)分片編號分配數(shù)據(jù)到對應的數(shù)據(jù)庫實例（比如 DB_1 和 DB_2）。拆分表也是同理計算。
在這個過程中，order_no 就是 t_order 表的分片鍵。也就是說，每一條訂單數(shù)據(jù)的 order_no 值決定了它應該存放的數(shù)據(jù)庫實例和表。選擇一個適合作為分片鍵的字段可以更好地利用水平分片帶來的性能提升。
這樣同一個訂單的相關數(shù)據(jù)就會落在同一個數(shù)據(jù)庫、表中，查詢訂單時同理計算，就可直接定位數(shù)據(jù)位置，大幅提升數(shù)據(jù)檢索的性能，避免了全庫表掃描。
不僅如此 ShardingSphere 還支持根據(jù)多個字段作為分片健進行分片，這個在后續(xù)對應章節(jié)中會詳細講。
分片策略 分片策略來指定使用哪種分片算法、選擇哪個字段作為分片鍵以及如何將數(shù)據(jù)分配到不同的節(jié)點上。
分片策略是由分片算法和分片健組合而成，分片策略中可以使用多種分片算法和對多個分片鍵進行運算。
分庫、分表的分片策略配置是相對獨立的，可以各自使用不同的策略與算法，每種策略中可以是多個分片算法的組合，每個分片算法可以對多個分片健做邏輯判斷。
分片算法 分片算法則是用于對分片鍵進行運算，將數(shù)據(jù)劃分到具體的數(shù)據(jù)節(jié)點中。
常用的分片算法有很多：
哈希分片 ：根據(jù)分片鍵的哈希值來決定數(shù)據(jù)應該落到哪個節(jié)點上。例如，根據(jù)用戶 ID 進行哈希分片，將屬于同一個用戶的數(shù)據(jù)分配到同一個節(jié)點上，便于后續(xù)的查詢操作。范圍分片 ：分片鍵值按區(qū)間范圍分配到不同的節(jié)點上。例如，根據(jù)訂單創(chuàng)建時間或者地理位置來進行分片。取模分片 ：將分片鍵值對分片數(shù)取模，將結果作為數(shù)據(jù)應該分配到的節(jié)點編號。例如， order_no % 2 將訂單數(shù)據(jù)分到兩個節(jié)點之一。實際業(yè)務開發(fā)中分片的邏輯要復雜的多，不同的算法適用于不同的場景和需求，需要根據(jù)實際情況進行選擇和調(diào)整。
綁定表 綁定表是那些具有相同分片規(guī)則的一組分片表，由于分片規(guī)則一致所產(chǎn)生的的數(shù)據(jù)落地位置相同，在JOIN聯(lián)合查詢時能有效避免跨庫 操作。
比如：t_order 訂單表和 t_order_item 訂單項目表，都以 order_no 字段作為分片鍵，并且使用 order_no 進行關聯(lián)，因此兩張表互為綁定表關系。
使用綁定表進行多表關聯(lián)查詢時，必須使用分片鍵進行關聯(lián)，否則會出現(xiàn)笛卡爾積關聯(lián)或跨庫關聯(lián)，從而影響查詢效率。
當使用 t_order 和 t_order_item 表進行多表聯(lián)合查詢，執(zhí)行如下聯(lián)合查詢的邏輯SQL。
select * from t_order o JOIN t_order_item i ON o.order_no=i.order_no如果不配置綁定表關系，兩個表的數(shù)據(jù)位置不確定就會全庫表查詢，出現(xiàn)笛卡爾積關聯(lián)查詢，將產(chǎn)生如下四條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
而配置綁定表關系后再進行關聯(lián)查詢時，分片規(guī)則一致產(chǎn)生的數(shù)據(jù)就會落到同一個庫表中，那么只需在當前庫中 t_order_n 和 t_order_item_n 表關聯(liá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
注意 ：在關聯(lián)查詢時 t_order 它作為整個聯(lián)合查詢的主表。所有相關的路由計算都只使用主表的策略，t_order_item 表的分片相關的計算也會使用 t_order 的條件，所以要保證綁定表之間的分片鍵要完全相同。
SQL 解析 分庫分表后在應用層面執(zhí)行一條 SQL 語句時，通常需要經(jīng)過以下六個步驟：SQL 解析 -> 執(zhí)⾏器優(yōu)化 -> SQL 路由 -> SQL 改寫 -> SQL 執(zhí)⾏ -> 結果歸并 。
在這里插入圖片描述 SQL解析過程分為詞法解析和語法解析兩步，比如下邊查詢用戶訂單的SQL，先用詞法解析將這條SQL拆解成不可再分的原子單元。在根據(jù)不同數(shù)據(jù)庫方言所提供的字典，將這些單元歸類為關鍵字，表達式，變量或者操作符等類型。
select order_no from t_order where order_status > 0 and user_id = 10086 接著語法解析會將拆分后的SQL關鍵字轉(zhuǎn)換為抽象語法樹，通過對抽象語法樹遍歷，提煉出分片所需的上下文，上下文包含查詢字段信息（Field）、表信息（Table）、查詢條件（Condition）、排序信息（Order By）、分組信息（Group By）以及分頁信息（Limit）等，并標記出 SQL中有可能需要改寫的位置。
抽象語法樹 執(zhí)⾏器優(yōu)化 執(zhí)⾏器優(yōu)化是根據(jù)SQL查詢特點和執(zhí)行統(tǒng)計信息，選擇最優(yōu)的查詢計劃并執(zhí)行，比如user_id字段有索引，那么會調(diào)整兩個查詢條件的位置，主要是提高SQL的執(zhí)行效率。
select order_no from t_order where user_id = 10086 and order_status > 0 SQL 路由 通過上邊的SQL解析得到了分片上下文數(shù)據(jù)，在匹配用戶配置的分片策略和算法，就可以運算生成路由路徑，將 SQL 語句路由到相應的數(shù)據(jù)節(jié)點上。
簡單點理解就是拿到分片策略中配置的分片鍵等信息，在從SQL解析結果中找到對應分片鍵字段的值，計算出 SQL該在哪個庫的哪個表中執(zhí)行，SQL路由又根據(jù)有無分片健分為 分片路由 和 廣播路由。
有分⽚鍵的路由叫分片路由，細分為直接路由、標準路由和笛卡爾積路由這3種類型。
標準路由 標準路由是最推薦也是最為常⽤的分⽚⽅式，它的適⽤范圍是不包含關聯(lián)查詢或僅包含綁定表之間關聯(lián)查詢的SQL。
當 SQL分片健的運算符為 = 時，路由結果將落⼊單庫（表），當分⽚運算符是 BETWEEN 或 IN 等范圍時，路由結果則不⼀定落⼊唯⼀的庫（表），因此⼀條邏輯SQL最終可能被拆分為多條⽤于執(zhí)⾏的真實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中的場景，還可以執(zhí)⾏包括⼦查詢、⾃定義函數(shù)等復雜情況的任意SQL。
笛卡爾積路由 笛卡爾路由是由⾮綁定表之間的關聯(lián)查詢產(chǎn)生的，比如訂單表t_order 分片鍵是t_order_id 和用戶表t_user分片鍵是t_order_id ，兩個表的分片鍵不同，要做聯(lián)表查詢，會執(zhí)行笛卡爾積路由，查詢性能較低盡量避免走此路由模式。
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種類型。
全庫表路由 全庫表路由針對的是數(shù)據(jù)庫 DQL 和 DML，以及 DDL等操作，當我們執(zhí)行一條邏輯表 t_order SQL時，在所有分片庫中對應的真實表 t_order_0 ··· t_order_n 內(nèi)逐一執(zhí)行。
全庫路由 全庫路由主要是對數(shù)據(jù)庫層面的操作，比如數(shù)據(jù)庫 SET 類型的數(shù)據(jù)庫管理命令，以及 TCL 這樣的事務控制語句。
對邏輯庫設置 autocommit 屬性后，所有對應的真實庫中都執(zhí)行該命令。
SET autocommit=0 ;全實例路由 全實例路由是針對數(shù)據(jù)庫實例的 DCL 操作（設置或更改數(shù)據(jù)庫用戶或角色權限），比如：創(chuàng)建一個用戶 order ，這個命令將在所有的真實庫實例中執(zhí)行，以此確保 order 用戶可以正常訪問每一個數(shù)據(jù)庫實例。
create USER order @127.0 .0 .1 identified BY '程序員小富' ;單播路由 單播路由用來獲取某一真實表信息，比如獲得表的描述信息：
DESCRIBE t_order; t_order 的真實表是 t_order_0 ···· t_order_n，他們的描述結構相完全同，我們只需在任意的真實表執(zhí)行一次就可以。
阻斷路由 ⽤來屏蔽SQL對數(shù)據(jù)庫的操作，例如：
USE order_db;這個命令不會在真實數(shù)據(jù)庫中執(zhí)⾏，因為 ShardingSphere 采⽤的是邏輯 Schema（數(shù)據(jù)庫的組織和結構） ⽅式，所以無需將切換數(shù)據(jù)庫的命令發(fā)送⾄真實數(shù)據(jù)庫中。
SQL 改寫 SQL經(jīng)過解析、優(yōu)化、路由后已經(jīng)明確分片具體的落地執(zhí)行的位置，接著就要將基于邏輯表開發(fā)的SQL改寫成可以在真實數(shù)據(jù)庫中可以正確執(zhí)行的語句。比如查詢 t_order 訂單表，我們實際開發(fā)中 SQL是按邏輯表 t_order 寫的。
select * from t_order這時需要將分表配置中的邏輯表名稱改寫為路由之后所獲取的真實表名稱。
select * from t_order_nSQL執(zhí)⾏ 將路由和改寫后的真實 SQL 安全且高效發(fā)送到底層數(shù)據(jù)源執(zhí)行。但這個過程并不能將 SQL 一股腦的通過 JDBC 直接發(fā)送至數(shù)據(jù)源執(zhí)行，需平衡數(shù)據(jù)源連接創(chuàng)建以及內(nèi)存占用所產(chǎn)生的消耗，它會自動化的平衡資源控制與執(zhí)行效率。
結果歸并 將從各個數(shù)據(jù)節(jié)點獲取的多數(shù)據(jù)結果集，合并成一個大的結果集并正確的返回至請求客戶端，稱為結果歸并。而我們SQL中的排序、分組、分頁和聚合等語法，均是在歸并后的結果集上進行操作的。
分布式主鍵 數(shù)據(jù)分⽚后，一個邏輯表（t_order）對應諸多的真實表（t_order_n），它們之間由于⽆法互相感知，主鍵ID都從初始值累加，所以必然會產(chǎn)⽣重復主鍵ID，此時主鍵不再唯一那么對于業(yè)務來說也就沒意義了。
盡管可通過設置表⾃增主鍵 初始值 和 步⻓ 的⽅式避免ID碰撞，但這樣會使維護成本加大，可擴展性差。
這個時候就需要我們手動為一條數(shù)據(jù)記錄，分配一個全局唯一的ID，這個ID被叫做分布式ID，而生產(chǎn)這個ID的系統(tǒng)通常被叫做發(fā)號器。
大家可以參考我之前發(fā)布的這篇文章 9種分布式ID生成方案
數(shù)據(jù)脫敏 分庫分表數(shù)據(jù)脫敏是一種有效的數(shù)據(jù)保護措施，可以確保敏感數(shù)據(jù)的機密性和安全性，減少數(shù)據(jù)泄露的風險。
比如，我們在分庫分表時可以指定表的哪些字段為脫敏列，并設置對應的脫敏算法，在數(shù)據(jù)分片時解析到執(zhí)行SQL中有待脫敏字段，會直接將字段值脫敏后的寫入庫表內(nèi)。
對于用戶的個人信息，如姓名、地址和電話號碼等，可以通過加密、隨機化或替換成偽隨機數(shù)據(jù)的方式進行脫敏，以確保用戶的隱私得到保護。
大家可以參考我之前發(fā)布的這篇文章 大廠也在用的 6種 數(shù)據(jù)脫敏方案
分布式事務 分布式事務的核心問題是如何實現(xiàn)跨多個數(shù)據(jù)源的原子性操作。
由于不同的服務通常會使用不同的數(shù)據(jù)源來存儲和管理數(shù)據(jù)，因此，跨數(shù)據(jù)源的操作可能會導致數(shù)據(jù)不一致性或丟失的風險。因此，保證分布式事務的一致性是非常重要的。
以訂單系統(tǒng)為例，它需要調(diào)用支付系統(tǒng)、庫存系統(tǒng)、積分系統(tǒng)等多個系統(tǒng)，而每個系統(tǒng)都維護自己的數(shù)據(jù)庫實例，系統(tǒng)間通過API接口交換數(shù)據(jù)。
為了保證下單后多個系統(tǒng)同時調(diào)用成功，可以使用強一致性事務的XA協(xié)議，或者柔性事務的代表工具Seata，來實現(xiàn)分布式事務的一致性。這些工具可以幫助開發(fā)人員簡化分布式事務的實現(xiàn)，減少錯誤和漏洞的出現(xiàn)，提高系統(tǒng)的穩(wěn)定性和可靠性。
經(jīng)過分庫分表之后，問題的難度進一步提升。自身訂單服務，也需要處理跨數(shù)據(jù)源的操作。這樣一來，系統(tǒng)的復雜度顯著增加。因此，不到萬不得已的情況下，最好避免采用分庫分表的解決方案。
關于分布式事務詳細的介紹，大家可以參考我之前發(fā)布的這篇文章 對比 5 種分布式事務方案，還是寵幸了阿里的 Seata（原理 + 實戰(zhàn)）
數(shù)據(jù)遷移 分庫分表后還有個讓人頭疼的問題，那就是數(shù)據(jù)遷移，為了不影響現(xiàn)有的業(yè)務系統(tǒng)，通常會新建數(shù)據(jù)庫集群遷移數(shù)據(jù)。將數(shù)據(jù)從舊集群的數(shù)據(jù)庫、表遷移到新集群的分庫、分表中。這是一個比較復雜的過程，在遷移過程中需要考慮數(shù)據(jù)量、數(shù)據(jù)一致性、遷移速度等諸多因素。
遷移主要針對 存量數(shù)據(jù) 和 增量數(shù)據(jù) 的處理，存量數(shù)據(jù)指舊數(shù)據(jù)源中已經(jīng)存在且有價值的歷史數(shù)據(jù)，增量數(shù)據(jù)指當下持續(xù)增長以及未來產(chǎn)生的業(yè)務數(shù)據(jù)。
存量數(shù)據(jù)可以采用定時、分批次的遷移，遷移過程可能會持續(xù)幾天。
增量數(shù)據(jù)可以采用新、舊數(shù)據(jù)庫集群雙寫模式。待數(shù)據(jù)遷移完畢，業(yè)務驗證了數(shù)據(jù)一致性，應用直接切換數(shù)據(jù)源即可。
后續(xù)我們會結合三方工具，來演示遷移的過程。
影子庫 什么是影子庫（Shadow Table）？
影子庫是一個與生產(chǎn)環(huán)境數(shù)據(jù)庫結構完全相同的實例，它存在的意義是為了在不影響線上系統(tǒng)的情況下，驗證數(shù)據(jù)庫遷移或者其他數(shù)據(jù)庫變更操作的正確性，以及全鏈路壓測。影子庫中存儲的數(shù)據(jù)是從生產(chǎn)環(huán)境中定期復制過來的，但是它不對線上業(yè)務產(chǎn)生任何影響，僅用于測試，驗證和調(diào)試。
在進行數(shù)據(jù)庫升級、版本變更、參數(shù)調(diào)優(yōu)等操作前，通過在影子庫上模擬這些操作，可以發(fā)現(xiàn)潛在的問題，因為測試環(huán)境的數(shù)據(jù)是不可靠的。
在使用影子庫時，需要遵循以下幾個原則：
與生產(chǎn)環(huán)境數(shù)據(jù)庫的結構應該完全一致，包括表結構、索引、約束等；
數(shù)據(jù)要與生產(chǎn)環(huán)境保持一致，可以通過定期同步方式實現(xiàn)；
讀寫操作不會影響生產(chǎn)環(huán)境，一般情況下應該禁止在影子庫上執(zhí)行更新、刪除等操作；
由于影子庫的數(shù)據(jù)特點，訪問權限應該嚴格控制，只允許授權人員進行訪問和操作；
總結 本文介紹了關于分庫分表架構的21個通用概念，有一定的了解之后，接下來我們將進入更深度的內(nèi)容，包括讀寫分離、數(shù)據(jù)脫敏、分布式主鍵、分布式事務、配置中心、注冊中心、Proxy服務等實戰(zhàn)案例的講解和源碼分析。
下期文章將是《分庫分表ShardingSphere5.x原理與實戰(zhàn)》系列的第三篇，《快速實現(xiàn)分庫分表的 2種方式》 。
400 186 1886
