大家好，我是小富～

（一）好好的系統(tǒng)，為什么要分庫(kù)分表？

本文是《分庫(kù)分表ShardingSphere5.x原理與實(shí)戰(zhàn)》系列的第二篇文章，距離上一篇文章已經(jīng)過(guò)去好久了，慚愧慚愧～

還是不著急實(shí)戰(zhàn)，咱們先介紹下在分庫(kù)分表架構(gòu)實(shí)施過(guò)程中，會(huì)接觸到的一些通用概念，了解這些概念能夠幫助理解市面上其他的分庫(kù)分表工具，盡管它們的實(shí)現(xiàn)方法可能存在差異，但整體思路基本一致。因此，在開(kāi)始實(shí)際操作之前，我們有必要先掌握這些通用概念，以便更好地理解和應(yīng)用分庫(kù)分表技術(shù)。

我們結(jié)合具體業(yè)務(wù)場(chǎng)景，以t_order表為例進(jìn)行架構(gòu)優(yōu)化。由于數(shù)據(jù)量已經(jīng)達(dá)到億級(jí)別，查詢性能嚴(yán)重下降，因此我們采用了分庫(kù)分表技術(shù)來(lái)處理這個(gè)問(wèn)題。具體而言，我們將原本的單庫(kù)分成了兩個(gè)庫(kù)，分別為DB_1和DB_2，并在每個(gè)庫(kù)中再次進(jìn)行分表處理，生成t_order_1和t_order_2兩張表，實(shí)現(xiàn)對(duì)訂單表的分庫(kù)分表處理。

數(shù)據(jù)分片

通常我們?cè)谔岬椒謳?kù)分表的時(shí)候，大多是以水平切分模式（水平分庫(kù)、分表）為基礎(chǔ)來(lái)說(shuō)的，數(shù)據(jù)分片它將原本一張數(shù)據(jù)量較大的表 t_order 拆分生成數(shù)個(gè)表結(jié)構(gòu)完全一致的小數(shù)據(jù)量表（拆分表） t_order_0、t_order_1、···、t_order_n，每張表只存儲(chǔ)原大表中的一部分?jǐn)?shù)據(jù)。

數(shù)據(jù)節(jié)點(diǎn)

數(shù)據(jù)節(jié)點(diǎn)是數(shù)據(jù)分片中一個(gè)不可再分的最小單元（表），它由數(shù)據(jù)源名稱和數(shù)據(jù)表組成，例如上圖中 DB_1.t_order_1、DB_2.t_order_2 就表示一個(gè)數(shù)據(jù)節(jié)點(diǎn)。

邏輯表

邏輯表是指具有相同結(jié)構(gòu)的水平拆分表的邏輯名稱。

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

分庫(kù)分表通常對(duì)業(yè)務(wù)代碼都是無(wú)侵入式的，開(kāi)發(fā)者只專注于業(yè)務(wù)邏輯SQL編碼，我們?cè)诖a中SQL依然按 t_order來(lái)寫，而在執(zhí)行邏輯SQL前將其解析成對(duì)應(yīng)的數(shù)據(jù)庫(kù)真實(shí)執(zhí)行的SQL。此時(shí) t_order 就是這些拆分表的邏輯表。

業(yè)務(wù)邏輯SQL

select * from t_order where order_no='A11111'

真實(shí)執(zhí)行SQL

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

真實(shí)表

真實(shí)表就是在數(shù)據(jù)庫(kù)中真實(shí)存在的物理表DB_1.t_order_n。

廣播表

廣播表是一類特殊的表，其表結(jié)構(gòu)和數(shù)據(jù)在所有分片數(shù)據(jù)源中均完全一致。與拆分表相比，廣播表的數(shù)據(jù)量較小、更新頻率較低，通常用于字典表或配置表等場(chǎng)景。由于其在所有節(jié)點(diǎn)上都有副本，因此可以大大降低JOIN關(guān)聯(lián)查詢的網(wǎng)絡(luò)開(kāi)銷，提高查詢效率。

需要注意的是，對(duì)于廣播表的修改操作需要保證同步性，以確保所有節(jié)點(diǎn)上的數(shù)據(jù)保持一致。

