剛開始看到“atlas”這個(gè)名字我腦子里瞬間閃過好幾個(gè)東西希臘神話里扛天的泰坦神地圖冊(cè)的英文名波士頓動(dòng)力的雙足機(jī)器人Facebook的廣告系統(tǒng)……但如果你是個(gè)干后端、搞數(shù)據(jù)庫的大概率第一反應(yīng)是那個(gè)曾經(jīng)在國內(nèi)互聯(lián)網(wǎng)圈子里很火的MySQL中間件。沒錯(cuò)這篇文章的主角就是它——奇虎360開源的數(shù)據(jù)庫中間件Atlas。這個(gè)項(xiàng)目源代碼托管在GitHub上奇虎360在2013年左右開源出來定位是MySQL代理層。它的核心價(jià)值說白了就是兩個(gè)讀寫分離和分表。你可以把它理解成數(shù)據(jù)庫門口的智能分流閘機(jī)——讀請(qǐng)求往從庫去寫請(qǐng)求往主庫去還能把一張千萬級(jí)的大表按規(guī)則拆成多張小表分?jǐn)偞鎯?chǔ)和查詢壓力。在那個(gè)MySQL官方還沒出什么像樣的中間件方案、MyCat還沒聲量那么大的年代Atlas確實(shí)算是很多團(tuán)隊(duì)的首選。這篇東西我不打算寫成一份照抄官方README的說明書而是從實(shí)際落地角度出發(fā)把部署、配置、原理、踩坑一條線捋清楚。如果你正在用或者準(zhǔn)備選型Atlas這篇文章能幫你少走不少彎路。文章里所有的操作步驟和配置示例都基于CentOS 7 MySQL 5.7的環(huán)境版本差異比較大的地方我會(huì)單獨(dú)標(biāo)出來。1. 為什么選擇Atlas一個(gè)老牌中間件的價(jià)值與邊界先說清楚一個(gè)觀點(diǎn)Atlas不是萬能的它解決的問題非常聚焦。但正因?yàn)榫劢顾谧约旱念I(lǐng)域里做得相當(dāng)純粹。很多時(shí)候我們選型失敗不是因?yàn)楣ぞ卟缓枚且驗(yàn)槠谕捣佩e(cuò)了位置。1.1 解決了什么問題在MySQL主從架構(gòu)里一臺(tái)主庫負(fù)責(zé)寫若干臺(tái)從庫負(fù)責(zé)讀。如果沒有中間層你的業(yè)務(wù)代碼就得自己感知哪臺(tái)是主、哪臺(tái)是從。比如你要寫數(shù)據(jù)就得連主庫要讀數(shù)據(jù)就得連從庫一旦主從切換所有連接配置都要跟著改。這在小團(tuán)隊(duì)、小業(yè)務(wù)量時(shí)還能湊合一旦服務(wù)多了維護(hù)成本就上來了。Atlas就是為了解決這個(gè)痛點(diǎn)出現(xiàn)的。業(yè)務(wù)方只需要連接Atlas完全不用理會(huì)背后有幾臺(tái)MySQL、哪臺(tái)是什么角色。你發(fā)給Atlas一條SQL它會(huì)自己判斷這條語句該發(fā)到主庫還是從庫然后把結(jié)果返回給你。這相當(dāng)于把“數(shù)據(jù)庫拓?fù)涓兄边@件事從業(yè)務(wù)端下沉到代理層業(yè)務(wù)代碼瞬間變得干凈了。另外一個(gè)殺招是分表。單表數(shù)據(jù)量超過千萬甚至億級(jí)的時(shí)候索引再優(yōu)化也扛不住寫入和查詢的延遲。Atlas支持按某個(gè)字段的哈希值取模把一張邏輯大表拆分成物理上的多張小表。業(yè)務(wù)還是按原表名去查Atlas在中間做映射和路由。這確實(shí)是解決大表問題的有效手段后文我會(huì)詳細(xì)講它的局限在哪。1.2 哪些場景不適合用AtlasAtlas是基于MySQL協(xié)議的代理它天然有一些限制。比如對(duì)事務(wù)的支持就不夠完美——開啟事務(wù)后事務(wù)里的語句默認(rèn)還是走讀寫分離規(guī)則如果你的事務(wù)內(nèi)是先寫后讀就可能出現(xiàn)讀到舊數(shù)據(jù)的情況。另一個(gè)是跨庫跨表的JOIN和子查詢性能會(huì)很差因?yàn)锳tlas需要把數(shù)據(jù)從多個(gè)后端節(jié)點(diǎn)撈回來再做關(guān)聯(lián)。所以這個(gè)方案更適合OLTP場景下的簡單查詢復(fù)雜分析類SQL建議直接上專門的OLAP方案或數(shù)倉別在Atlas這里硬扛。我還見過有人拿Atlas做分庫分表之外的“高可用”兜底這個(gè)用法其實(shí)有點(diǎn)錯(cuò)位。Atlas本身不是集群方案它自身就是單點(diǎn)。真要防Atlas這臺(tái)機(jī)器掛掉得靠Keepalived做VIP浮動(dòng)或者前置一層負(fù)載均衡比如HAProxy來做故障轉(zhuǎn)移否則它一掛整個(gè)數(shù)據(jù)庫入口就癱了。1.3 與其他老牌/同期方案對(duì)比下面這個(gè)表格是我在選型時(shí)候做的對(duì)比當(dāng)時(shí)備選的幾個(gè)方案都列出來了便于你有個(gè)直觀印象方案讀寫分離分表分庫管理界面協(xié)議兼容性活躍度Atlas支持支持單鍵哈希不支持管理端口命令高基于MySQL原生協(xié)議維護(hù)狀態(tài)社區(qū)活躍度一般MyCat支持支持支持有Web管理高支持多協(xié)議社區(qū)比Atlas活躍但配置復(fù)雜ShardingSphere-JDBC支持支持支持無中間件層嵌入應(yīng)用極高應(yīng)用內(nèi)集成很活躍云原生友好MySQL官方Router支持不支持不支持有API高官方維護(hù)但功能少看這張表你就明白了Atlas對(duì)比同期方案最大的優(yōu)勢是輕量、部署簡單、MySQL協(xié)議兼容性好。業(yè)務(wù)幾乎不用改代碼接上就能跑。對(duì)比現(xiàn)在的ShardingSphere-JDBC這種應(yīng)用內(nèi)集成方案Atlas的劣勢是功能不夠全、擴(kuò)展性偏弱但它作為獨(dú)立代理層對(duì)業(yè)務(wù)代碼的侵入性為零運(yùn)維維護(hù)上也更直觀。這兩種路線各有各的適用場景沒有絕對(duì)的好與壞。2. 核心架構(gòu)拆解讀寫分離和分表在Atlas內(nèi)部是怎么跑起來的知其然更要知其所以然。我把Atlas內(nèi)部幾個(gè)關(guān)鍵機(jī)制捋了一遍這塊搞清楚了后面配置和排錯(cuò)會(huì)輕松很多。2.1 連接管理前端連接與后端連接池Atlas本質(zhì)上是一個(gè)代理但它不是簡單的轉(zhuǎn)發(fā)。它內(nèi)部維護(hù)了兩類連接一類是業(yè)務(wù)程序連接到Atlas的連接叫前端連接另一類是Atlas連接到后端MySQL數(shù)據(jù)庫的連接叫后端連接。這里有一個(gè)很關(guān)鍵的機(jī)制后端連接是池化的。前端來一個(gè)連接Atlas不會(huì)立刻向后端建立一個(gè)對(duì)應(yīng)的MySQL連接而是從空閑連接池里取一個(gè)分配給前端。用完歸還。這樣做的好處是避免每個(gè)業(yè)務(wù)請(qǐng)求都要進(jìn)行一次完整的MySQL握手認(rèn)證大幅降低后端數(shù)據(jù)庫的連接建立開銷。類比一下就像你去銀行辦事大堂經(jīng)理Atlas不會(huì)每次都在柜臺(tái)新開一個(gè)窗口MySQL連接給你而是把你引導(dǎo)到已有的空閑窗口。窗口數(shù)量是有限的業(yè)務(wù)量再大后端數(shù)據(jù)庫的連接數(shù)也能被控制在合理區(qū)間。我在生產(chǎn)環(huán)境里就遇到過因?yàn)檫B接管理不當(dāng)導(dǎo)致MySQL連接數(shù)被打滿的故障Atlas這個(gè)機(jī)制幫了大忙。2.2 讀寫分離的判斷邏輯MySQL協(xié)議層玩兒的正則匹配Atlas怎么判斷一條SQL是讀還是寫呢如果你以為它解析了SQL語法那就太小看它了。它的判斷邏輯非常簡單直接對(duì)SQL語句進(jìn)行正則匹配。如果一個(gè)語句以SELECT開頭去掉注釋、空白符后并且不是SELECT ... FOR UPDATE這種帶鎖的查詢Atlas就把它歸為讀請(qǐng)求其余的全部歸為寫請(qǐng)求。包括INSERT、UPDATE、DELETE、CREATE、ALTER、DROP等凡是修改數(shù)據(jù)或結(jié)構(gòu)的一律走主庫。這里注意兩個(gè)容易被忽略的點(diǎn)一是“SELECT ... FOR UPDATE”會(huì)被識(shí)別為寫請(qǐng)求這是合理的因?yàn)镕OR UPDATE加的是行級(jí)排他鎖必須走主庫二是一些看似讀實(shí)則寫的情況比如自定義函數(shù)里執(zhí)行了更新外部套了SELECT。這類SQL會(huì)被判斷成讀請(qǐng)求而路由到從庫一旦從庫是只讀復(fù)制狀態(tài)就會(huì)報(bào)錯(cuò)。這種邊角情況在業(yè)務(wù)里確實(shí)會(huì)遇到后面踩坑部分我會(huì)專門說。2.3 分表實(shí)現(xiàn)哈希取模的規(guī)則世界Atlas的另一個(gè)標(biāo)志性功能是分表。它支持的是一種哈希取模的分片策略指定分表鍵shard key和分表數(shù)量N然后計(jì)算分表鍵的哈希值跟N取模得到的結(jié)果就對(duì)應(yīng)物理分表的表后綴。舉個(gè)例子訂單流水表叫T_ORDER分表鍵是ORDER_ID分表數(shù)量是16。那哈希值對(duì)16取模的結(jié)果就是表后綴實(shí)際物理表就是T_ORDER_0、T_ORDER_1、T_ORDER_2……一直到T_ORDER_15。業(yè)務(wù)插入一條數(shù)據(jù)時(shí)Atlas根據(jù)ORDER_ID算出該去哪個(gè)分表然后把SQL改寫后路由到對(duì)應(yīng)分表。但這里有個(gè)極大的坑如果你的分表規(guī)則設(shè)計(jì)不合理查詢時(shí)沒有帶分表鍵那Atlas就只能對(duì)所有分表做全表掃描把每條分表的結(jié)果全部合并返回。這在數(shù)據(jù)量小的時(shí)候問題不明顯等數(shù)據(jù)量大了一次查詢可能要打幾十張表性能直接崩掉。所以分表鍵的選擇和查詢習(xí)慣的設(shè)計(jì)是分表方案能否跑得好的核心前提比中間件本身還重要。2.4 主庫故障下的主從切換一個(gè)需要你提前準(zhǔn)備的動(dòng)作Atlas自身不具備數(shù)據(jù)庫高可用切換能力。也就是說它只是知道哪臺(tái)是主庫、哪臺(tái)是從庫如果主庫掛了它不會(huì)自動(dòng)把從庫提升為主庫并修改自己的配置。這需要借助外部工具做故障轉(zhuǎn)移比如MHAMaster High Availability或者自研腳本去觸發(fā)MySQL主從切換然后把Atlas.conf里的Master和Slave配置改掉再重啟Atlas。我看到很多初次使用Atlas的團(tuán)隊(duì)都會(huì)忽略這個(gè)問題默認(rèn)以為Atlas會(huì)自己搞定結(jié)果主庫一掛整個(gè)服務(wù)直接癱瘓。所以務(wù)必在前期架構(gòu)設(shè)計(jì)時(shí)就把主從切換的流程想清楚并且做好演練。后面我會(huì)專門有一節(jié)講這個(gè)踩坑。3. 部署實(shí)操從源碼編譯到生產(chǎn)環(huán)境上線Atlas的安裝方式主要有兩種官方提供了編譯好的二進(jìn)制包至少有CentOS和Ubuntu版本另一個(gè)是自己從源碼編譯。我強(qiáng)烈建議一般團(tuán)隊(duì)直接使用官方二進(jìn)制包省時(shí)省力只有需要定制化內(nèi)核或改代碼的團(tuán)隊(duì)才需要走編譯這條路。3.1 環(huán)境準(zhǔn)備與依賴檢查操作系統(tǒng)層面我用的CentOS 7 x86_64。依賴方面Atlas需要依賴libevent、glib2、mysql-devel這些基礎(chǔ)庫。如果你下載的二進(jìn)制包在啟動(dòng)時(shí)報(bào)缺少動(dòng)態(tài)庫的錯(cuò)誤通常就是這些依賴沒裝齊。yum install -y libevent libevent-devel glib2 glib2-devel mysql-devel ncurses-devel建一個(gè)專用的系統(tǒng)用戶來跑Atlas不推薦直接用root這是個(gè)基本的安全習(xí)慣。useradd -M -s /sbin/nologin atlas mkdir -p /usr/local/mysql-proxy chown -R atlas:atlas /usr/local/mysql-proxy3.2 安裝與目錄規(guī)劃把二進(jìn)制包解壓到/usr/local/mysql-proxy目錄后里面會(huì)有bin和conf兩個(gè)目錄。bin里是一個(gè)叫mysql-proxy的可執(zhí)行文件Atlas的運(yùn)行就是靠它。注意雖然它繼承了mysql-proxy的名字但奇虎360在原版基礎(chǔ)上做了大規(guī)模改造和MySQL官方的mysql-proxy已經(jīng)完全不是同一個(gè)東西了。Atlas啟動(dòng)之后主要監(jiān)聽兩個(gè)端口一個(gè)默認(rèn)是1234這是業(yè)務(wù)流量入口就是給應(yīng)用連的另一個(gè)是2345這是管理端口運(yùn)維人員和腳本通過這個(gè)端口執(zhí)行管理命令。配置文件放在conf目錄下一般叫Atlas.conf。還有個(gè)重要的文件是分表規(guī)則文件默認(rèn)叫shard.conf或者加在Atlas.conf尾部各版本命名有差異按實(shí)際來。我習(xí)慣這樣規(guī)劃目錄conf/Atlas.conf —— 主配置文件conf/sharding.conf或Atlas.conf中的分表段 —— 分表規(guī)則logs/ —— 日志目錄包括sql.log和error.logbin/mysql-proxy —— 可執(zhí)行程序3.3 配置文件的詳細(xì)解析下面是一份我在生產(chǎn)環(huán)境中用的Atlas.conf模板去掉了敏感信息每個(gè)關(guān)鍵項(xiàng)都注釋了含義[mysql-proxy] # 是否以后臺(tái)守護(hù)進(jìn)程方式運(yùn)行 daemon true # 管理端口綁定的地址和端口 admin-address 0.0.0.0:2345 # 業(yè)務(wù)流量入口綁定的地址和端口 proxy-address 0.0.0.0:1234 # 管理接口的用戶名和密碼用于連接管理端口 admin-username admin admin-password admin_pwd # 后端主從MySQL配置 # 主庫可寫 proxy-backend-addresses 10.0.0.2:3306 # 從庫可讀多個(gè)從庫用逗號(hào)分隔 proxy-read-only-backend-addresses 10.0.0.3:3306,10.0.0.4:3306 # 連接Atlas自身的認(rèn)證用戶 pwds root:xxxxxx # 分表規(guī)則所在的文件 shard-file /usr/local/mysql-proxy/conf/shard.conf # 日志級(jí)別debug級(jí)別會(huì)輸出每條SQL生產(chǎn)建議用message診斷問題臨時(shí)開debug log-level message log-path /usr/local/mysql-proxy/logs # 工作線程數(shù)建議與CPU核數(shù)相同 event-threads 8 # 會(huì)話空閑超時(shí)時(shí)間單位秒 wait-timeout 60這里面有幾個(gè)容易踩坑的地方第一pwds是連接Atlas的認(rèn)證用戶配置格式是“用戶名:加密后的密碼”。這里的密碼不是明文是MySQL加密后的密碼串。怎么獲取在MySQL服務(wù)器上執(zhí)行SQL來生成SELECT PASSWORD(your_password);把返回的那一串密碼填進(jìn)去。千萬不要直接填明文否則Atlas會(huì)拒絕認(rèn)證。這是新人使用Atlas最常見的坑。第二如果暫時(shí)不分表shard-file可以留空或不配置。但一旦配置了Atlas啟動(dòng)時(shí)就會(huì)強(qiáng)制校驗(yàn)分表規(guī)則文件的格式格式不對(duì)會(huì)啟動(dòng)失敗。3.4 啟動(dòng)、停止與驗(yàn)證啟動(dòng)很簡單/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file/usr/local/mysql-proxy/conf/Atlas.conf注意Atlas默認(rèn)使用/etc/mysql-proxy.cnf作為配置文件如果你把配置放在了別的路徑一定要用--defaults-file指定。而且配置文件要求權(quán)限是0600否則啟動(dòng)時(shí)會(huì)報(bào)錯(cuò)。這也算是一個(gè)隱蔽坑我遇到過直接復(fù)制配置文件過去忘了改權(quán)限的情況。啟動(dòng)后驗(yàn)證兩件事業(yè)務(wù)端口是否監(jiān)聽netstat -tlnp | grep 1234管理端口是否監(jiān)聽netstat -tlnp | grep 2345然后用管理端口連進(jìn)去看后端狀態(tài)mysql -h127.0.0.1 -P2345 -uadmin -padmin_pwd執(zhí)行SELECT * FROM backends;應(yīng)該能看到主庫和從庫的狀態(tài)。正常狀態(tài)下主庫的type是rw從庫type是rostatus是up。為了業(yè)務(wù)流量連通性最好再用一個(gè)有業(yè)務(wù)的賬號(hào)試連一下1234跑一條簡單的SELECT確認(rèn)讀寫分離生效mysql -h127.0.0.1 -P1234 -uappuser -papppass -e SELECT 1;如果這條能通整體鏈路基本就算起來了。把Atlas注冊(cè)成systemd服務(wù)也好寫個(gè)啟動(dòng)腳本扔進(jìn)rc.local也好反正要保證開機(jī)自啟。4. 分表與讀寫分離配置實(shí)戰(zhàn)讓規(guī)則真正跑起來我見過很多團(tuán)隊(duì)部署完Atlas測試讀寫分離正常然后就開始跑業(yè)務(wù)了。但用到分表功能時(shí)由于分表配置不正確或使用方法不對(duì)上線當(dāng)天就出了線上事故。這一節(jié)我專門把分表配置的前前后后講透。4.1 分表規(guī)則文件到底怎么寫我用的shard.conf是一個(gè)Python風(fēng)格的規(guī)則文件核心就是注冊(cè)一個(gè)函數(shù)函數(shù)返回分表后的表名。例如def main(): # 讀取分表鍵的值 from atlas_shard_rule import * return get_shard_table(4)稍微解釋一下邏輯Atlas的分表規(guī)則文件使用Python語法Atlas在啟動(dòng)和路由SQL時(shí)會(huì)加載并執(zhí)行這個(gè)文件根據(jù)你寫的規(guī)則確定物理表名。整個(gè)配置文件里可以寫多個(gè)規(guī)則函數(shù)每個(gè)函數(shù)對(duì)應(yīng)一種分表模式。函數(shù)的返回值就是實(shí)際路由到的物理表名Atlas會(huì)用它替換SQL里的邏輯表名。我自己的分表規(guī)則文件一般長這樣def rule_order(): table_name T_ORDER shard_num 16 return get_shard_table(shard_num) def rule_user(): table_name T_USER shard_num 8 return get_shard_table(shard_num)等等這個(gè)寫法其實(shí)還需要再細(xì)化。前面例子里的get_shard_table內(nèi)部會(huì)拿到當(dāng)前語句的分表鍵值再對(duì)分表數(shù)量取模。具體使用哪個(gè)分表鍵是在SQL語句的WHERE條件里體現(xiàn)的。Atlas會(huì)從句法層面解析出分表鍵的值帶入Python函數(shù)函數(shù)計(jì)算出目標(biāo)分表名后Atlas再改寫SQL并路由。4.2 建分表的最佳實(shí)踐提前建好還是動(dòng)態(tài)創(chuàng)建Atlas本身不負(fù)責(zé)自動(dòng)創(chuàng)建分表。你必須在MySQL實(shí)例上把所有分表手動(dòng)建好。假設(shè)邏輯表名是T_ORDER分16個(gè)分表你必須先在數(shù)據(jù)庫里創(chuàng)建T_ORDER_0、T_ORDER_1、一直到T_ORDER_15這16張表。每張表的表結(jié)構(gòu)完全一致索引也一致。如果業(yè)務(wù)端有DDL變更也要同步到所有分表上。我強(qiáng)烈建議你在項(xiàng)目啟動(dòng)腳本里或者在發(fā)布流程里寫一個(gè)遍歷建表和遍歷改表的腳本確保所有分表結(jié)構(gòu)完全一致。否則后期排查數(shù)據(jù)缺失問題會(huì)痛不欲生。我自己就經(jīng)歷過因?yàn)槟撤直砩倭怂饕齻€(gè)別訂單查詢奇慢無比的問題。不同MySQL實(shí)例上的分表怎么分布Atlas支持在不同后端MySQL節(jié)點(diǎn)上放不同的分表。比如主庫上放T_ORDER_0到T_ORDER_7從庫上放T_ORDER_8到T_ORDER_15。這種情況下路由邏輯會(huì)先根據(jù)哈希值找到分表名再根據(jù)分表名找到對(duì)應(yīng)的后端節(jié)點(diǎn)。這個(gè)功能在生產(chǎn)上非常有用可以把一個(gè)大表的數(shù)據(jù)分散到不同機(jī)器上進(jìn)一步降低單機(jī)壓力。4.3 分表后SQL編寫的硬性要求分表規(guī)則生效后SQL寫入和查詢時(shí)必須帶上分表鍵。我給你的最實(shí)在的建議是在項(xiàng)目初期的代碼規(guī)范里就明確下來所有涉及分表的表查詢、更新、刪除必須強(qiáng)制帶上分表鍵。例如-- 錯(cuò)誤示范沒有帶分表鍵Atlas只能全分表掃描 SELECT * FROM T_ORDER WHERE ORDER_STATUS PAID; -- 正確示范帶分表鍵Atlas可以直接路由到唯一分表 SELECT * FROM T_ORDER WHERE ORDER_ID A123456789;如果確實(shí)需要在不帶分表鍵的情況下查詢雖然Atlas會(huì)廣播到所有分表再合并結(jié)果但這種操作應(yīng)該被嚴(yán)格控制盡量在業(yè)務(wù)低峰期執(zhí)行或者提前在中間層緩存/搜索引擎里做條件查詢。說實(shí)話廣播查詢?cè)诜直頂?shù)量少比如4張、8張且數(shù)據(jù)不是特別巨大時(shí)勉強(qiáng)能用到了16張以上基本就別指望了延遲會(huì)指數(shù)級(jí)上升。還有一個(gè)容易被忽略的點(diǎn)分表鍵不能更新。如果你把某行的分表鍵值改了它的哈希值就變了理論上的位置也跟著變但實(shí)際上數(shù)據(jù)還在老分表里查新分表就找不到了。所以一條鐵律分表鍵只支持新增和查詢不支持修改。4.4 讀寫分離加分表聯(lián)調(diào)測試配置完成之后我是這樣做的聯(lián)調(diào)驗(yàn)證先在主庫上手動(dòng)插入幾條測試數(shù)據(jù)分表規(guī)則比如ORDER_ID100和ORDER_ID101會(huì)路由到不同的分表插入成功后再去各分表確認(rèn)數(shù)據(jù)落位正確。通過在代碼里同時(shí)發(fā)讀請(qǐng)求和寫請(qǐng)求觀察Atlas日志里SQL實(shí)際被路由到了哪個(gè)后端、哪個(gè)分表。開啟debug日志臨時(shí)觀察在Atlas.conf中把log-level改成debug重啟Atlas執(zhí)行幾條典型的CRUD查看logs/sql.log里的實(shí)際路由信息確認(rèn)無誤后再把log-level改回message并重啟避免生產(chǎn)環(huán)境留下大量調(diào)試日志。5. 生產(chǎn)環(huán)境踩坑實(shí)錄這些問題網(wǎng)上真的搜不到現(xiàn)成答案在寫這篇文章之前我特意翻了翻以前運(yùn)維Atlas這段時(shí)間積累的排障筆記。有些問題在當(dāng)時(shí)花了很大力氣才定位現(xiàn)在回想起來如果早點(diǎn)有人寫出來真的能省很多功夫。下面這些都是我實(shí)際踩過的坑按踩坑的頻率和影響程度排個(gè)序。5.1 連接全部掛起問題出在backends狀態(tài)不一致有一次線上突然出現(xiàn)大面積請(qǐng)求超時(shí)檢查Atlas的backends發(fā)現(xiàn)主庫和從庫都顯示up但業(yè)務(wù)就是卡住不動(dòng)。后來仔細(xì)排查發(fā)現(xiàn)問題出在MySQL端主庫因?yàn)橐淮未笫聞?wù)導(dǎo)致臨時(shí)表空間滿了所有寫請(qǐng)求堵塞連帶Atlas的業(yè)務(wù)線程全部卡在等待后端響應(yīng)上。當(dāng)時(shí)的解決辦法是先把主庫上的慢事務(wù)殺掉等主庫恢復(fù)后Atlas自然就恢復(fù)了。但這個(gè)過程我意識(shí)到一個(gè)很重要的問題Atlas沒有健康檢查機(jī)制它不會(huì)自動(dòng)把掛掉的后端從輪詢列表里移出去。你的監(jiān)控系統(tǒng)必須覆蓋到Atlas這一層否則你只會(huì)看到業(yè)務(wù)超時(shí)卻不知道根源在哪。后來我加了一個(gè)定時(shí)腳本每30秒檢查一次Atlas的backends狀態(tài)只要發(fā)現(xiàn)某個(gè)后端狀態(tài)異?；蝽憫?yīng)耗時(shí)超高立刻報(bào)警。這類腳本網(wǎng)上沒有現(xiàn)成的統(tǒng)一方案我建議就自己在服務(wù)器上寫個(gè)Python腳本連上管理端口拉狀態(tài)推送報(bào)警到釘釘或者企業(yè)微信非常管用。5.2 主從切換后Atlas還指向舊主庫這是幾乎每個(gè)用Atlas的團(tuán)隊(duì)都會(huì)遇到的問題只是早晚。當(dāng)主庫宕機(jī)你用MHA把從庫提升為新主庫之后必須手動(dòng)修改Atlas.conf中的proxy-backend-addresses和新從庫地址然后重啟Atlas。我踩過的坑是MHA切換完成后網(wǎng)站還是慢得一塌糊涂。因?yàn)榕f主庫恢復(fù)了但已經(jīng)變成從庫還在被Atlas當(dāng)成主庫接收所有寫流量新主庫只是作為只讀從庫在背后默默復(fù)制。數(shù)據(jù)看著沒丟但高可用完全失效了。后來我總結(jié)出一套相對(duì)順暢的切換流程確認(rèn)MHA完成主從切換新主庫狀態(tài)正常修改Atlas.conf把舊的proxy-backend-addresses改成新主庫地址把舊主庫地址加入proxy-read-only-backend-addresses用mysql-proxy --defaults-file... --reload有些版本是HUP信號(hào)嘗試熱加載配置如果版本不支持就重啟Atlas重啟后立刻在管理端口執(zhí)行SELECT * FROM backends;確認(rèn)主從角色正確讓業(yè)務(wù)側(cè)做一輪功能回歸測試確認(rèn)寫入讀取都正常整個(gè)切換過程我們后來控制在分鐘級(jí)別而且專門做了演練確保操作人員不需要臨時(shí)翻文檔就能執(zhí)行。5.3 FOR UPDATE語句導(dǎo)致的死鎖誤判有一次業(yè)務(wù)頻繁報(bào)死鎖但數(shù)據(jù)庫自身的死鎖日志根本不顯示任何記錄。查了半天發(fā)現(xiàn)是業(yè)務(wù)代碼里在事務(wù)里用了SELECT ... FOR UPDATEAtlas判斷正確地將它路由到了主庫但由于同一個(gè)事務(wù)里的普通SELECT被路由到了從庫瞬間產(chǎn)生了兩個(gè)不同的連接一個(gè)在主庫鎖定行一個(gè)在從庫讀取快照。此時(shí)如果主庫的行一直鎖著從庫讀請(qǐng)求依賴的binlog位置就會(huì)一直等待業(yè)務(wù)表現(xiàn)為死鎖超時(shí)。這個(gè)問題的根源是Atlas的讀寫分離粒度太粗它對(duì)“事務(wù)內(nèi)語句”沒有明確的黏合機(jī)制。解決思路有幾種一是把此類需要嚴(yán)格一致性的查詢都顯式加上FOR UPDATE強(qiáng)制走主庫二是在配置里將所有該業(yè)務(wù)的用戶設(shè)為只走主庫也就是把該用戶加進(jìn)非讀寫分離名單三是修改代碼把事務(wù)內(nèi)的查詢和寫庫操作合并到同一個(gè)連接上執(zhí)行。第三種方案最徹底但需要業(yè)務(wù)配合改動(dòng)。我當(dāng)時(shí)是讓業(yè)務(wù)把事務(wù)內(nèi)的讀改成了FOR UPDATE或者干脆在事務(wù)里只做寫操作事務(wù)結(jié)束之后再做查詢。這個(gè)方案治標(biāo)也治本至少業(yè)務(wù)保持一致性了。5.4 連接數(shù)被打滿Atlas自身線程和MySQL連接數(shù)的聯(lián)動(dòng)關(guān)系A(chǔ)tlas默認(rèn)的連接池行為是一個(gè)前端連接對(duì)應(yīng)一個(gè)后端連接。如果業(yè)務(wù)方連接池配置得比較大比如最小連接數(shù)200最大連接數(shù)500同時(shí)有多個(gè)服務(wù)連同一個(gè)Atlas那Atlas到后端的MySQL連接數(shù)會(huì)非?？鋸?。MySQL默認(rèn)最大連接數(shù)是151很快就被打滿了。解決這個(gè)問題需要多端聯(lián)動(dòng)調(diào)大MySQL的max_connections但要有度別把系統(tǒng)資源拖垮控制業(yè)務(wù)連接池大小不要在連接池里設(shè)置過大的空閑連接數(shù)在Atlas層面event-threads線程數(shù)不要盲目調(diào)大設(shè)成CPU核數(shù)比較合適讓Atlas和MySQL之間保持內(nèi)網(wǎng)通信降低TCP連接建立時(shí)間我這里給出一個(gè)我經(jīng)過壓測調(diào)優(yōu)后的參數(shù)組合供參考參數(shù)位置參數(shù)名推薦值說明my.cnfmax_connections1000根據(jù)最大并發(fā)和內(nèi)存綜合評(píng)估m(xù)y.cnfwait_timeout60讓空閑連接盡快釋放Atlas.confevent-threadsCPU核數(shù)太高反而引入上下文切換開銷Atlas.confwait-timeout60和MySQL保持一致業(yè)務(wù)連接池maximum-pool-size50~100按服務(wù)實(shí)例數(shù)和吞吐量評(píng)估5.5 分表鍵沒走索引少了一個(gè)普通的WHERE條件引發(fā)的慘案分表鍵的選擇也很講究。前面說業(yè)務(wù)查詢必須帶上分表鍵但如果你帶的是個(gè)區(qū)分度很低的字段比如狀態(tài)字段那分表本身意義不大因?yàn)楣＝Y(jié)果會(huì)集中在某幾個(gè)分表上造成數(shù)據(jù)傾斜。更嚴(yán)重的是如果你在建表時(shí)沒有為分表鍵建索引那么即使路由對(duì)了分表在分表內(nèi)部也會(huì)產(chǎn)生全表掃描。分表只是把你的大表變成多張小表但如果你不建索引每張小表依然要全掃。所以設(shè)計(jì)表結(jié)構(gòu)時(shí)必須把分表鍵納入索引設(shè)計(jì)的第一優(yōu)先級(jí)。一般建議分表鍵同時(shí)是查詢高頻條件比如訂單號(hào)、用戶ID。這樣既能精準(zhǔn)路由又能在單表內(nèi)用上索引性能才真正有保障。6. 日常運(yùn)維與監(jiān)控讓Atlas穩(wěn)定運(yùn)行的管理手段一個(gè)中間件跑起來之后日常維護(hù)工作其實(shí)不少。Atlas本身提供的功能有限但用好管理和監(jiān)控手段還是能過得比較從容。6.1 管理接口的實(shí)用命令管理端口是整個(gè)運(yùn)維的核心入口以下命令是我最常用的-- 查看所有后端節(jié)點(diǎn)的狀態(tài) SELECT * FROM backends; -- 動(dòng)態(tài)加入一個(gè)從庫節(jié)點(diǎn)避免重啟 ADD RO BACKEND 10.0.0.5:3306; -- 動(dòng)態(tài)下線一個(gè)后端節(jié)點(diǎn)常見于數(shù)據(jù)庫實(shí)例維護(hù) REMOVE BACKEND 3; -- 查看當(dāng)前Atlas的配置信息 SELECT * FROM config;動(dòng)態(tài)上下線功能特別重要。比如要從庫做備份或者升級(jí)直接REMOVE再ADD業(yè)務(wù)側(cè)完全無感知不需要重啟Atlas。6.2 日志是排障的第一現(xiàn)場Atlas的日志目錄下一般有sql.log和error.log。sql.log在log-leveldebug時(shí)記錄每一條SQL的路由詳情error.log則記錄運(yùn)行時(shí)的錯(cuò)誤信息。平時(shí)排障我的順序是先看error.log再看sql.log最后看系統(tǒng)層面的dmesg和MySQL慢查詢?nèi)罩?。調(diào)試SQL路由問題時(shí)一條典型的debug日志大概長這樣[DEBUG] 2024-05-20 10:15:30: (sql) SELECT * FROM T_ORDER WHERE ORDER_ID 123 - route to backend 10.0.0.3:3306, table: T_ORDER_5看到這行日志你就能明確知道這條SQL被路由到了哪個(gè)從庫、哪個(gè)分表。如果發(fā)現(xiàn)路由結(jié)果和預(yù)期不符先檢查分表規(guī)則文件再檢查SQL是否帶了正確的分表鍵。6.3 監(jiān)控項(xiàng)不盯這些出了問題只能干瞪眼根據(jù)我對(duì)Atlas長期的運(yùn)維觀察下面這幾個(gè)監(jiān)控指標(biāo)至少要有Atlas進(jìn)程是否存活最簡單一個(gè)進(jìn)程監(jiān)控腳本或systemd守護(hù)就能解決管理端口能不能連能連說明進(jìn)程本身沒死但可能處在異常狀態(tài)backends里各節(jié)點(diǎn)的連接數(shù)如果某個(gè)后端節(jié)點(diǎn)連接數(shù)異常高大概率是有慢查詢堵住了連接池Atlas到后端的響應(yīng)延遲可以用tcprstat之類工具統(tǒng)計(jì)Atlas和MySQL之間的網(wǎng)絡(luò)延遲也可以直接在MySQL端開general_log觀察Atlas過來的請(qǐng)求是否變慢分表數(shù)據(jù)分布是否均勻定期抽查各分表的行數(shù)確認(rèn)數(shù)據(jù)沒有嚴(yán)重傾斜這些監(jiān)控項(xiàng)不用全部自己造輪子如果你有Zabbix或Prometheus可以直接接進(jìn)去。Atlas沒有官方exporter我當(dāng)年是用腳本輪詢管理端口拿到狀態(tài)數(shù)據(jù)再轉(zhuǎn)成metrics推到Prometheus畫到Grafana上。效果挺好中間件自身的狀態(tài)一目了然。6.4 高可用架構(gòu)的完整形態(tài)最后說一個(gè)理想的Atlas部署形態(tài)避免讀者在搭建時(shí)只在單臺(tái)機(jī)器上跑一個(gè)Atlas就以為完事了。我建議的架構(gòu)是兩臺(tái)機(jī)器各部署一個(gè)Atlas實(shí)例前置一臺(tái)HAProxy做負(fù)載均衡后端的MySQL主從由MHA或自研工具負(fù)責(zé)切換。這樣任意一臺(tái)Atlas掛了HAProxy會(huì)自動(dòng)摘除業(yè)務(wù)流量全部轉(zhuǎn)發(fā)到存活的那臺(tái)。Atlas本身是無狀態(tài)的代理配置保持一致即可不涉及數(shù)據(jù)同步問題所以高可用實(shí)現(xiàn)起來并不難。后端MySQL層面主庫掛了MHA自動(dòng)切換然后通過外部腳本更新兩臺(tái)Atlas的配置。整個(gè)鏈路里HAProxy是唯一還需要再考慮高可用的點(diǎn)通常再配一組Keepalived漂移VIP就能解決。這套架構(gòu)跑下來數(shù)據(jù)庫入口層基本就沒有明顯的單點(diǎn)了。業(yè)務(wù)方只認(rèn)一個(gè)VIP背后具體是哪個(gè)Atlas在扛、哪臺(tái)MySQL是主都跟業(yè)務(wù)無關(guān)運(yùn)維自主可控。回到Atlas這個(gè)項(xiàng)目本身雖然它不像今天云原生時(shí)代的很多新組件那么花哨但作為MySQL中間件領(lǐng)域一個(gè)極其務(wù)實(shí)的開源項(xiàng)目它的設(shè)計(jì)思路和實(shí)現(xiàn)方式放到現(xiàn)在的很多場景里依然有參考價(jià)值。如果你正在評(píng)估輕量級(jí)讀寫分離方案或者想理解代理層數(shù)據(jù)庫中間件的工作機(jī)制Atlas確實(shí)是個(gè)值得研究的樣本。最后留一句實(shí)在話任何中間件都只是工具用得好不好關(guān)鍵還是理解它背后的路由邏輯和邊界條件。配置照著抄很簡單真正考驗(yàn)功力的是出了問題之后你能不能從一堆日志里快速定位到它把SQL送到了哪里、為什么會(huì)送錯(cuò)。掌握這個(gè)能力比會(huì)裝一個(gè)Atlas值錢多了。