第一次接觸ShardingProxy的人通常是被一句話吸引過(guò)來(lái)的它能把你拆散在多個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)上的表重新拼成一個(gè)邏輯上的“普通數(shù)據(jù)庫(kù)”業(yè)務(wù)方不用改一行SQL就能繼續(xù)按單庫(kù)的習(xí)慣去讀寫(xiě)。做數(shù)據(jù)庫(kù)中間件這行久了會(huì)發(fā)現(xiàn)很多團(tuán)隊(duì)從單庫(kù)單表演進(jìn)到分庫(kù)分表后卡住的往往不是拆分規(guī)則本身而是“怎么讓一百多個(gè)應(yīng)用實(shí)例無(wú)縫切換到新架構(gòu)”。ShardingProxy正好是解決這個(gè)接入問(wèn)題的關(guān)鍵一環(huán)。這篇文章我從頭講透它的原理、配置、實(shí)戰(zhàn)部署和排坑經(jīng)驗(yàn)全部基于真實(shí)環(huán)境踩過(guò)的坑總結(jié)出來(lái)適合正在做分庫(kù)分表架構(gòu)選型的開(kāi)發(fā)、DBA以及被拆分后的查詢路由搞得頭疼的同學(xué)參考。1. 先搞清楚ShardingProxy到底解決了什么問(wèn)題1.1 從單庫(kù)單表到分庫(kù)分表問(wèn)題從哪來(lái)先聊一個(gè)最常見(jiàn)的演進(jìn)路徑。系統(tǒng)剛開(kāi)始上線時(shí)一張訂單表就夠用后來(lái)業(yè)務(wù)量漲了單表千萬(wàn)級(jí)、上億級(jí)索引深了寫(xiě)并發(fā)高了數(shù)據(jù)庫(kù)的CPU和IO開(kāi)始報(bào)警。于是DBA把訂單表按時(shí)間或者按訂單號(hào)拆成多張表再往后單庫(kù)也扛不住干脆把不同的表散到多個(gè)數(shù)據(jù)庫(kù)實(shí)例上。這個(gè)動(dòng)作做完存儲(chǔ)壓力確實(shí)緩解了但應(yīng)用端的麻煩才剛剛開(kāi)始原來(lái)一條INSERT語(yǔ)句現(xiàn)在要自己算該去哪張表原來(lái)一個(gè)JOIN要跨多個(gè)庫(kù)手工拼數(shù)據(jù)原來(lái)一個(gè)事務(wù)現(xiàn)在要面對(duì)跨庫(kù)事務(wù)的難題。如果這些邏輯全部寫(xiě)死在業(yè)務(wù)代碼里那每接入一個(gè)需求都要重新改一遍SQL拼接邏輯而且不同服務(wù)的分片規(guī)則不一致之后團(tuán)隊(duì)維護(hù)成本會(huì)迅速失控。市面上解決這個(gè)問(wèn)題的方式無(wú)非三種第一種是在應(yīng)用層封裝數(shù)據(jù)訪問(wèn)層把分片路由做在代碼里第二種是引入數(shù)據(jù)庫(kù)中間件讓SQL先經(jīng)過(guò)中間件再路由到后端節(jié)點(diǎn)第三種是把整個(gè)數(shù)據(jù)庫(kù)直接換成一個(gè)原生分布式數(shù)據(jù)庫(kù)。ShardingProxy屬于第二種也是我這些年見(jiàn)過(guò)在兼容性、改造成本和穩(wěn)定性之間平衡得比較好的方案。1.2 ShardingProxy與ShardingSphere生態(tài)的關(guān)系很多人會(huì)把ShardingSphere和ShardingProxy搞混。簡(jiǎn)單說(shuō)ShardingSphere是一套完整的數(shù)據(jù)庫(kù)生態(tài)下面兩條核心產(chǎn)品線一條是ShardingJDBC做成輕量級(jí)Java客戶端以jar包形式嵌入應(yīng)用另一條就是ShardingProxy做成獨(dú)立部署的中間件服務(wù)對(duì)客戶端而言它就是一個(gè)標(biāo)準(zhǔn)數(shù)據(jù)庫(kù)服務(wù)端。兩者的定位差異很直觀。ShardingJDBC像是給每個(gè)應(yīng)用請(qǐng)了一位貼身管家它跟著應(yīng)用進(jìn)程走路由規(guī)則直接內(nèi)置在JVM里性能損耗低但每個(gè)應(yīng)用都要引入對(duì)應(yīng)的依賴、配置分片規(guī)則。ShardingProxy則像是樓下的前臺(tái)總機(jī)你只管把SQL交給它它負(fù)責(zé)轉(zhuǎn)給背后各個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)業(yè)務(wù)側(cè)完全感知不到分庫(kù)分表的存在。這種差異決定了它們的適用場(chǎng)景完全不同。新寫(xiě)一個(gè)微服務(wù)明確規(guī)定從零開(kāi)始我傾向于ShardingJDBC因?yàn)榍秩肟煽亍㈡溌范痰绻拥氖谴媪肯到y(tǒng)幾十個(gè)服務(wù)每個(gè)都改JDBC連接方式成本太高或者對(duì)接的是異構(gòu)語(yǔ)言比如PHP、Python、Go沒(méi)辦法直接復(fù)用Java端的ShardingJDBC那ShardingProxy幾乎是唯一現(xiàn)實(shí)的選擇。我實(shí)際遇到過(guò)幾個(gè)項(xiàng)目數(shù)據(jù)庫(kù)表都拆好了但業(yè)務(wù)團(tuán)隊(duì)有Java有Go還有寫(xiě)存儲(chǔ)過(guò)程的最后統(tǒng)一收口到ShardingProxy所有客戶端只改一個(gè)連接地址問(wèn)題立刻變簡(jiǎn)單。1.3 為什么選Proxy而不是JDBC模式每次做技術(shù)選型團(tuán)隊(duì)里都會(huì)有人問(wèn)既然ShardingJDBC性能更好為什么還要引入一個(gè)單獨(dú)的中間層這個(gè)問(wèn)題我一般從三個(gè)維度來(lái)回答。從運(yùn)維視角看ShardingJDBC的分片規(guī)則散落在每個(gè)應(yīng)用進(jìn)程里規(guī)則要調(diào)整時(shí)必須發(fā)版重啟幾十上百個(gè)實(shí)例同時(shí)變更是個(gè)災(zāi)難ShardingProxy把規(guī)則集中在服務(wù)端DBA改配置文件后重啟單點(diǎn)即可控制力強(qiáng)得多。從團(tuán)隊(duì)協(xié)作看分片規(guī)則本質(zhì)上是一種“數(shù)據(jù)基礎(chǔ)設(shè)施約定”放在Proxy層由DBA或基礎(chǔ)架構(gòu)組統(tǒng)一維護(hù)比指望每個(gè)業(yè)務(wù)開(kāi)發(fā)都理解取模算法要可靠。從生態(tài)兼容看Proxy透明地實(shí)現(xiàn)了MySQL和PostgreSQL網(wǎng)絡(luò)協(xié)議意味著任何能用這兩種協(xié)議連接數(shù)據(jù)庫(kù)的客戶端工具、監(jiān)控系統(tǒng)、BI軟件都能直接復(fù)用。當(dāng)然Proxy也有代價(jià)。多一跳網(wǎng)絡(luò)就意味著額外的幾毫秒延遲加上中間件的CPU和內(nèi)存開(kāi)銷對(duì)延遲極端敏感的純交易場(chǎng)景需要壓測(cè)確認(rèn)。我的真實(shí)感受是如果你做的是內(nèi)部系統(tǒng)、報(bào)表平臺(tái)、ToB應(yīng)用或者是存量系統(tǒng)改造Proxy的優(yōu)勢(shì)遠(yuǎn)大于這點(diǎn)性能損耗如果每個(gè)接口對(duì)單次查詢延遲都有硬性要求且團(tuán)隊(duì)全是Java且愿意接受強(qiáng)侵入改造再認(rèn)真考慮ShardingJDBC。沒(méi)有銀彈適合的才是對(duì)的。2. 部署前的關(guān)鍵概念邏輯庫(kù)、物理庫(kù)、綁定表與分片算法2.1 邏輯庫(kù)、邏輯表與物理節(jié)點(diǎn)剛接觸ShardingProxy時(shí)最容易糊涂的就是配置里那一堆“邏輯”和“物理”的概念。我用最簡(jiǎn)單的話解釋邏輯庫(kù)是客戶端看到的庫(kù)邏輯表是客戶端看到的表物理庫(kù)和物理表才是真正存在數(shù)據(jù)庫(kù)里的東西。比如你在Proxy里定義一個(gè)邏輯庫(kù)叫sharding_db客戶端執(zhí)行USE sharding_db然后查詢SELECT * FROM t_order WHERE order_id 1001。Proxy拿到這條SQL后先根據(jù)order_id的分片算法算出這條數(shù)據(jù)在物理表t_order_1上再根據(jù)庫(kù)分片規(guī)則算出它在物理庫(kù)ds0上于是真實(shí)執(zhí)行的是SELECT * FROM ds0.t_order_1 WHERE order_id 1001。整個(gè)過(guò)程對(duì)客戶端完全透明。這個(gè)“邏輯和物理分離”的設(shè)計(jì)價(jià)值在于它解耦了業(yè)務(wù)代碼和存儲(chǔ)拓?fù)?。今天訂單表拆?張明天拆成8張只需要改Proxy的配置業(yè)務(wù)SQL里的表名永遠(yuǎn)叫t_order。我在項(xiàng)目里經(jīng)常開(kāi)玩笑說(shuō)分片規(guī)則是DBA和中間件之間的秘密業(yè)務(wù)開(kāi)發(fā)不該也不需要知道。配置里的actualDataNodes就是用來(lái)告訴Proxy“這實(shí)這些物理表散落在哪里”的字段格式是ds0.t_order_0, ds0.t_order_1...也可以用行表達(dá)式簡(jiǎn)寫(xiě)成ds$-{0..1}.t_order_$-{0..3}。2.2 分片策略標(biāo)準(zhǔn)、復(fù)合與行表達(dá)式的實(shí)際使用分片策略是整個(gè)配置的重頭戲它決定了SQL會(huì)被路由到哪幾張物理表。常見(jiàn)的類型有三種標(biāo)準(zhǔn)分片、復(fù)合分片和HINT分片。標(biāo)準(zhǔn)分片是使用最多的場(chǎng)景它針對(duì)一個(gè)分片鍵做路由比如order_id對(duì)4取?；蛘甙丛路莘直怼Ｅ渲脮r(shí)通過(guò)shardingColumn指定分片鍵在shardingAlgorithms里定義算法類型INLINE是最常用的行表達(dá)式算法比如t_order_$-{order_id % 4}表達(dá)的就是按訂單號(hào)對(duì)4取模落到4張表中。復(fù)合分片適合需要用兩個(gè)字段一起決定路由的場(chǎng)景比如先按用戶ID分庫(kù)再按訂單時(shí)間分表這時(shí)候需要實(shí)現(xiàn)一個(gè)自定義的復(fù)合算法類。HINT分片則是在SQL里完全不帶分片鍵時(shí)強(qiáng)制指定走哪個(gè)節(jié)點(diǎn)適合一些特殊的管理查詢。選算法時(shí)我的建議是能用取模就用取模模數(shù)按未來(lái)兩年數(shù)據(jù)增長(zhǎng)預(yù)估再留出一倍余量。按時(shí)間分片適合歸檔類數(shù)據(jù)比如按月分表然后定期把歷史表遷移到冷存儲(chǔ)按用戶維度分片適合C端應(yīng)用因?yàn)榻^大部分查詢都是圍繞某個(gè)用戶展開(kāi)的。記住一個(gè)要點(diǎn)分片鍵的選擇本質(zhì)上是和業(yè)務(wù)查詢模式強(qiáng)綁定的不是DBA隨便拍腦袋定的最忌諱的就是選了一個(gè)業(yè)務(wù)上根本不作為查詢條件的字段結(jié)果每條SQL都變成全路由廣播。2.3 綁定表與廣播表被低估的兩個(gè)配置分庫(kù)分表后跨節(jié)點(diǎn)JOIN是最讓人頭疼的問(wèn)題。比如t_order和t_order_item都按order_id分片如果分片規(guī)則完全一致那么應(yīng)該把兩個(gè)表配置成綁定表。綁定表的意思是兩個(gè)表在路由時(shí)會(huì)強(qiáng)制使用相同的分片路由結(jié)果t_order查了ds0.t_order_1t_order_item也只會(huì)去ds0.t_order_item_1查JOIN變成了單庫(kù)內(nèi)的普通JOIN不需要中間件做內(nèi)存聚合。廣播表則適合那些數(shù)據(jù)量很小、幾乎每個(gè)分片節(jié)點(diǎn)都需要用到的表比如字典表、配置表、省份城市表。這類表在每個(gè)物理庫(kù)里都存一份全量數(shù)據(jù)Proxy在寫(xiě)入時(shí)會(huì)自動(dòng)廣播到所有節(jié)點(diǎn)查詢時(shí)任選一個(gè)節(jié)點(diǎn)即可。配置方式是在rules里用!BROADCAST聲明兩張表之后應(yīng)用完全感知不到它的存在。這兩個(gè)配置看起來(lái)不起眼但在實(shí)際并發(fā)場(chǎng)景里作用極大。我看到過(guò)太多團(tuán)隊(duì)沒(méi)配綁定表結(jié)果一次本來(lái)很簡(jiǎn)單的聯(lián)表查詢被拆成幾十次子查詢中間件內(nèi)存被打爆然后懷疑Proxy性能不行的案例。歸根結(jié)底中間件不是萬(wàn)能加速器它只是在SQL路由上幫你做了正確的事數(shù)據(jù)分布設(shè)計(jì)不合理再好的中間件也救不回來(lái)。3. 實(shí)戰(zhàn)部署從下載到跑通第一條分片查詢3.1 環(huán)境準(zhǔn)備與安裝包選擇說(shuō)再多原理不如親手跑一次。這里我用一個(gè)模擬訂單場(chǎng)景來(lái)做實(shí)戰(zhàn)演示兩個(gè)物理庫(kù)ds0和ds1每個(gè)庫(kù)里有4張訂單表t_order_0到t_order_3通過(guò)Proxy對(duì)外暴露成一個(gè)邏輯庫(kù)sharding_db。操作系統(tǒng)準(zhǔn)備一臺(tái)Linux我這邊測(cè)試用的是CentOS 7其他主流發(fā)行版沒(méi)區(qū)別提前裝好JDK 8。因?yàn)镾hardingProxy本身是JVM進(jìn)程所有數(shù)據(jù)庫(kù)驅(qū)動(dòng)已經(jīng)內(nèi)置不需要額外裝客戶端。從ShardingSphere官網(wǎng)下載頁(yè)找最新穩(wěn)定版二進(jìn)制包如果本地沒(méi)有就直接用內(nèi)網(wǎng)鏡像包名大致是apache-shardingsphere-xxx-bin.tar.gz。這里提供一個(gè)選版本的原則不追求最新選已經(jīng)發(fā)布超過(guò)半年的穩(wěn)定版本社區(qū)的issue和坑基本都被踩平了文檔也最齊。解壓后目錄結(jié)構(gòu)很清晰bin目錄是啟停腳本conf目錄放所有配置lib目錄是各種依賴jar包。整個(gè)中間件的設(shè)計(jì)思路是“配置驅(qū)動(dòng)”你要改的一切都在conf下完成。我第一次部署時(shí)最不適應(yīng)的一點(diǎn)是它沒(méi)有一個(gè)交互式控制臺(tái)讓你敲命令建庫(kù)建表一切都要通過(guò)YAML配置來(lái)聲明改完重啟進(jìn)程生效。理解了這個(gè)模式之后反而覺(jué)得它適合自動(dòng)化運(yùn)維配完直接走配置管理流程發(fā)布即可。3.2 配置server.yaml賬號(hào)權(quán)限與全局參數(shù)conf/server.yaml是Proxy自身的基礎(chǔ)配置相當(dāng)于這個(gè)“虛擬數(shù)據(jù)庫(kù)”的全局總控。最核心的是用戶認(rèn)證信息這里決定了客戶端用哪個(gè)賬號(hào)密碼能連上來(lái)。rules: - !AUTHORITY users: - root%:root - sharding%:sharding provider: type: ALL_PERMISSIONS props: max-connections-size-per-query: 1 sql-show: true check-table-metadata-enabled: falseroot%:root的意思是用戶名root允許任意主機(jī)連接密碼是root。%表示來(lái)源IP不限生產(chǎn)環(huán)境建議改成具體網(wǎng)段。sql-show: true會(huì)把每條經(jīng)過(guò)Proxy的SQL打印到日志里排障時(shí)非常好用但生產(chǎn)環(huán)境建議關(guān)掉否則日志量會(huì)非?？捎^。max-connections-size-per-query表示一次查詢最多允許在多少物理庫(kù)上同時(shí)執(zhí)行1表示每個(gè)查詢路由到單庫(kù)執(zhí)行如果路由到多庫(kù)則串行這個(gè)參數(shù)直接關(guān)系到并發(fā)和連接占用后面性能章節(jié)再展開(kāi)講。需要注意一個(gè)容易踩的坑如果下面想配合讀寫(xiě)分離還需要在server.yaml里配置!TRANSACTION類型的全局事務(wù)規(guī)則如果不想用分布式事務(wù)保持默認(rèn)即可。啟動(dòng)前可以先用bin/start.bat這個(gè)腳本在Windows環(huán)境做快速驗(yàn)證線上還是用bin/start.sh。3.3 配置config-sharding.yaml定義數(shù)據(jù)源和分片規(guī)則重頭戲在conf/config-sharding.yaml這里要定義邏輯庫(kù)、物理數(shù)據(jù)源、分片規(guī)則三大部分。先看數(shù)據(jù)源配置databaseName: sharding_db dataSources: ds0: url: jdbc:mysql://127.0.0.1:3306/demo_ds0?serverTimezoneUTCuseSSLfalse username: root password: root ds1: url: jdbc:mysql://127.0.0.1:3307/demo_ds1?serverTimezoneUTCuseSSLfalse username: root password: root注意兩個(gè)細(xì)節(jié)。一是連接串里的serverTimezoneUTC必填否則連接MySQL 8.x的時(shí)候會(huì)報(bào)時(shí)區(qū)錯(cuò)誤二是useSSLfalse內(nèi)網(wǎng)環(huán)境沒(méi)必要做SSL握手加了這個(gè)參數(shù)能省掉一層握手耗時(shí)。模擬環(huán)境里我會(huì)把ds0和ds1配置成兩個(gè)真正的MySQL實(shí)例如果只有一臺(tái)機(jī)器可以用兩個(gè)不同端口模擬。接著是分片規(guī)則這是整個(gè)配置的靈魂rules: - !SHARDING tables: t_order: actualDataNodes: ds$-{0..1}.t_order_$-{0..3} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_inline keyGenerateStrategy: column: order_id keyGeneratorName: snowflake shardingAlgorithms: t_order_inline: type: INLINE props: algorithm-expression: t_order_$-{order_id % 4} ds_inline: type: INLINE props: algorithm-expression: ds$-{user_id % 2} defaultDatabaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: ds_inline這里解釋一下每一行的作用。actualDataNodes聲明了t_order這個(gè)邏輯表對(duì)應(yīng)的物理表位置ds$-{0..1}表示ds0和ds1兩個(gè)庫(kù)t_order_$-{0..3}表示每個(gè)庫(kù)里的4張物理表一共8張表。tableStrategy配置表級(jí)別的分片策略按order_id對(duì)4取模決定數(shù)據(jù)落在哪張物理表。defaultDatabaseStrategy配置庫(kù)級(jí)別的分片策略按user_id對(duì)2取模決定數(shù)據(jù)落在哪個(gè)物理庫(kù)。有個(gè)設(shè)計(jì)細(xì)節(jié)值得留意庫(kù)分片鍵我選了user_id而不是order_id。因?yàn)橛唵螆?chǎng)景里絕大部分查詢都是“查某個(gè)用戶的訂單”用user_id做庫(kù)分片能讓同一用戶的所有訂單都落在同一個(gè)物理庫(kù)后續(xù)查用戶訂單列表時(shí)只需要路由到一個(gè)庫(kù)不需要跨庫(kù)聚合。這是從業(yè)務(wù)查詢模式反推分片鍵的典型案例遠(yuǎn)比“隨便找個(gè)字段取?！币煽?。3.4 啟動(dòng)、建表、驗(yàn)證查詢配置寫(xiě)完后先確認(rèn)兩個(gè)物理庫(kù)里已經(jīng)建好對(duì)應(yīng)的物理表。ShardingProxy不會(huì)幫你自動(dòng)建表需要你提前在ds0和ds1中分別執(zhí)行建表SQL把所有t_order_0到t_order_3都建出來(lái)。很多新手在這里栽跟頭Proxy配置的是8張實(shí)際表結(jié)果物理庫(kù)里只有一張t_order一查就報(bào)“表不存在”。啟動(dòng)進(jìn)程cd /opt/shardingsphere/bin ./start.sh tail -f ../logs/stdout.log看到類似ShardingSphere-Proxy memory mode started successfully的日志說(shuō)明啟動(dòng)成功。默認(rèn)監(jiān)聽(tīng)3307端口這個(gè)設(shè)計(jì)是故意的就是為了避開(kāi)MySQL默認(rèn)的3306端口防止連錯(cuò)。如果用防火墻記得放行3307。然后用任意MySQL客戶端驗(yàn)證mysql -h127.0.0.1 -P3307 -uroot -proot進(jìn)入后執(zhí)行USE sharding_db再執(zhí)行一條插入和一條查詢。如果開(kāi)啟了sql-show你會(huì)在日志里看到Proxy自動(dòng)改寫(xiě)后的SQL比如INSERT INTO t_order ...被改寫(xiě)成對(duì)ds0下的t_order_1執(zhí)行這就是透明路由生效的證據(jù)。我第一次跑通時(shí)最深的感受是從外部看它就像一個(gè)安裝完就能用的MySQL完全不需要業(yè)務(wù)方理解后臺(tái)的復(fù)雜度。這種“低門檻接入”才是Proxy產(chǎn)品設(shè)計(jì)的核心價(jià)值。4. 讀寫(xiě)分離與分布式事務(wù)讓Proxy更貼近生產(chǎn)4.1 讀寫(xiě)分離配置與主從延遲問(wèn)題真實(shí)的業(yè)務(wù)系統(tǒng)基本不會(huì)只用一臺(tái)數(shù)據(jù)庫(kù)主從架構(gòu)是標(biāo)配。ShardingProxy在同一個(gè)配置體系里支持讀寫(xiě)分離。在config-readwrite-splitting.yaml里定義邏輯數(shù)據(jù)源把寫(xiě)庫(kù)和讀庫(kù)的關(guān)系告訴ProxydatabaseName: readwrite_splitting_db dataSources: write_ds: url: jdbc:mysql://127.0.0.1:3306/write_db username: root password: root read_ds_0: url: jdbc:mysql://127.0.0.1:3307/read_db username: root password: root rules: - !READWRITE_SPLITTING dataSources: readwrite_ds: writeDataSourceName: write_ds readDataSourceNames: - read_ds_0 loadBalancerName: round_robin loadBalancers: round_robin: type: ROUND_ROBIN使用的時(shí)候這個(gè)邏輯數(shù)據(jù)源readwrite_ds本身也可以繼續(xù)參與分片配置也就是說(shuō)讀寫(xiě)分離和分庫(kù)分表可以疊加使用。生產(chǎn)環(huán)境中常見(jiàn)的問(wèn)題是“主從延遲”寫(xiě)完主庫(kù)立刻去查數(shù)據(jù)還沒(méi)同步到從庫(kù)讀到舊數(shù)據(jù)。解決方案通常是在Proxy上層加一個(gè)強(qiáng)制路由提示或者業(yè)務(wù)層對(duì)剛寫(xiě)完的數(shù)據(jù)做特殊處理。ShardingProxy可以通過(guò)Slave選主庫(kù)強(qiáng)制走寫(xiě)庫(kù)執(zhí)行具體實(shí)現(xiàn)依賴SQL解析器的注釋透?jìng)髂芰?。我的建議是對(duì)一致性要求極高的場(chǎng)景不要依賴讀寫(xiě)分離走寫(xiě)庫(kù)最穩(wěn)妥報(bào)表、列表這類讀多寫(xiě)少的業(yè)務(wù)才適合把只讀流量打到從庫(kù)。4.2 分布式事務(wù)類型與取舍分庫(kù)分表之后跨庫(kù)事務(wù)是個(gè)繞不開(kāi)的坎。原來(lái)在單庫(kù)里的一條事務(wù)如果涉及到兩個(gè)物理庫(kù)普通的數(shù)據(jù)庫(kù)事務(wù)已經(jīng)無(wú)能為力了。ShardingProxy提供兩種方案XA事務(wù)和Seata柔性事務(wù)。XA是強(qiáng)一致的典型代表它的思路是事務(wù)管理器統(tǒng)一協(xié)調(diào)所有分片節(jié)點(diǎn)先預(yù)提交再統(tǒng)一提交保證要么全成功要么全失敗。配置方式在server.yaml里聲明事務(wù)類型為XA即可。XA的優(yōu)點(diǎn)是對(duì)業(yè)務(wù)透明接入成本低缺點(diǎn)是并發(fā)性能損耗比較大因?yàn)槭聞?wù)期間所有節(jié)點(diǎn)都要持有鎖等待協(xié)調(diào)者決定最終結(jié)果。Seata柔性事務(wù)則走的是最終一致路線業(yè)務(wù)上先做本地事務(wù)通過(guò)undo_log記錄反向操作遇到異常時(shí)反向補(bǔ)償回滾。Seata方案并發(fā)能力更強(qiáng)但需要額外部署Seata服務(wù)端同時(shí)業(yè)務(wù)代碼中需要引入相應(yīng)的注解配合。我個(gè)人的選型經(jīng)驗(yàn)是金融交易、賬戶類、庫(kù)存類這些強(qiáng)一致場(chǎng)景上XA寧可性能差點(diǎn)也不能出錯(cuò)積分、日志、通知這類可以容忍短暫不一致的場(chǎng)景上Seata吞吐量高得多。最理想的情況是盡量從業(yè)務(wù)設(shè)計(jì)上避免跨庫(kù)事務(wù)比如把強(qiáng)關(guān)聯(lián)的表按照相同分片鍵放在同一物理庫(kù)事務(wù)就退化為單庫(kù)事務(wù)這是最高效的“分布式事務(wù)優(yōu)化方案”。4.3 多分片鍵與自定義算法擴(kuò)展標(biāo)準(zhǔn)取模算法覆蓋了大多數(shù)場(chǎng)景但總有些業(yè)務(wù)需要更復(fù)雜的路由邏輯。比如訂單系統(tǒng)一天的數(shù)據(jù)量差異非常大大促期間可能是平時(shí)的幾十倍單純?nèi)∧?huì)導(dǎo)致每個(gè)分片數(shù)據(jù)不均衡。這時(shí)候可以自定義分片算法。ShardingProxy的擴(kuò)展機(jī)制基于SPI要做的是寫(xiě)一個(gè)Java類實(shí)現(xiàn)對(duì)應(yīng)的分片算法接口打成jar包放到lib目錄然后重啟Proxy。比如我可以實(shí)現(xiàn)一個(gè)結(jié)合“日期用戶ID末位”的復(fù)合分片算法每天的流量先按日分表再按用戶取模散到不同庫(kù)既能應(yīng)對(duì)大促擴(kuò)容單日表又能讓單日內(nèi)的數(shù)據(jù)分布均勻。這里要重點(diǎn)提醒自定義算法一旦上線后續(xù)想改路由邏輯會(huì)極其痛苦因?yàn)槔蠑?shù)據(jù)已經(jīng)按照舊規(guī)則分布了。所以自定義算法在正式啟用前務(wù)必做充分的容量估算和回放測(cè)試。任何分片算法上線后都做“只讀增加、不輕易修改”的原則。5. 性能調(diào)優(yōu)與連接管理心得5.1 連接數(shù)與并發(fā)參數(shù)來(lái)自一場(chǎng)壓測(cè)的教訓(xùn)之前幫一個(gè)團(tuán)隊(duì)做過(guò)一次壓測(cè)場(chǎng)景是模擬1000個(gè)并發(fā)用戶同時(shí)查訂單。上線前測(cè)試環(huán)境一切正常一上生產(chǎn)就頻繁報(bào)Too many connections。查下來(lái)才發(fā)現(xiàn)問(wèn)題出在Proxy和后端數(shù)據(jù)庫(kù)的連接數(shù)量匹配上。ShardingProxy本身面向每一個(gè)客戶端連接它還會(huì)根據(jù)SQL路由結(jié)果向后端數(shù)據(jù)庫(kù)發(fā)起連接。假如前端有100個(gè)連接每一條SQL同時(shí)路由到4個(gè)分片那么后端瞬間要建立400個(gè)連接。如果不限制max-connections-size-per-query后端數(shù)據(jù)庫(kù)的連接池直接被擊穿。我建議壓測(cè)前把max-connections-size-per-query設(shè)成1讓每個(gè)查詢路由到多個(gè)分片時(shí)串行執(zhí)行這樣后端連接數(shù)始終被控制在合理范圍。當(dāng)然這會(huì)犧牲一些查詢速度所以這個(gè)參數(shù)應(yīng)該在理解了“并發(fā)查詢數(shù)×單查詢節(jié)點(diǎn)數(shù)”的關(guān)系后根據(jù)后端數(shù)據(jù)庫(kù)能承受的連接總量來(lái)折中設(shè)置。后端MySQL的max_connections也要同步調(diào)大同時(shí)Proxy的JVM堆內(nèi)存建議至少給4-8G具體取決于路由聚合時(shí)的數(shù)據(jù)量。5.2 SQL解析開(kāi)銷與日志陷阱很多人問(wèn)Proxy會(huì)不會(huì)成為性能瓶頸答案是它確實(shí)有開(kāi)銷但比大多數(shù)人想象的小得多。SQL解析、路由計(jì)算、結(jié)果合并這些操作都是在JVM內(nèi)存中完成的單核處理幾萬(wàn)條簡(jiǎn)單SQL沒(méi)什么問(wèn)題。真正的性能殺手有兩個(gè)一個(gè)是大結(jié)果集跨分片合并另一個(gè)是日志。跨分片聚合排序這種SQL比如LIMIT ORDER BYProxy需要把每個(gè)分片查到的數(shù)據(jù)全部拉到中間件內(nèi)存排序后再返回前端。如果單頁(yè)數(shù)據(jù)量太大內(nèi)存會(huì)直接飆高。我遇到過(guò)一個(gè)案例一張表分片后沒(méi)做任何優(yōu)化前端做分頁(yè)查詢每頁(yè)100條但Proxy內(nèi)存持續(xù)不釋放原因是Proxy為了排序要把所有符合條件的數(shù)據(jù)都加載進(jìn)來(lái)。解決辦法是業(yè)務(wù)SQL加上明確的分片鍵條件讓路由收斂到單分片或者用NoSQL思路做寬表冗余避免跨分片聚合。日志問(wèn)題說(shuō)起來(lái)很基礎(chǔ)但很多人會(huì)中招sql-show: true在生產(chǎn)環(huán)境跑了一周發(fā)現(xiàn)日志文件幾個(gè)GB磁盤滿系統(tǒng)卡死。教訓(xùn)就是這個(gè)參數(shù)只適合聯(lián)調(diào)和測(cè)試環(huán)境生產(chǎn)必須關(guān)掉實(shí)在要監(jiān)控可以通過(guò)接入Prometheus和JMX監(jiān)控指標(biāo)來(lái)做。5.3 減少不必要的路由廣播可能遇到的另一個(gè)性能問(wèn)題是SQL里明明帶了分片鍵但Proxy還是做了全路由。有一次排查慢查詢發(fā)現(xiàn)SQL里的分片鍵被包在函數(shù)里了比如WHERE DATE_FORMAT(create_time, %Y-%m-%d) 2024-01-01雖然create_time是分片鍵但經(jīng)過(guò)函數(shù)處理后Proxy無(wú)法提取分片鍵值只能廣播到所有分片。這不是Proxy的bug而是SQL規(guī)范化帶來(lái)的天然限制。想讓路由精準(zhǔn)命中分片SQL里要“裸用”分片鍵中間不要套函數(shù)、不要做類型轉(zhuǎn)換。這是我多年實(shí)戰(zhàn)排障中反復(fù)驗(yàn)證過(guò)的規(guī)律屬于典型的“中間件替你干活但你得遵守它的規(guī)則”。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄6.1 啟動(dòng)失敗類端口、配置、驅(qū)動(dòng)端口被占用是最常見(jiàn)的啟動(dòng)失敗原因。ShardingProxy默認(rèn)3307端口如果被其他進(jìn)程占了啟動(dòng)日志會(huì)報(bào)Address already in use。檢查端口占用后要么殺掉舊進(jìn)程要么修改server.yaml里的port配置。配置語(yǔ)法錯(cuò)誤比端口問(wèn)題更隱蔽。YAML文件對(duì)縮進(jìn)極其敏感尤其是rules節(jié)點(diǎn)下的- !SHARDING這樣的標(biāo)簽少一個(gè)空格都會(huì)導(dǎo)致啟動(dòng)失敗。我習(xí)慣在本地用支持YAML校驗(yàn)的編輯器先格式化一遍再上傳能省下大量排錯(cuò)時(shí)間。MySQL驅(qū)動(dòng)不兼容是另一個(gè)高頻問(wèn)題。如果連的是MySQL 8.xProxy內(nèi)置的驅(qū)動(dòng)版本必須匹配否則會(huì)出現(xiàn)Unable to load authentication plugin caching_sha2_password之類的報(bào)錯(cuò)。解決辦法是把用戶認(rèn)證方式改成mysql_native_password或者升級(jí)Proxy到新版。PostgreSQL場(chǎng)景一般沒(méi)這個(gè)問(wèn)題驅(qū)動(dòng)內(nèi)置得比較完善。6.2 查詢報(bào)錯(cuò)類邏輯庫(kù)不存在、表不存在啟動(dòng)成功后客戶端連不上最常見(jiàn)的原因是連接時(shí)沒(méi)帶邏輯庫(kù)名。如果連接串寫(xiě)的是jdbc:mysql://127.0.0.1:3307/而不是/sharding_dbProxy不知道你要用哪個(gè)邏輯庫(kù)直接報(bào)錯(cuò)。這和原生MySQL不太一樣因?yàn)镻roxy可以同時(shí)掛載多個(gè)邏輯庫(kù)必須明確指定。查詢時(shí)報(bào)“表不存在”先確認(rèn)物理庫(kù)里是否真的建了對(duì)應(yīng)的物理表。Proxy只負(fù)責(zé)路由不負(fù)責(zé)幫你建表。我見(jiàn)過(guò)不止一次配置里寫(xiě)了t_order_$-{0..3}但物理庫(kù)只建了t_order_0一張表業(yè)務(wù)一查就炸。建議寫(xiě)一個(gè)初始化腳本把所有分片表一次性建好順便做一次遍歷校驗(yàn)。6.3 獨(dú)家避坑經(jīng)驗(yàn)配置生命周期與灰度切換最后分享一個(gè)我特別想強(qiáng)調(diào)的經(jīng)驗(yàn)ShardingProxy的配置變更至少在默認(rèn)內(nèi)存模式下是需要重啟進(jìn)程才生效的。重啟意味著所有在線連接會(huì)斷開(kāi)對(duì)生產(chǎn)業(yè)務(wù)來(lái)說(shuō)這是不可接受的。所以我的建議是把Proxy納入配置管理平臺(tái)變更時(shí)間窗選在業(yè)務(wù)低峰同時(shí)準(zhǔn)備好回滾版本。如果項(xiàng)目對(duì)可用性要求極高可以考慮ShardingSphere后續(xù)版本里支持的集群模式把配置放到注冊(cè)中心統(tǒng)一管理配合管理端做動(dòng)態(tài)生效。不過(guò)引入這個(gè)方案本身也增加了部署復(fù)雜度建議在資源允許的前提下再上。另外接入Proxy之前務(wù)必先在測(cè)試環(huán)境做一輪全量SQL兼容性測(cè)試重點(diǎn)覆蓋子查詢、多表JOIN、批量INSERT、分頁(yè)排序這四類SQL。它們是最容易觸發(fā)路由異常和結(jié)果合并bug的場(chǎng)景。把這個(gè)測(cè)試做扎實(shí)上線后至少能躲掉80%的坑。6.4 我常用的排障路徑遇到問(wèn)題我會(huì)按照“連接層→路由層→執(zhí)行層→合并層”的順序來(lái)定位。連接層看端口、賬號(hào)、防火墻路由層開(kāi)sql-show看改寫(xiě)后的SQL是否落在預(yù)期分片執(zhí)行層去物理庫(kù)手動(dòng)執(zhí)行改寫(xiě)后的SQL確認(rèn)物理庫(kù)本身沒(méi)問(wèn)題合并層看返回結(jié)果集是否和預(yù)期一致。這套路徑幫我解決過(guò)幾十個(gè)疑難問(wèn)題比亂猜高效得多。寫(xiě)到最后想補(bǔ)充的一句話ShardingProxy不是那種用完就能立刻感受到“快”的組件它的價(jià)值是讓分庫(kù)分表后的系統(tǒng)依然像一個(gè)普通數(shù)據(jù)庫(kù)一樣可被消費(fèi)。我在多個(gè)項(xiàng)目里體會(huì)最深的一點(diǎn)是中間件只是工具真正決定架構(gòu)成敗的是你對(duì)業(yè)務(wù)查詢模式的理解以及是否提前規(guī)劃好分片鍵、綁定表、廣播表和讀寫(xiě)分離的組合策略。先把這些基礎(chǔ)打牢再上手Proxy你會(huì)發(fā)現(xiàn)很多問(wèn)題不需要靠文檔看一眼配置就能想明白原因。