廣播表的特點(diǎn)：

• 在所有分片數(shù)據(jù)源中，廣播表的數(shù)據(jù)完全一致。因此，對(duì)廣播表的操作（如插入、更新和刪除）會(huì)實(shí)時(shí)在每個(gè)分片數(shù)據(jù)源中執(zhí)行一遍，以保證數(shù)據(jù)的一致性。
• 對(duì)于廣播表的查詢操作，僅需要在任意一個(gè)分片數(shù)據(jù)源中執(zhí)行一次即可。
• 與任何其他表進(jìn)行JOIN操作都是可行的，因?yàn)橛捎趶V播表的數(shù)據(jù)在所有節(jié)點(diǎn)上均一致，所以可以訪問(wèn)到任何一個(gè)節(jié)點(diǎn)上的相同數(shù)據(jù)。

什么樣的表可以作為廣播表呢？

訂單管理系統(tǒng)中，往往需要查詢統(tǒng)計(jì)某個(gè)城市地區(qū)的訂單數(shù)據(jù)，這就會(huì)涉及到省份地區(qū)表t_city與訂單流水表DB_n.t_order_n進(jìn)行JOIN查詢，因此可以考慮將省份地區(qū)表設(shè)計(jì)為廣播表，核心理念就是避免跨庫(kù)JOIN操作。

注意：上邊我們提到廣播表在數(shù)據(jù)插入、更新與刪除會(huì)實(shí)時(shí)在每個(gè)分片數(shù)據(jù)源均執(zhí)行，也就是說(shuō)如果你有1000個(gè)分片數(shù)據(jù)源，那么修改一次廣播表就要執(zhí)行1000次SQL，所以盡量不在并發(fā)環(huán)境下和業(yè)務(wù)高峰時(shí)進(jìn)行，以免影響系統(tǒng)的性能。

單表

單表指所有的分片數(shù)據(jù)源中僅唯一存在的表（沒(méi)有分片的表），適用于數(shù)據(jù)量不大且無(wú)需分片的表。

如果一張表的數(shù)據(jù)量預(yù)估在千萬(wàn)級(jí)別，且沒(méi)有與其他拆分表進(jìn)行關(guān)聯(lián)查詢的需求，建議將其設(shè)置為單表類型，存儲(chǔ)在默認(rèn)分片數(shù)據(jù)源中。

分片鍵

分片鍵決定了數(shù)據(jù)落地的位置，也就是數(shù)據(jù)將會(huì)被分配到哪個(gè)數(shù)據(jù)節(jié)點(diǎn)上存儲(chǔ)。因此，分片鍵的選擇非常重要。

比如我們將 t_order 表進(jìn)行分片后，當(dāng)插入一條訂單數(shù)據(jù)執(zhí)行SQL時(shí)，需要通過(guò)解析SQL語(yǔ)句中指定的分片鍵來(lái)計(jì)算數(shù)據(jù)應(yīng)該落在哪個(gè)分片中。以表中order_no字段為例，我們可以通過(guò)對(duì)其取模運(yùn)算（比如 order_no % 2）來(lái)得到分片編號(hào)，然后根據(jù)分片編號(hào)分配數(shù)據(jù)到對(duì)應(yīng)的數(shù)據(jù)庫(kù)實(shí)例（比如 DB_1 和 DB_2）。拆分表也是同理計(jì)算。

在這個(gè)過(guò)程中，order_no 就是 t_order 表的分片鍵。也就是說(shuō)，每一條訂單數(shù)據(jù)的 order_no 值決定了它應(yīng)該存放的數(shù)據(jù)庫(kù)實(shí)例和表。選擇一個(gè)適合作為分片鍵的字段可以更好地利用水平分片帶來(lái)的性能提升。

這樣同一個(gè)訂單的相關(guān)數(shù)據(jù)就會(huì)落在同一個(gè)數(shù)據(jù)庫(kù)、表中，查詢訂單時(shí)同理計(jì)算，就可直接定位數(shù)據(jù)位置，大幅提升數(shù)據(jù)檢索的性能，避免了全庫(kù)表掃描。

