大家好，我是小富～
技術(shù)交流：歡迎關(guān)注：程序員小富
本文是《分庫分表ShardingSphere5.x原理與實(shí)戰(zhàn)》系列的第二篇文章，距離上一篇文章已經(jīng)過去好久了村怪，慚愧慚愧～
還是不著急實(shí)戰(zhàn)秽浇，咱們先介紹下在分庫分表架構(gòu)實(shí)施過程中，會(huì)接觸到的一些通用概念甚负，了解這些概念能夠幫助理解市面上其他的分庫分表工具柬焕，盡管它們的實(shí)現(xiàn)方法可能存在差異，但整體思路基本一致腊敲。因此击喂，在開始實(shí)際操作之前，我們有必要先掌握這些通用概念碰辅，以便更好地理解和應(yīng)用分庫分表技術(shù)懂昂。
我們結(jié)合具體業(yè)務(wù)場(chǎng)景，以t_order表為例進(jìn)行架構(gòu)優(yōu)化没宾。由于數(shù)據(jù)量已經(jīng)達(dá)到億級(jí)別凌彬，查詢性能嚴(yán)重下降沸柔，因此我們采用了分庫分表技術(shù)來處理這個(gè)問題。具體而言铲敛，我們將原本的單庫分成了兩個(gè)庫褐澎，分別為DB_1和DB_2，并在每個(gè)庫中再次進(jìn)行分表處理伐蒋，生成t_order_1和t_order_2兩張表工三，實(shí)現(xiàn)對(duì)訂單表的分庫分表處理。
[圖片上傳失敗...(image-19b395-1684122255127)]
數(shù)據(jù)分片
通常我們?cè)谔岬椒謳旆直淼臅r(shí)候先鱼，大多是以水平切分模式（水平分庫俭正、分表）為基礎(chǔ)來說的，數(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ù)儿惫。
[圖片上傳失敗...(image-913732-1684122255127)]
數(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)。
[圖片上傳失敗...(image-983a83-1684122255127)]
邏輯表
邏輯表是指具有相同結(jié)構(gòu)的水平拆分表的邏輯名稱砌烁。
比如我們將訂單表t_order 分表拆分成 t_order_0 ··· t_order_9等10張表筐喳，這時(shí)我們的數(shù)據(jù)庫中已經(jīng)不存在 t_order這張表，取而代之的是若干的t_order_n表函喉。
分庫分表通常對(duì)業(yè)務(wù)代碼都是無侵入式的避归，開發(fā)者只專注于業(yè)務(wù)邏輯SQL編碼，我們?cè)诖a中SQL依然按 t_order來寫管呵，而在執(zhí)行邏輯SQL前將其解析成對(duì)應(yīng)的數(shù)據(jù)庫真實(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ù)庫中真實(shí)存在的物理表DB_1.t_order_n捐下。
[圖片上傳失敗...(image-9a240e-1684122255127)]
廣播表
廣播表是一類特殊的表账锹，其表結(jié)構(gòu)和數(shù)據(jù)在所有分片數(shù)據(jù)源中均完全一致。與拆分表相比坷襟，廣播表的數(shù)據(jù)量較小奸柬、更新頻率較低，通常用于字典表或配置表等場(chǎng)景婴程。由于其在所有節(jié)點(diǎn)上都有副本廓奕，因此可以大大降低JOIN關(guān)聯(lián)查詢的網(wǎng)絡(luò)開銷，提高查詢效率。
需要注意的是桌粉，對(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)上均一致恕齐，所以可以訪問到任何一個(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ì)為廣播表士骤，核心理念就是避免跨庫JOIN操作。
[圖片上傳失敗...(image-c3fd4-1684122255127)]
注意：上邊我們提到廣播表在數(shù)據(jù)插入蕾域、更新與刪除會(huì)實(shí)時(shí)在每個(gè)分片數(shù)據(jù)源均執(zhí)行拷肌，也就是說如果你有1000個(gè)分片數(shù)據(jù)源，那么修改一次廣播表就要執(zhí)行1000次SQL旨巷，所以盡量不在并發(fā)環(huán)境下和業(yè)務(wù)高峰時(shí)進(jìn)行巨缘，以免影響系統(tǒng)的性能。
單表
單表指所有的分片數(shù)據(jù)源中僅唯一存在的表（沒有分片的表）采呐，適用于數(shù)據(jù)量不大且無需分片的表若锁。
如果一張表的數(shù)據(jù)量預(yù)估在千萬級(jí)別，且沒有與其他拆分表進(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í)，需要通過解析SQL語句中指定的分片鍵來計(jì)算數(shù)據(jù)應(yīng)該落在哪個(gè)分片中。以表中order_no字段為例木张，我們可以通過對(duì)其取模運(yùn)算（比如 order_no % 2）來得到分片編號(hào)众辨，然后根據(jù)分片編號(hào)分配數(shù)據(jù)到對(duì)應(yīng)的數(shù)據(jù)庫實(shí)例（比如 DB_1 和 DB_2）。拆分表也是同理計(jì)算舷礼。
在這個(gè)過程中鹃彻，order_no 就是 t_order 表的分片鍵。也就是說妻献，每一條訂單數(shù)據(jù)的 order_no 值決定了它應(yīng)該存放的數(shù)據(jù)庫實(shí)例和表蛛株。選擇一個(gè)適合作為分片鍵的字段可以更好地利用水平分片帶來的性能提升。
[圖片上傳失敗...(image-7cc0c1-1684122255127)]
這樣同一個(gè)訂單的相關(guān)數(shù)據(jù)就會(huì)落在同一個(gè)數(shù)據(jù)庫育拨、表中谨履，查詢訂單時(shí)同理計(jì)算，就可直接定位數(shù)據(jù)位置熬丧，大幅提升數(shù)據(jù)檢索的性能笋粟，避免了全庫表掃描。
不僅如此 ShardingSphere 還支持根據(jù)多個(gè)字段作為分片健進(jìn)行分片析蝴，這個(gè)在后續(xù)對(duì)應(yīng)章節(jié)中會(huì)詳細(xì)講害捕。
分片策略
分片策略來指定使用哪種分片算法、選擇哪個(gè)字段作為分片鍵以及如何將數(shù)據(jù)分配到不同的節(jié)點(diǎn)上闷畸。
分片策略是由分片算法和分片健組合而成尝盼，分片策略中可以使用多種分片算法和對(duì)多個(gè)分片鍵進(jìn)行運(yùn)算。
[圖片上傳失敗...(image-abfc17-1684122255127)]
分庫佑菩、分表的分片策略配置是相對(duì)獨(dú)立的盾沫，可以各自使用不同的策略與算法，每種策略中可以是多個(gè)分片算法的組合殿漠，每個(gè)分片算法可以對(duì)多個(gè)分片健做邏輯判斷赴精。
分片算法
分片算法則是用于對(duì)分片鍵進(jìn)行運(yùn)算，將數(shù)據(jù)劃分到具體的數(shù)據(jù)節(jié)點(diǎn)中绞幌。
常用的分片算法有很多：
- 哈希分片：根據(jù)分片鍵的哈希值來決定數(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í)間或者地理位置來進(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ù)開發(fā)中分片的邏輯要復(fù)雜的多械蹋，不同的算法適用于不同的場(chǎng)景和需求出皇，需要根據(jù)實(shí)際情況進(jìn)行選擇和調(diào)整。
綁定表
綁定表是那些具有相同分片規(guī)則的一組分片表哗戈，由于分片規(guī)則一致所產(chǎn)生的的數(shù)據(jù)落地位置相同郊艘，在JOIN聯(lián)合查詢時(shí)能有效避免跨庫操作。
比如：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)或跨庫關(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ì)全庫表查詢，出現(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
[圖片上傳失敗...(image-b57be0-1684122255127)]
而配置綁定表關(guān)系后再進(jìn)行關(guān)聯(lián)查詢時(shí)痒筒，分片規(guī)則一致產(chǎn)生的數(shù)據(jù)就會(huì)落到同一個(gè)庫表中宰闰，那么只需在當(dāng)前庫中 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
[圖片上傳失敗...(image-1ff8a4-1684122255127)]
注意：在關(guān)聯(lián)查詢時(shí)
t_order它作為整個(gè)聯(lián)合查詢的主表簿透。 所有相關(guān)的路由計(jì)算都只使用主表的策略移袍，t_order_item表的分片相關(guān)的計(jì)算也會(huì)使用t_order的條件，所以要保證綁定表之間的分片鍵要完全相同老充。
SQL 解析
分庫分表后在應(yīng)用層面執(zhí)行一條 SQL 語句時(shí)葡盗，通常需要經(jīng)過以下六個(gè)步驟：SQL 解析 -> 執(zhí)?器優(yōu)化 -> SQL 路由 -> SQL 改寫 -> SQL 執(zhí)? -> 結(jié)果歸并 。
[圖片上傳失敗...(image-acd764-1684122255127)]
SQL解析過程分為詞法解析和語法解析兩步啡浊，比如下邊查詢用戶訂單的SQL觅够，先用詞法解析將這條SQL拆解成不可再分的原子單元。在根據(jù)不同數(shù)據(jù)庫方言所提供的字典巷嚣，將這些單元?dú)w類為關(guān)鍵字喘先，表達(dá)式，變量或者操作符等類型廷粒。
SELECT order_no FROM t_order where order_status > 0 and user_id = 10086
接著語法解析會(huì)將拆分后的SQL關(guān)鍵字轉(zhuǎn)換為抽象語法樹窘拯，通過對(duì)抽象語法樹遍歷红且，提煉出分片所需的上下文，上下文包含查詢字段信息（Field）涤姊、表信息（Table）暇番、查詢條件（Condition）、排序信息（Order By）思喊、分組信息（Group By）以及分頁信息（Limit）等壁酬，并標(biāo)記出 SQL中有可能需要改寫的位置。
[圖片上傳失敗...(image-b665b0-1684122255127)]
執(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 路由
通過上邊的SQL解析得到了分片上下文數(shù)據(jù)，在匹配用戶配置的分片策略和算法诬留，就可以運(yùn)算生成路由路徑斜纪，將 SQL 語句路由到相應(yīng)的數(shù)據(jù)節(jié)點(diǎn)上。
簡單點(diǎn)理解就是拿到分片策略中配置的分片鍵等信息文兑，在從SQL解析結(jié)果中找到對(duì)應(yīng)分片鍵字段的值盒刚，計(jì)算出 SQL該在哪個(gè)庫的哪個(gè)表中執(zhí)行，SQL路由又根據(jù)有無分片健分為 分片路由 和 廣播路由绿贞。
[圖片上傳失敗...(image-e0182f-1684122255127)]
有分?鍵的路由叫分片路由因块，細(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é)果將落?單庫（表）吩愧，當(dāng)分?運(yùn)算符是BETWEEN 或IN 等范圍時(shí)，路由結(jié)果則不?定落?唯?的庫（表）增显，因此?條邏輯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路由到指定?庫、表的一種分?方式同云，而且直接路由可以?于分?鍵不在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
無分?鍵的路由又叫做廣播路由届垫，可以劃分為全庫表路由释液、全庫路由、 全實(shí)例路由装处、單播路由和阻斷路由這 5種類型误债。
全庫表路由
全庫表路由針對(duì)的是數(shù)據(jù)庫 DQL和 DML，以及 DDL等操作妄迁，當(dāng)我們執(zhí)行一條邏輯表 t_order SQL時(shí)寝蹈，在所有分片庫中對(duì)應(yīng)的真實(shí)表 t_order_0 ··· t_order_n 內(nèi)逐一執(zhí)行。
全庫路由
全庫路由主要是對(duì)數(shù)據(jù)庫層面的操作登淘，比如數(shù)據(jù)庫 SET 類型的數(shù)據(jù)庫管理命令箫老，以及 TCL 這樣的事務(wù)控制語句。
對(duì)邏輯庫設(shè)置 autocommit 屬性后黔州，所有對(duì)應(yīng)的真實(shí)庫中都執(zhí)行該命令耍鬓。
SET autocommit=0;
全實(shí)例路由
全實(shí)例路由是針對(duì)數(shù)據(jù)庫實(shí)例的 DCL 操作（設(shè)置或更改數(shù)據(jù)庫用戶或角色權(quán)限），比如：創(chuàng)建一個(gè)用戶 order 流妻，這個(gè)命令將在所有的真實(shí)庫實(shí)例中執(zhí)行牲蜀，以此確保 order 用戶可以正常訪問每一個(gè)數(shù)據(jù)庫實(shí)例。
CREATE USER order@127.0.0.1 identified BY '程序員小富';
單播路由
單播路由用來獲取某一真實(shí)表信息绅这，比如獲得表的描述信息：
DESCRIBE t_order;
t_order 的真實(shí)表是 t_order_0 ···· t_order_n涣达，他們的描述結(jié)構(gòu)相完全同，我們只需在任意的真實(shí)表執(zhí)行一次就可以证薇。
阻斷路由
?來屏蔽SQL對(duì)數(shù)據(jù)庫的操作度苔，例如：
USE order_db;
這個(gè)命令不會(huì)在真實(shí)數(shù)據(jù)庫中執(zhí)?，因?yàn)?ShardingSphere 采?的是邏輯 Schema（數(shù)據(jù)庫的組織和結(jié)構(gòu)） ?式棕叫，所以無需將切換數(shù)據(jù)庫的命令發(fā)送?真實(shí)數(shù)據(jù)庫中。
SQL 改寫
SQL經(jīng)過解析奕删、優(yōu)化俺泣、路由后已經(jīng)明確分片具體的落地執(zhí)行的位置，接著就要將基于邏輯表開發(fā)的SQL改寫成可以在真實(shí)數(shù)據(jù)庫中可以正確執(zhí)行的語句完残。比如查詢 t_order 訂單表伏钠，我們實(shí)際開發(fā)中 SQL是按邏輯表 t_order 寫的。
SELECT * FROM t_order
這時(shí)需要將分表配置中的邏輯表名稱改寫為路由之后所獲取的真實(shí)表名稱谨设。
SELECT * FROM t_order_n
SQL執(zhí)?
將路由和改寫后的真實(shí) SQL 安全且高效發(fā)送到底層數(shù)據(jù)源執(zhí)行熟掂。但這個(gè)過程并不能將 SQL 一股腦的通過 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中的排序指厌、分組、分頁和聚合等語法踊跟，均是在歸并后的結(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ù)來說也就沒意義了袭异。
[圖片上傳失敗...(image-69ccd0-1684122255127)]
盡管可通過設(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ù)脫敏
分庫分表數(shù)據(jù)脫敏是一種有效的數(shù)據(jù)保護(hù)措施细睡，可以確保敏感數(shù)據(jù)的機(jī)密性和安全性谷羞，減少數(shù)據(jù)泄露的風(fēng)險(xiǎn)。
比如溜徙，我們?cè)诜謳旆直頃r(shí)可以指定表的哪些字段為脫敏列湃缎，并設(shè)置對(duì)應(yīng)的脫敏算法，在數(shù)據(jù)分片時(shí)解析到執(zhí)行SQL中有待脫敏字段蠢壹，會(huì)直接將字段值脫敏后的寫入庫表內(nèi)嗓违。
對(duì)于用戶的個(gè)人信息，如姓名图贸、地址和電話號(hào)碼等蹂季，可以通過加密、隨機(jī)化或替換成偽隨機(jī)數(shù)據(jù)的方式進(jìn)行脫敏疏日，以確保用戶的隱私得到保護(hù)偿洁。
大家可以參考我之前發(fā)布的這篇文章 大廠也在用的 6種 數(shù)據(jù)脫敏方案
分布式事務(wù)
分布式事務(wù)的核心問題是如何實(shí)現(xiàn)跨多個(gè)數(shù)據(jù)源的原子性操作。
由于不同的服務(wù)通常會(huì)使用不同的數(shù)據(jù)源來存儲(chǔ)和管理數(shù)據(jù)沟优，因此涕滋，跨數(shù)據(jù)源的操作可能會(huì)導(dǎo)致數(shù)據(jù)不一致性或丟失的風(fēng)險(xiǎn)。因此挠阁，保證分布式事務(wù)的一致性是非常重要的宾肺。
以訂單系統(tǒng)為例溯饵，它需要調(diào)用支付系統(tǒng)、庫存系統(tǒng)爱榕、積分系統(tǒng)等多個(gè)系統(tǒng)瓣喊，而每個(gè)系統(tǒng)都維護(hù)自己的數(shù)據(jù)庫實(shí)例，系統(tǒng)間通過API接口交換數(shù)據(jù)黔酥。
[圖片上傳失敗...(image-70ea2d-1684122255127)]
為了保證下單后多個(gè)系統(tǒng)同時(shí)調(diào)用成功藻三，可以使用強(qiáng)一致性事務(wù)的XA協(xié)議，或者柔性事務(wù)的代表工具Seata跪者，來實(shí)現(xiàn)分布式事務(wù)的一致性棵帽。這些工具可以幫助開發(fā)人員簡化分布式事務(wù)的實(shí)現(xiàn)，減少錯(cuò)誤和漏洞的出現(xiàn)渣玲，提高系統(tǒng)的穩(wěn)定性和可靠性逗概。
經(jīng)過分庫分表之后，問題的難度進(jìn)一步提升忘衍。自身訂單服務(wù)逾苫，也需要處理跨數(shù)據(jù)源的操作。這樣一來枚钓，系統(tǒng)的復(fù)雜度顯著增加铅搓。因此，不到萬不得已的情況下搀捷，最好避免采用分庫分表的解決方案星掰。
[圖片上傳失敗...(image-b9fc6-1684122255127)]
關(guān)于分布式事務(wù)詳細(xì)的介紹，大家可以參考我之前發(fā)布的這篇文章 對(duì)比 5 種分布式事務(wù)方案嫩舟，還是寵幸了阿里的 Seata（原理 + 實(shí)戰(zhàn)）
數(shù)據(jù)遷移
分庫分表后還有個(gè)讓人頭疼的問題氢烘，那就是數(shù)據(jù)遷移，為了不影響現(xiàn)有的業(yè)務(wù)系統(tǒng)家厌，通常會(huì)新建數(shù)據(jù)庫集群遷移數(shù)據(jù)播玖。將數(shù)據(jù)從舊集群的數(shù)據(jù)庫、表遷移到新集群的分庫饭于、分表中蜀踏。這是一個(gè)比較復(fù)雜的過程，在遷移過程中需要考慮數(shù)據(jù)量镰绎、數(shù)據(jù)一致性脓斩、遷移速度等諸多因素木西。
遷移主要針對(duì) 存量數(shù)據(jù) 和 增量數(shù)據(jù) 的處理畴栖，存量數(shù)據(jù)指舊數(shù)據(jù)源中已經(jīng)存在且有價(jià)值的歷史數(shù)據(jù)，增量數(shù)據(jù)指當(dāng)下持續(xù)增長以及未來產(chǎn)生的業(yè)務(wù)數(shù)據(jù)八千。
存量數(shù)據(jù)可以采用定時(shí)吗讶、分批次的遷移燎猛，遷移過程可能會(huì)持續(xù)幾天。
增量數(shù)據(jù)可以采用新照皆、舊數(shù)據(jù)庫集群雙寫模式重绷。待數(shù)據(jù)遷移完畢，業(yè)務(wù)驗(yàn)證了數(shù)據(jù)一致性膜毁，應(yīng)用直接切換數(shù)據(jù)源即可昭卓。
后續(xù)我們會(huì)結(jié)合三方工具，來演示遷移的過程瘟滨。
影子庫
什么是影子庫（Shadow Table）候醒？
影子庫是一個(gè)與生產(chǎn)環(huán)境數(shù)據(jù)庫結(jié)構(gòu)完全相同的實(shí)例，它存在的意義是為了在不影響線上系統(tǒng)的情況下杂瘸，驗(yàn)證數(shù)據(jù)庫遷移或者其他數(shù)據(jù)庫變更操作的正確性倒淫，以及全鏈路壓測(cè)。影子庫中存儲(chǔ)的數(shù)據(jù)是從生產(chǎn)環(huán)境中定期復(fù)制過來的败玉，但是它不對(duì)線上業(yè)務(wù)產(chǎn)生任何影響敌土，僅用于測(cè)試，驗(yàn)證和調(diào)試运翼。
[圖片上傳失敗...(image-197614-1684122255127)]
在進(jìn)行數(shù)據(jù)庫升級(jí)返干、版本變更、參數(shù)調(diào)優(yōu)等操作前南蹂，通過在影子庫上模擬這些操作犬金，可以發(fā)現(xiàn)潛在的問題，因?yàn)闇y(cè)試環(huán)境的數(shù)據(jù)是不可靠的六剥。
在使用影子庫時(shí)晚顷，需要遵循以下幾個(gè)原則：
與生產(chǎn)環(huán)境數(shù)據(jù)庫的結(jié)構(gòu)應(yīng)該完全一致，包括表結(jié)構(gòu)疗疟、索引该默、約束等；
數(shù)據(jù)要與生產(chǎn)環(huán)境保持一致策彤，可以通過定期同步方式實(shí)現(xiàn)栓袖；
讀寫操作不會(huì)影響生產(chǎn)環(huán)境，一般情況下應(yīng)該禁止在影子庫上執(zhí)行更新店诗、刪除等操作裹刮；
由于影子庫的數(shù)據(jù)特點(diǎn)，訪問權(quán)限應(yīng)該嚴(yán)格控制庞瘸，只允許授權(quán)人員進(jìn)行訪問和操作捧弃；
總結(jié)
本文介紹了關(guān)于分庫分表架構(gòu)的21個(gè)通用概念，對(duì)有一定的了解之后，接下來我們將進(jìn)入更深度的內(nèi)容违霞，包括讀寫分離嘴办、數(shù)據(jù)脫敏、分布式主鍵买鸽、分布式事務(wù)涧郊、配置中心、注冊(cè)中心眼五、Proxy服務(wù)等實(shí)戰(zhàn)案例的講解和源碼分析妆艘。
下期文章將是《分庫分表ShardingSphere5.x原理與實(shí)戰(zhàn)》系列的第三篇，《快速實(shí)現(xiàn)分庫分表的 2種方式》看幼。
我是小富双仍，下期見～
