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