不僅如此 ShardingSphere 還支持根據(jù)多個(gè)字段作為分片健進(jìn)行分片，這個(gè)在后續(xù)對(duì)應(yīng)章節(jié)中會(huì)詳細(xì)講。

分片策略

分片策略來(lái)指定使用哪種分片算法、選擇哪個(gè)字段作為分片鍵以及如何將數(shù)據(jù)分配到不同的節(jié)點(diǎn)上。

分片策略是由分片算法和分片健組合而成，分片策略中可以使用多種分片算法和對(duì)多個(gè)分片鍵進(jìn)行運(yùn)算。

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

分片算法

分片算法則是用于對(duì)分片鍵進(jìn)行運(yùn)算，將數(shù)據(jù)劃分到具體的數(shù)據(jù)節(jié)點(diǎn)中。

常用的分片算法有很多：

• 哈希分片：根據(jù)分片鍵的哈希值來(lái)決定數(shù)據(jù)應(yīng)該落到哪個(gè)節(jié)點(diǎn)上。例如，根據(jù)用戶 ID 進(jìn)行哈希分片，將屬于同一個(gè)用戶的數(shù)據(jù)分配到同一個(gè)節(jié)點(diǎn)上，便于后續(xù)的查詢操作。
• 范圍分片：分片鍵值按區(qū)間范圍分配到不同的節(jié)點(diǎn)上。例如，根據(jù)訂單創(chuàng)建時(shí)間或者地理位置來(lái)進(jìn)行分片。
• 取模分片：將分片鍵值對(duì)分片數(shù)取模，將結(jié)果作為數(shù)據(jù)應(yīng)該分配到的節(jié)點(diǎn)編號(hào)。例如， order_no % 2 將訂單數(shù)據(jù)分到兩個(gè)節(jié)點(diǎn)之一。
• .....

實(shí)際業(yè)務(wù)開(kāi)發(fā)中分片的邏輯要復(fù)雜的多，不同的算法適用于不同的場(chǎng)景和需求，需要根據(jù)實(shí)際情況進(jìn)行選擇和調(diào)整。

綁定表

綁定表是那些具有相同分片規(guī)則的一組分片表，由于分片規(guī)則一致所產(chǎn)生的的數(shù)據(jù)落地位置相同，在JOIN聯(lián)合查詢時(shí)能有效避免跨庫(kù)操作。

比如：t_order 訂單表和 t_order_item 訂單項(xiàng)目表，都以 order_no 字段作為分片鍵，并且使用 order_no 進(jìn)行關(guān)聯(lián)，因此兩張表互為綁定表關(guān)系。

使用綁定表進(jìn)行多表關(guān)聯(lián)查詢時(shí)，必須使用分片鍵進(jìn)行關(guān)聯(lián)，否則會(huì)出現(xiàn)笛卡爾積關(guān)聯(lián)或跨庫(kù)關(guān)聯(lián)，從而影響查詢效率。

當(dāng)使用 t_order 和 t_order_item 表進(jìn)行多表聯(lián)合查詢，執(zhí)行如下聯(lián)合查詢的邏輯SQL。

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

