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