如果不配置綁定表關(guān)系，兩個(gè)表的數(shù)據(jù)位置不確定就會(huì)全庫(kù)表查詢，出現(xiàn)笛卡爾積關(guā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

而配置綁定表關(guān)系后再進(jìn)行關(guān)聯(lián)查詢時(shí)，分片規(guī)則一致產(chǎn)生的數(shù)據(jù)就會(huì)落到同一個(gè)庫(kù)表中，那么只需在當(dāng)前庫(kù)中 t_order_n 和 t_order_item_n 表關(guā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

注意：在關(guān)聯(lián)查詢時(shí) t_order 它作為整個(gè)聯(lián)合查詢的主表。所有相關(guān)的路由計(jì)算都只使用主表的策略，t_order_item 表的分片相關(guān)的計(jì)算也會(huì)使用 t_order 的條件，所以要保證綁定表之間的分片鍵要完全相同。

SQL 解析

分庫(kù)分表后在應(yīng)用層面執(zhí)行一條 SQL 語(yǔ)句時(shí)，通常需要經(jīng)過(guò)以下六個(gè)步驟：SQL 解析 -> 執(zhí)?器優(yōu)化 -> SQL 路由 -> SQL 改寫 -> SQL 執(zhí)? -> 結(jié)果歸并 。

SQL解析過(guò)程分為詞法解析和語(yǔ)法解析兩步，比如下邊查詢用戶訂單的SQL，先用詞法解析將這條SQL拆解成不可再分的原子單元。在根據(jù)不同數(shù)據(jù)庫(kù)方言所提供的字典，將這些單元?dú)w類為關(guān)鍵字，表達(dá)式，變量或者操作符等類型。

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

接著語(yǔ)法解析會(huì)將拆分后的SQL關(guān)鍵字轉(zhuǎn)換為抽象語(yǔ)法樹(shù)，通過(guò)對(duì)抽象語(yǔ)法樹(shù)遍歷，提煉出分片所需的上下文，上下文包含查詢字段信息（Field）、表信息（Table）、查詢條件（Condition）、排序信息（Order By）、分組信息（Group By）以及分頁(yè)信息（Limit）等，并標(biāo)記出 SQL中有可能需要改寫的位置。

抽象語(yǔ)法樹(shù)

執(zhí)?器優(yōu)化

執(zhí)?器優(yōu)化是根據(jù)SQL查詢特點(diǎn)和執(zhí)行統(tǒng)計(jì)信息，選擇最優(yōu)的查詢計(jì)劃并執(zhí)行，比如user_id字段有索引，那么會(huì)調(diào)整兩個(gè)查詢條件的位置，主要是提高SQL的執(zhí)行效率。

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

SQL 路由

通過(guò)上邊的SQL解析得到了分片上下文數(shù)據(jù)，在匹配用戶配置的分片策略和算法，就可以運(yùn)算生成路由路徑，將 SQL 語(yǔ)句路由到相應(yīng)的數(shù)據(jù)節(jié)點(diǎn)上。

簡(jiǎn)單點(diǎn)理解就是拿到分片策略中配置的分片鍵等信息，在從SQL解析結(jié)果中找到對(duì)應(yīng)分片鍵字段的值，計(jì)算出 SQL該在哪個(gè)庫(kù)的哪個(gè)表中執(zhí)行，SQL路由又根據(jù)有無(wú)分片健分為 分片路由 和 廣播路由。

有分?鍵的路由叫分片路由，細(xì)分為直接路由、標(biāo)準(zhǔn)路由和笛卡爾積路由這3種類型。

標(biāo)準(zhǔn)路由

標(biāo)準(zhǔn)路由是最推薦也是最為常?的分??式，它的適?范圍是不包含關(guān)聯(lián)查詢或僅包含綁定表之間關(guān)聯(lián)查詢的SQL。

當(dāng) SQL分片健的運(yùn)算符為 = 時(shí)，路由結(jié)果將落?單庫(kù)（表），當(dāng)分?運(yùn)算符是 BETWEEN 或 IN 等范圍時(shí)，路由結(jié)果則不?定落?唯?的庫(kù)（表），因此?條邏輯SQL最終可能被拆分為多條?于執(zhí)?的真實(shí)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路由到指定?庫(kù)、表的一種分?方式，而且直接路由可以?于分?鍵不在SQL中的場(chǎng)景，還可以執(zhí)?包括?查詢、?定義函數(shù)等復(fù)雜情況的任意SQL。

笛卡爾積路由

笛卡爾路由是由?綁定表之間的關(guān)聯(lián)查詢產(chǎn)生的，比如訂單表t_order 分片鍵是t_order_id 和用戶表t_user分片鍵是t_order_id ，兩個(gè)表的分片鍵不同，要做聯(lián)表查詢，會(huì)執(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

無(wú)分?鍵的路由又叫做廣播路由，可以劃分為全庫(kù)表路由、全庫(kù)路由、 全實(shí)例路由、單播路由和阻斷路由這 5種類型。

全庫(kù)表路由

全庫(kù)表路由針對(duì)的是數(shù)據(jù)庫(kù) DQL 和 DML，以及 DDL等操作，當(dāng)我們執(zhí)行一條邏輯表 t_order SQL時(shí)，在所有分片庫(kù)中對(duì)應(yīng)的真實(shí)表 t_order_0 ···  t_order_n 內(nèi)逐一執(zhí)行。

全庫(kù)路由

全庫(kù)路由主要是對(duì)數(shù)據(jù)庫(kù)層面的操作，比如數(shù)據(jù)庫(kù) SET 類型的數(shù)據(jù)庫(kù)管理命令，以及 TCL 這樣的事務(wù)控制語(yǔ)句。

對(duì)邏輯庫(kù)設(shè)置 autocommit 屬性后，所有對(duì)應(yīng)的真實(shí)庫(kù)中都執(zhí)行該命令。

SET autocommit=0;

全實(shí)例路由

全實(shí)例路由是針對(duì)數(shù)據(jù)庫(kù)實(shí)例的 DCL 操作（設(shè)置或更改數(shù)據(jù)庫(kù)用戶或角色權(quán)限），比如：創(chuàng)建一個(gè)用戶 order ，這個(gè)命令將在所有的真實(shí)庫(kù)實(shí)例中執(zhí)行，以此確保 order 用戶可以正常訪問(wèn)每一個(gè)數(shù)據(jù)庫(kù)實(shí)例。

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

單播路由

單播路由用來(lái)獲取某一真實(shí)表信息，比如獲得表的描述信息：

DESCRIBE t_order;

t_order 的真實(shí)表是 t_order_0 ···· t_order_n，他們的描述結(jié)構(gòu)相完全同，我們只需在任意的真實(shí)表執(zhí)行一次就可以。

阻斷路由

?來(lái)屏蔽SQL對(duì)數(shù)據(jù)庫(kù)的操作，例如：

USE order_db;

這個(gè)命令不會(huì)在真實(shí)數(shù)據(jù)庫(kù)中執(zhí)?，因?yàn)?nbsp;ShardingSphere 采?的是邏輯 Schema（數(shù)據(jù)庫(kù)的組織和結(jié)構(gòu)） ?式，所以無(wú)需將切換數(shù)據(jù)庫(kù)的命令發(fā)送?真實(shí)數(shù)據(jù)庫(kù)中。

SQL 改寫

SQL經(jīng)過(guò)解析、優(yōu)化、路由后已經(jīng)明確分片具體的落地執(zhí)行的位置，接著就要將基于邏輯表開(kāi)發(fā)的SQL改寫成可以在真實(shí)數(shù)據(jù)庫(kù)中可以正確執(zhí)行的語(yǔ)句。比如查詢 t_order 訂單表，我們實(shí)際開(kāi)發(fā)中 SQL是按邏輯表 t_order 寫的。

SELECT * FROM t_order

這時(shí)需要將分表配置中的邏輯表名稱改寫為路由之后所獲取的真實(shí)表名稱。

SELECT * FROM t_order_n

SQL執(zhí)?

將路由和改寫后的真實(shí) SQL 安全且高效發(fā)送到底層數(shù)據(jù)源執(zhí)行。但這個(gè)過(guò)程并不能將 SQL 一股腦的通過(guò) JDBC 直接發(fā)送至數(shù)據(jù)源執(zhí)行，需平衡數(shù)據(jù)源連接創(chuàng)建以及內(nèi)存占用所產(chǎn)生的消耗，它會(huì)自動(dòng)化的平衡資源控制與執(zhí)行效率。

結(jié)果歸并

將從各個(gè)數(shù)據(jù)節(jié)點(diǎn)獲取的多數(shù)據(jù)結(jié)果集，合并成一個(gè)大的結(jié)果集并正確的返回至請(qǐng)求客戶端，稱為結(jié)果歸并。而我們SQL中的排序、分組、分頁(yè)和聚合等語(yǔ)法，均是在歸并后的結(jié)果集上進(jìn)行操作的。

分布式主鍵

數(shù)據(jù)分?后，一個(gè)邏輯表（t_order）對(duì)應(yīng)諸多的真實(shí)表（t_order_n），它們之間由于?法互相感知，主鍵ID都從初始值累加，所以必然會(huì)產(chǎn)?重復(fù)主鍵ID，此時(shí)主鍵不再唯一那么對(duì)于業(yè)務(wù)來(lái)說(shuō)也就沒(méi)意義了。

盡管可通過(guò)設(shè)置表?增主鍵 初始值 和 步? 的?式避免ID碰撞，但這樣會(huì)使維護(hù)成本加大，可擴(kuò)展性差。

這個(gè)時(shí)候就需要我們手動(dòng)為一條數(shù)據(jù)記錄，分配一個(gè)全局唯一的ID，這個(gè)ID被叫做分布式ID，而生產(chǎn)這個(gè)ID的系統(tǒng)通常被叫做發(fā)號(hào)器。

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

數(shù)據(jù)脫敏

分庫(kù)分表數(shù)據(jù)脫敏是一種有效的數(shù)據(jù)保護(hù)措施，可以確保敏感數(shù)據(jù)的機(jī)密性和安全性，減少數(shù)據(jù)泄露的風(fēng)險(xiǎn)。

比如，我們?cè)诜謳?kù)分表時(shí)可以指定表的哪些字段為脫敏列，并設(shè)置對(duì)應(yīng)的脫敏算法，在數(shù)據(jù)分片時(shí)解析到執(zhí)行SQL中有待脫敏字段，會(huì)直接將字段值脫敏后的寫入庫(kù)表內(nèi)。

對(duì)于用戶的個(gè)人信息，如姓名、地址和電話號(hào)碼等，可以通過(guò)加密、隨機(jī)化或替換成偽隨機(jī)數(shù)據(jù)的方式進(jìn)行脫敏，以確保用戶的隱私得到保護(hù)。

大家可以參考我之前發(fā)布的這篇文章 大廠也在用的 6種 數(shù)據(jù)脫敏方案

分布式事務(wù)

分布式事務(wù)的核心問(wèn)題是如何實(shí)現(xiàn)跨多個(gè)數(shù)據(jù)源的原子性操作。

由于不同的服務(wù)通常會(huì)使用不同的數(shù)據(jù)源來(lái)存儲(chǔ)和管理數(shù)據(jù)，因此，跨數(shù)據(jù)源的操作可能會(huì)導(dǎo)致數(shù)據(jù)不一致性或丟失的風(fēng)險(xiǎn)。因此，保證分布式事務(wù)的一致性是非常重要的。

以訂單系統(tǒng)為例，它需要調(diào)用支付系統(tǒng)、庫(kù)存系統(tǒng)、積分系統(tǒng)等多個(gè)系統(tǒng)，而每個(gè)系統(tǒng)都維護(hù)自己的數(shù)據(jù)庫(kù)實(shí)例，系統(tǒng)間通過(guò)API接口交換數(shù)據(jù)。

為了保證下單后多個(gè)系統(tǒng)同時(shí)調(diào)用成功，可以使用強(qiáng)一致性事務(wù)的XA協(xié)議，或者柔性事務(wù)的代表工具Seata，來(lái)實(shí)現(xiàn)分布式事務(wù)的一致性。這些工具可以幫助開(kāi)發(fā)人員簡(jiǎn)化分布式事務(wù)的實(shí)現(xiàn)，減少錯(cuò)誤和漏洞的出現(xiàn)，提高系統(tǒng)的穩(wěn)定性和可靠性。

經(jīng)過(guò)分庫(kù)分表之后，問(wèn)題的難度進(jìn)一步提升。自身訂單服務(wù)，也需要處理跨數(shù)據(jù)源的操作。這樣一來(lái)，系統(tǒng)的復(fù)雜度顯著增加。因此，不到萬(wàn)不得已的情況下，最好避免采用分庫(kù)分表的解決方案。

關(guān)于分布式事務(wù)詳細(xì)的介紹，大家可以參考我之前發(fā)布的這篇文章 對(duì)比 5 種分布式事務(wù)方案，還是寵幸了阿里的 Seata（原理 + 實(shí)戰(zhàn)）

數(shù)據(jù)遷移

分庫(kù)分表后還有個(gè)讓人頭疼的問(wèn)題，那就是數(shù)據(jù)遷移，為了不影響現(xiàn)有的業(yè)務(wù)系統(tǒng)，通常會(huì)新建數(shù)據(jù)庫(kù)集群遷移數(shù)據(jù)。將數(shù)據(jù)從舊集群的數(shù)據(jù)庫(kù)、表遷移到新集群的分庫(kù)、分表中。這是一個(gè)比較復(fù)雜的過(guò)程，在遷移過(guò)程中需要考慮數(shù)據(jù)量、數(shù)據(jù)一致性、遷移速度等諸多因素。

遷移主要針對(duì) 存量數(shù)據(jù) 和 增量數(shù)據(jù) 的處理，存量數(shù)據(jù)指舊數(shù)據(jù)源中已經(jīng)存在且有價(jià)值的歷史數(shù)據(jù)，增量數(shù)據(jù)指當(dāng)下持續(xù)增長(zhǎng)以及未來(lái)產(chǎn)生的業(yè)務(wù)數(shù)據(jù)。

存量數(shù)據(jù)可以采用定時(shí)、分批次的遷移，遷移過(guò)程可能會(huì)持續(xù)幾天。

增量數(shù)據(jù)可以采用新、舊數(shù)據(jù)庫(kù)集群雙寫模式。待數(shù)據(jù)遷移完畢，業(yè)務(wù)驗(yàn)證了數(shù)據(jù)一致性，應(yīng)用直接切換數(shù)據(jù)源即可。

后續(xù)我們會(huì)結(jié)合三方工具，來(lái)演示遷移的過(guò)程。

影子庫(kù)

什么是影子庫(kù)（Shadow Table）？

影子庫(kù)是一個(gè)與生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)結(jié)構(gòu)完全相同的實(shí)例，它存在的意義是為了在不影響線上系統(tǒng)的情況下，驗(yàn)證數(shù)據(jù)庫(kù)遷移或者其他數(shù)據(jù)庫(kù)變更操作的正確性，以及全鏈路壓測(cè)。影子庫(kù)中存儲(chǔ)的數(shù)據(jù)是從生產(chǎn)環(huán)境中定期復(fù)制過(guò)來(lái)的，但是它不對(duì)線上業(yè)務(wù)產(chǎn)生任何影響，僅用于測(cè)試，驗(yàn)證和調(diào)試。

在進(jìn)行數(shù)據(jù)庫(kù)升級(jí)、版本變更、參數(shù)調(diào)優(yōu)等操作前，通過(guò)在影子庫(kù)上模擬這些操作，可以發(fā)現(xiàn)潛在的問(wèn)題，因?yàn)闇y(cè)試環(huán)境的數(shù)據(jù)是不可靠的。

在使用影子庫(kù)時(shí)，需要遵循以下幾個(gè)原則：

• 與生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)的結(jié)構(gòu)應(yīng)該完全一致，包括表結(jié)構(gòu)、索引、約束等；
• 數(shù)據(jù)要與生產(chǎn)環(huán)境保持一致，可以通過(guò)定期同步方式實(shí)現(xiàn)；
• 讀寫操作不會(huì)影響生產(chǎn)環(huán)境，一般情況下應(yīng)該禁止在影子庫(kù)上執(zhí)行更新、刪除等操作；
• 由于影子庫(kù)的數(shù)據(jù)特點(diǎn)，訪問(wèn)權(quán)限應(yīng)該嚴(yán)格控制，只允許授權(quán)人員進(jìn)行訪問(wèn)和操作；

總結(jié)

本文介紹了關(guān)于分庫(kù)分表架構(gòu)的21個(gè)通用概念，有一定的了解之后，接下來(lái)我們將進(jìn)入更深度的內(nèi)容，包括讀寫分離、數(shù)據(jù)脫敏、分布式主鍵、分布式事務(wù)、配置中心、注冊(cè)中心、Proxy服務(wù)等實(shí)戰(zhàn)案例的講解和源碼分析。