最近在整理一套老系統(tǒng)的數(shù)據(jù)庫(kù)訪問(wèn)鏈路項(xiàng)目代號(hào)就叫 Atlas。這套東西本質(zhì)是一個(gè)放在應(yīng)用和 MySQL 之間的訪問(wèn)中間層用來(lái)統(tǒng)一解決讀寫分離、分庫(kù)分表、連接管理這些煩心事。你可能也遇到過(guò)類似情況業(yè)務(wù)量上來(lái)之后單庫(kù)單表扛不住應(yīng)用層到處寫死數(shù)據(jù)庫(kù)地址一到大促就要臨時(shí)拆庫(kù)代碼改到想罵人。Atlas 要做的就是讓應(yīng)用側(cè)只認(rèn)一個(gè)入口真正落在哪臺(tái)庫(kù)、哪張表由中間層去決策。這篇東西我打算從項(xiàng)目整體設(shè)計(jì)講到核心原理再到部署實(shí)操和排障經(jīng)驗(yàn)全程用我實(shí)際踩過(guò)的坑來(lái)鋪墊。適合正在做數(shù)據(jù)庫(kù)拆分、讀寫分離或者被連接數(shù)打滿折磨過(guò)的后端開發(fā)、DBA 和架構(gòu)師參考。即便你是第一次接觸中間件只要跟著走一遍也能理解它到底怎么工作、能解決什么問(wèn)題。1. 項(xiàng)目定位與方案拆解1.1 Atlas 在整個(gè)數(shù)據(jù)鏈路中扮演什么角色先打個(gè)比方。以前應(yīng)用直連數(shù)據(jù)庫(kù)就像每個(gè)員工都直接跑到倉(cāng)庫(kù)去拿貨倉(cāng)庫(kù)窗口就那幾個(gè)人一多就排隊(duì)偶爾有人拿錯(cuò)貨還沒人管。Atlas 就好比在倉(cāng)庫(kù)門口加了一個(gè)分撥臺(tái)所有取貨請(qǐng)求先到這里登記分撥臺(tái)根據(jù)貨單內(nèi)容決定你去哪個(gè)窗口順帶還能幫你把一些零散的小請(qǐng)求合并成大訂單。放到技術(shù)鏈路上看Atlas 的位置非常清晰應(yīng)用層通過(guò)標(biāo)準(zhǔn)的 MySQL 協(xié)議連上 Atlas 的端口Atlas 解析 SQL 之后再往后端真實(shí)的 MySQL 實(shí)例轉(zhuǎn)發(fā)。應(yīng)用側(cè)根本感知不到后端有幾臺(tái)機(jī)器、哪些是主庫(kù)、哪些是從庫(kù)。這個(gè)方式的優(yōu)勢(shì)在于數(shù)據(jù)庫(kù)拓?fù)渥兏挥迷偻ㄖ袠I(yè)務(wù)方只需要改中間層配置。我在做這套項(xiàng)目時(shí)最直觀的感受是連接數(shù)和流量可控了。以前幾百個(gè)服務(wù)實(shí)例每個(gè)都保持幾十個(gè)長(zhǎng)連接數(shù)據(jù)庫(kù)光握手就要耗盡 CPU。Atlas 收口之后后端連接數(shù)變得非常平穩(wěn)應(yīng)用擴(kuò)容也不用擔(dān)心把數(shù)據(jù)庫(kù)連接池打爆。說(shuō)白了它讓數(shù)據(jù)庫(kù)從“被很多人直接操作”變成“被一個(gè)有腦子的人統(tǒng)一調(diào)度”。1.2 核心功能清單與方案選型對(duì)比Atlas 的核心功能我整理成了一張表和直連方案對(duì)比大家看得更清楚功能維度直連數(shù)據(jù)庫(kù)Atlas 中間件后端地址管理每個(gè)應(yīng)用配置自己的連接串統(tǒng)一入口后端變更對(duì)應(yīng)用透明讀寫分離應(yīng)用自己實(shí)現(xiàn)代碼侵入大中間層按 SQL 類型自動(dòng)路由分庫(kù)分表應(yīng)用層判斷并拼接表名按分片鍵路由應(yīng)用無(wú)需關(guān)心連接池復(fù)用每個(gè)服務(wù)維護(hù)一堆連接中間層統(tǒng)一復(fù)用降低連接數(shù)故障摘除依賴應(yīng)用側(cè)重試機(jī)制健康檢查后自動(dòng)剔除故障節(jié)點(diǎn)監(jiān)控審計(jì)分散難匯總統(tǒng)一日志與統(tǒng)計(jì)便于排查為什么不直接選應(yīng)用層改造或者引入其他重量級(jí)方案而是用 Atlas 這類中間件我當(dāng)時(shí)的考慮有幾點(diǎn)。第一應(yīng)用層改造成本太高幾十個(gè)服務(wù)都要?jiǎng)右槐楣馀牌诰鸵鐑蓚€(gè)迭代。第二很多輕量級(jí)方案對(duì)分庫(kù)分表的支持很弱尤其是一致性事務(wù)場(chǎng)景自己寫容易挖坑。第三Atlas 這類基于 MySQL 協(xié)議的代理方案對(duì)業(yè)務(wù)代碼基本透明切換成本低上線失敗也容易回滾。當(dāng)然它也有短板比如跨庫(kù) JOIN 支持不好分布式事務(wù)需要業(yè)務(wù)配合。但這不是 Atlas 的問(wèn)題而是所有分庫(kù)分表都要付出的代價(jià)。你選的不是完美方案而是在當(dāng)前階段收益最大、代價(jià)最小的方案。1.3 整體架構(gòu)拓?fù)渑c數(shù)據(jù)流向Atlas 的部署形態(tài)不復(fù)雜核心就三層。最上層是接入層也就是應(yīng)用服務(wù)器它們只需要配置一個(gè)虛擬 IP 或者域名指向 Atlas 所在的主機(jī)端口可以是常見的 3306也可以換成別的。中間是 Atlas 節(jié)點(diǎn)建議至少部署兩個(gè)一臺(tái)為主、一臺(tái)為備配合 Keepalived 之類的工具做高可用切換。下面是真實(shí)的 MySQL 實(shí)例集群分為主庫(kù)和若干從庫(kù)主庫(kù)負(fù)責(zé)寫入從庫(kù)負(fù)責(zé)讀取。數(shù)據(jù)流向大概是這樣的應(yīng)用發(fā)出 SQL 請(qǐng)求Atlas 先解析這條 SQL 的類型和涉及的表然后根據(jù)配置的路由規(guī)則以及當(dāng)前各節(jié)點(diǎn)的健康狀態(tài)決定把請(qǐng)求轉(zhuǎn)發(fā)給哪個(gè)后端實(shí)例。如果是SELECT默認(rèn)會(huì)挑一個(gè)負(fù)載較低的從庫(kù)如果是INSERT、UPDATE、DELETE或者會(huì)話開啟了事務(wù)就走主庫(kù)。如果配置了分庫(kù)分表還需要根據(jù)分片鍵算出具體落到哪個(gè)庫(kù)、哪張表。這里有個(gè)容易被忽略的點(diǎn)Atlas 自身是無(wú)狀態(tài)的也就是說(shuō)它不存業(yè)務(wù)數(shù)據(jù)只是做轉(zhuǎn)發(fā)和路由。這樣設(shè)計(jì)的好處非常明顯一旦某臺(tái) Atlas 宕機(jī)另一臺(tái)可以直接頂上數(shù)據(jù)不會(huì)丟。壞處是配置要同步好不然兩個(gè)節(jié)點(diǎn)的規(guī)則不一致會(huì)引發(fā)路由錯(cuò)亂。我后續(xù)會(huì)專門講怎么用腳本同步配置和管理節(jié)點(diǎn)。2. 核心機(jī)制與關(guān)鍵原理2.1 讀寫分離的實(shí)現(xiàn)細(xì)節(jié)與路由策略讀寫分離是 Atlas 最常用的能力但很多人只知道“SELECT 走從庫(kù)其他走主庫(kù)”實(shí)際做起來(lái)沒有那么簡(jiǎn)單。路由的判斷不僅是看 SQL 的第一個(gè)關(guān)鍵詞。比如SELECT ... FOR UPDATE雖然以 SELECT 開頭但它帶了行鎖必須走主庫(kù)否則你在從庫(kù)加鎖主庫(kù)的數(shù)據(jù)還在被別人改業(yè)務(wù)就出大問(wèn)題。再比如事務(wù)內(nèi)的所有語(yǔ)句只要你在一個(gè)顯式事務(wù)里哪怕全是 SELECT也應(yīng)該全走主庫(kù)。原因是事務(wù)的隔離級(jí)別和快照讀在從庫(kù)上可能拿到過(guò)期數(shù)據(jù)尤其主從延遲明顯的時(shí)候容易引發(fā)臟讀。所以 Atlas 在做路由決策時(shí)至少要參考這三個(gè)維度語(yǔ)句是否為SELECT、是否在事務(wù)中、語(yǔ)句是否包含鎖語(yǔ)義或函數(shù)調(diào)用。我見過(guò)不少業(yè)務(wù)事故都是因?yàn)闆]有處理事務(wù)內(nèi)路由比如先開啟事務(wù)插入數(shù)據(jù)再查詢剛插入的記錄結(jié)果查到了舊值因?yàn)椴樵冏吡藦膸?kù)而主從還沒同步。這類問(wèn)題非常隱蔽線上復(fù)現(xiàn)難用戶又催得急排查起來(lái)特別費(fèi)勁。路由策略還需要考慮主從延遲。正常情況下讀流量全部打到從庫(kù)無(wú)可厚非但一旦從庫(kù)延遲超過(guò)閾值比如 relay log 應(yīng)用積壓超過(guò)幾秒Atlas 最好把部分讀請(qǐng)求臨時(shí)切回主庫(kù)。我在配置里就預(yù)留了這樣的開關(guān)不是說(shuō)一定要用而是關(guān)鍵時(shí)刻能救命。2.2 分庫(kù)分表的規(guī)則設(shè)計(jì)與擴(kuò)容思路講完讀寫分離再聊分庫(kù)分表。Atlas 支持按某個(gè)字段做分片常見的就是哈希取模和時(shí)間范圍分片。哈希取模是最簡(jiǎn)單也最常用的方案。假設(shè)訂單表要拆成 16 張物理表分片鍵是訂單號(hào)路由算法就是hash(order_no) % 16。關(guān)鍵是選擇一個(gè)分布足夠均勻的分片鍵訂單號(hào)、用戶 ID 都算不錯(cuò)但如果你按地區(qū)分片就會(huì)出現(xiàn)頭部地區(qū)數(shù)據(jù)量巨大、尾部地區(qū)幾乎沒數(shù)據(jù)的傾斜問(wèn)題。這里我要提一個(gè)規(guī)劃層面的教訓(xùn)分片數(shù)一開始就要預(yù)留余量最好設(shè)置成 2 的冪次方比如 8、16、32。為什么因?yàn)楹竺鏀U(kuò)容時(shí)如果分片數(shù)不能按倍數(shù)擴(kuò)數(shù)據(jù)遷移的范圍會(huì)非常大。比如從 16 擴(kuò)到 24幾乎所有數(shù)據(jù)都要重新分布但從 16 擴(kuò)到 32則只有一半的數(shù)據(jù)需要遷移遷移邏輯也更簡(jiǎn)單。我做 Atlas 項(xiàng)目規(guī)劃時(shí)直接定成了 32 個(gè)分片初期只用 8 個(gè)分片剩下的暫時(shí)空著后續(xù)加機(jī)器直接把新分片啟用就行。分庫(kù)分表的代價(jià)也要提前想清楚?？绶制?JOIN 基本別想了IN 查詢需要拆成多個(gè)查詢?cè)僭趦?nèi)存里合并分布式事務(wù)需要業(yè)務(wù)方配合做最終一致性方案。我一般建議團(tuán)隊(duì)把分片邊界設(shè)計(jì)在業(yè)務(wù)層面比如同一個(gè)用戶的所有數(shù)據(jù)始終落在一個(gè)分片內(nèi)這樣大部分查詢都能限定在單分片內(nèi)執(zhí)行復(fù)雜度會(huì)小很多。2.3 連接池復(fù)用與高可用保障再說(shuō)連接管理。數(shù)據(jù)庫(kù)連接很貴從創(chuàng)建連接到認(rèn)證再到 MySQL 內(nèi)部分配線程、初始化會(huì)話開銷都不小。應(yīng)用側(cè)如果每個(gè)請(qǐng)求都新建連接數(shù)據(jù)庫(kù)很快就會(huì)被拖垮。Atlas 在中間層做了一件很巧妙的事它對(duì)外暴露的連接和后端實(shí)際建立的連接并不是一比一對(duì)應(yīng)的。應(yīng)用連上 Atlas 之后Atlas 從后端的連接池里取一條空閑連接出來(lái)復(fù)用請(qǐng)求處理完再把連接還回去。這樣一來(lái)后端只需要維持比應(yīng)用連接數(shù)少一個(gè)數(shù)量級(jí)的連接就能支撐大量并發(fā)請(qǐng)求。我實(shí)測(cè)過(guò)一個(gè)場(chǎng)景一個(gè)有 50 個(gè)節(jié)點(diǎn)的應(yīng)用集群原來(lái)每個(gè)節(jié)點(diǎn) 30 個(gè)連接直連時(shí) MySQL 要維持 1500 個(gè)連接接入 Atlas 后后端只保留了 200 個(gè)連接負(fù)載直接降下來(lái)一大截。高可用方面Atlas 會(huì)周期性對(duì)后端每個(gè)實(shí)例做健康檢查。檢查方式可以是很簡(jiǎn)單的SELECT 1也可以是自定義的探活語(yǔ)句。如果某個(gè)實(shí)例連續(xù)幾次失敗它會(huì)被標(biāo)記為不可用讀流量自動(dòng)轉(zhuǎn)移到其他可用節(jié)點(diǎn)。等到實(shí)例恢復(fù)健康會(huì)重新放回池子里。這套機(jī)制在從庫(kù)宕機(jī)、主從切換兩種場(chǎng)景下都非常有用。主從切換的場(chǎng)景尤其要小心。Atlas 必須具備配置熱更新的能力不然你手動(dòng)把主庫(kù)切換成了新機(jī)器中間件還傻傻地往舊地址發(fā)請(qǐng)求服務(wù)就全掛了。我的做法是在 Atlas 管理接口上預(yù)留動(dòng)態(tài)調(diào)整后端的命令切換完成后立刻更新后端節(jié)點(diǎn)列表不需要重啟進(jìn)程。3. 部署與實(shí)操全過(guò)程3.1 環(huán)境規(guī)劃與安裝前的準(zhǔn)備先看機(jī)器規(guī)劃這是我實(shí)際部署時(shí)用的一個(gè)標(biāo)準(zhǔn)方案大家可以參考角色機(jī)器配置數(shù)量說(shuō)明Atlas 節(jié)點(diǎn)4C8GSSD2一主一備Keepalived 做 VIP 漂移MySQL 主庫(kù)8C16GSSD1承載寫入流量MySQL 從庫(kù)8C16GSSD2承載讀流量延遲監(jiān)控監(jiān)控/日志機(jī)2C4G1收集 Atlas 日志和 MySQL 慢查詢安裝前有幾項(xiàng)系統(tǒng)設(shè)置必須處理否則 Atlas 跑起來(lái)就會(huì)出現(xiàn)各種莫名其妙的連接問(wèn)題。打開文件描述符上限修改/etc/security/limits.conf把nofile調(diào)高到 65535 以上不然高并發(fā)下會(huì)報(bào) “Too many open files”。關(guān)閉透明大頁(yè)數(shù)據(jù)庫(kù)鏈路對(duì)延遲敏感透明大頁(yè)會(huì)導(dǎo)致內(nèi)存分配不穩(wěn)定建議在/etc/rc.local里執(zhí)行echo never /sys/kernel/mm/transparent_hugepage/enabled。同步時(shí)間主從和中間件節(jié)點(diǎn)都要配置 NTP時(shí)間不一致會(huì)導(dǎo)致日志分析困難甚至認(rèn)證異常。Atlas 的運(yùn)行依賴 MySQL 客戶端庫(kù)和 glibc安裝前確認(rèn)系統(tǒng)里有l(wèi)ibmysqlclient.so沒有的話用系統(tǒng)的包管理器裝上即可。我用的是 CentOS 7.9直接安裝編譯好的二進(jìn)制包解壓到/usr/local/atlas沒有遇到依賴地獄的問(wèn)題。3.2 配置文件逐項(xiàng)解讀Atlas 的配置是我覺得整個(gè)項(xiàng)目里最值得花時(shí)間研究的部分。配置文件結(jié)構(gòu)不復(fù)雜但每個(gè)參數(shù)都暗藏玄機(jī)。我貼一份我實(shí)際使用的精簡(jiǎn)配置并逐個(gè)講解。[mysql] # Atlas 對(duì)外監(jiān)聽地址和端口 proxy-address 0.0.0.0:3306 # 后端 MySQL 實(shí)例列表主庫(kù)在前從庫(kù)在后 backend-address 10.0.0.11:3306 backend-address 10.0.0.12:3306 backend-address 10.0.0.13:3306 # 主庫(kù)標(biāo)識(shí)用于區(qū)分讀寫角色 master-address 10.0.0.11:3306 # 客戶端連接 Atlas 所需的賬號(hào) pwds admin:xxxxx # 管理接口地址和賬號(hào) admin-address 0.0.0.0:2345 admin-username admin admin-password xxxxx # 分庫(kù)分表規(guī)則文件 tables /usr/local/atlas/conf/table.rule # 日志配置 log-path /usr/local/atlas/logs log-level INFO # 主從延遲閾值超過(guò)則延遲讀切主 max-delay 5先看backend-address注意主庫(kù)要寫在前面還是后面其實(shí)不重要重要的是列表里必須包含主庫(kù)。master-address是單獨(dú)指定的Atlas 用這個(gè)字段來(lái)區(qū)分哪個(gè)實(shí)例承擔(dān)寫流量。從庫(kù)在列表里通常排在主庫(kù)后面。pwds這個(gè)字段很多人會(huì)踩坑它存的是加密后的密碼不是明文。我第一次配置時(shí)直接寫了明文結(jié)果客戶端連接一直認(rèn)證失敗。后來(lái)查了文檔才知道要先通過(guò)工具生成加密串再寫進(jìn)去。admin-address是中間件的管理口和業(yè)務(wù)端口分開防止外部誤連。日常運(yùn)維、查看狀態(tài)、動(dòng)態(tài)調(diào)整后端地址都靠這個(gè)端口。max-delay是主從延遲閾值單位是秒。前面提到過(guò)延遲超過(guò)閾值就要把讀流量切回主庫(kù)這個(gè)參數(shù)就是那套機(jī)制的觸發(fā)條件。設(shè)得太小會(huì)導(dǎo)致讀流量頻繁抖動(dòng)設(shè)得太大又會(huì)出現(xiàn)數(shù)據(jù)新鮮度問(wèn)題我一般從 5 秒開始調(diào)根據(jù)業(yè)務(wù)容忍度再動(dòng)態(tài)改。3.3 啟動(dòng)驗(yàn)證與壓測(cè)觀察配置完成之后啟動(dòng)過(guò)程非常簡(jiǎn)單執(zhí)行啟動(dòng)腳本就行。但啟動(dòng)成功不代表路由已經(jīng)符合預(yù)期必須做一套完整的驗(yàn)證。第一步用 MySQL 客戶端連接 Atlasmysql -h 127.0.0.1 -P 3306 -u admin -p能正常連上說(shuō)明基本鏈路通暢。第二步執(zhí)行SHOW DATABASES;能列出后端 MySQL 的真實(shí)庫(kù)說(shuō)明 Atlas 成功代理到后端實(shí)例。第三步驗(yàn)證讀寫分離是否真的生效。我在從庫(kù)上執(zhí)行下面的 SQL 來(lái)查看當(dāng)前連接來(lái)源SHOW PROCESSLIST;然后在應(yīng)用側(cè)不斷發(fā)起SELECT請(qǐng)求觀察從庫(kù)的Info字段里是否持續(xù)出現(xiàn)來(lái)自 Atlas 轉(zhuǎn)發(fā)的查詢。如果從庫(kù)一點(diǎn)動(dòng)靜都沒有大概率是路由配置有問(wèn)題所有流量都打到了主庫(kù)。緊接著做一輪簡(jiǎn)單壓測(cè)。我用 sysbench 造了大概 100 萬(wàn)條數(shù)據(jù)分別測(cè)試直連 MySQL 和通過(guò) Atlas 訪問(wèn)的吞吐差異。結(jié)果如下壓測(cè)場(chǎng)景連接數(shù)QPS 峰值平均延遲(ms)直連主庫(kù)2001200012走 Atlas 讀從庫(kù)2001050015走 Atlas 讀寫混合200830018看這個(gè)結(jié)果走 Atlas 后單次請(qǐng)求延遲確實(shí)有微幅上升大概 2 到 3 毫秒這是代理層的正常開銷。但換來(lái)的是整體連接數(shù)大幅下降后端單實(shí)例負(fù)載壓力小了很多系統(tǒng)的擴(kuò)展性和穩(wěn)定性才是更大的收益。3.4 業(yè)務(wù)接入與快速回滾策略驗(yàn)證通過(guò)后就是接業(yè)務(wù)。Atlas 最讓我喜歡的一點(diǎn)是業(yè)務(wù)接入成本幾乎為零只需要把應(yīng)用里的數(shù)據(jù)庫(kù)連接地址從原來(lái)的 MySQL 實(shí)例 IP 改成 Atlas 的地址即可。端口如果沒有特殊要求可以繼續(xù)用 3306 端口這樣連驅(qū)動(dòng)里的 URL 都不用改。不過(guò)接入順序還是有講究的。我建議先挑一個(gè)讀多寫少、不影響核心交易鏈路的服務(wù)做灰度跑一兩天觀察日志里有沒有路由異常、連接中斷、主從延遲導(dǎo)致的臟讀報(bào)警。確認(rèn)穩(wěn)定之后再逐步擴(kuò)大到所有服務(wù)?；貪L方案我一般提前準(zhǔn)備好。所有服務(wù)在變更配置時(shí)保留舊連接串一旦發(fā)現(xiàn) Atlas 這邊有問(wèn)題直接用發(fā)布系統(tǒng)回滾配置應(yīng)用連接重新指向原 MySQL 實(shí)例。整個(gè)回滾過(guò)程不會(huì)超過(guò)五分鐘中間件的無(wú)狀態(tài)特性在這里發(fā)揮了巨大作用因?yàn)?Atlas 本身不落業(yè)務(wù)數(shù)據(jù)回滾不會(huì)造成數(shù)據(jù)不一致。我還特意寫了一個(gè)一鍵回滾腳本核心就是把應(yīng)用配置里的atlas.host改回mysql.host然后重啟服務(wù)。這種看似很笨的方案在線上緊急故障時(shí)往往最管用。4. 常見問(wèn)題與排查技巧實(shí)錄4.1 高頻故障速查表我把這段時(shí)間遇到的問(wèn)題整理成了一張速查表按“現(xiàn)象 - 可能原因 - 解決思路”的方式排列方便大家直接對(duì)照?，F(xiàn)象可能原因解決思路客戶端連接 Atlas 報(bào)認(rèn)證失敗pwds里寫的是明文而非加密串用工具生成加密密碼后重寫配置應(yīng)用啟動(dòng)后查詢偶發(fā)超時(shí)后端連接池耗盡調(diào)大 Atlas 后端連接上限同時(shí)檢查 MySQL max_connections從庫(kù) CPU 飆高但主庫(kù)很低讀流量全部打到主庫(kù)檢查master-address配置以及路由規(guī)則主從切換后新主庫(kù)不接收寫請(qǐng)求Atlas 后端列表未更新通過(guò)管理接口動(dòng)態(tài)更新不需要重啟SELECT 查詢看到舊數(shù)據(jù)主從延遲超過(guò)容忍閾值調(diào)低max-delay或部分讀請(qǐng)求強(qiáng)制走主日志里大量連接被斷開后端 MySQLwait_timeout過(guò)短調(diào)整 MySQL 會(huì)話超時(shí)參數(shù)Atlas 進(jìn)程內(nèi)存持續(xù)增長(zhǎng)連接泄漏或慢查詢堆積排查慢 SQL定期釋放空閑連接每一個(gè)問(wèn)題我都在自己環(huán)境里踩過(guò)一兩遍尤其是主從切換后的寫請(qǐng)求丟失這個(gè)坑影響最大。當(dāng)時(shí)我以為 Atlas 會(huì)把新主庫(kù)自動(dòng)識(shí)別出來(lái)結(jié)果沒有因?yàn)樗恢滥阃獠恳呀?jīng)把主庫(kù)切換了。后來(lái)我在切換腳本里加入了通知 Atlas 更新后端的步驟才徹底解決。4.2 排查命令與日志分析實(shí)戰(zhàn)排查問(wèn)題不能瞎猜我分享幾個(gè)最常用的命令和方法遇到異常時(shí)可以快速定位。第一招連接 Atlas 管理端口看全局狀態(tài)。管理端口不是給業(yè)務(wù)用的是給運(yùn)維和管理員用的。登錄后直接輸入show status可以查看當(dāng)前的前端連接數(shù)、后端連接池使用情況、路由次數(shù)統(tǒng)計(jì)等。如果沒有這些指標(biāo)問(wèn)題的定位會(huì)非常困難。第二招看日志里的關(guān)鍵字。Atlas 的日志路徑在配置文件里可以指定正常運(yùn)行時(shí)輸出到/usr/local/atlas/logs。排查時(shí)重點(diǎn)看三類關(guān)鍵詞ERROR表示有請(qǐng)求執(zhí)行失敗TIMEOUT表示連接或查詢超時(shí)BACKEND表示后端實(shí)例的狀態(tài)變化。比如下面這行日志[ERROR] cannot get connection from backend pool, timeout這行日志一出現(xiàn)基本可以斷定是后端連接池滿了或者 MySQL 真的無(wú)法建立新連接。優(yōu)先檢查 MySQL 的max_connections和threads_connected再看 Atlas 到 MySQL 之間的網(wǎng)絡(luò)是否正常。第三招用tcpdump抓包看 SQL 流向。在執(zhí)行查詢的同時(shí)抓包能非常直觀地看到 SQL 到底發(fā)給了哪個(gè)后端 IP。這招在處理路由懷疑的爭(zhēng)論時(shí)最有效不靠猜直接看包。tcpdump -i eth0 -nn port 3306 -w atlas.pcap抓完之后用 Wireshark 分析可以看到每個(gè)連接的握手、查詢語(yǔ)句、響應(yīng)耗時(shí)。如果某個(gè) SQL 應(yīng)該走從庫(kù)但抓包發(fā)現(xiàn)反向了那路由配置肯定有問(wèn)題。4.3 獨(dú)家避坑心得最后分享幾個(gè)我在項(xiàng)目中總結(jié)的獨(dú)家經(jīng)驗(yàn)別的地方不一定能看到。第一分片鍵的選擇要有防御性。不要在項(xiàng)目初期圖方便選一個(gè)業(yè)務(wù)主鍵做分片業(yè)務(wù)主鍵往往帶有自增特性和局部性很容易出現(xiàn)熱點(diǎn)。我見過(guò)一個(gè)支付業(yè)務(wù)按照門店 ID 分片結(jié)果頭部門店數(shù)據(jù)量是尾部門店的幾百倍查詢嚴(yán)重傾斜。分片鍵要選訪問(wèn)頻率均勻、區(qū)分度高的字段。第二中間件節(jié)點(diǎn)不要跨機(jī)房部署。剛開始我圖省事把兩臺(tái) Atlas 分別放在兩個(gè)可用區(qū)想著提升容災(zāi)能力。結(jié)果發(fā)現(xiàn)跨機(jī)房的網(wǎng)絡(luò)延遲讓每次 SQL 轉(zhuǎn)發(fā)都增加了十幾毫秒應(yīng)用層受不了最后還是改回了同機(jī)房雙節(jié)點(diǎn)。想跨機(jī)房容災(zāi)應(yīng)該從數(shù)據(jù)庫(kù)層面做雙向同步而不是讓中間件跨機(jī)房轉(zhuǎn)發(fā)。第三升級(jí)和變更盡量在低峰期進(jìn)行。Atlas 的配置熱更新雖然是動(dòng)態(tài)的但涉及表規(guī)則變更這類重大調(diào)整時(shí)最好還是先灰度再全量。我在一次規(guī)則更新時(shí)因?yàn)樾屡f規(guī)則并行產(chǎn)生了歧義導(dǎo)致部分請(qǐng)求被路由到錯(cuò)誤的表雖然很快恢復(fù)了但那次教訓(xùn)讓我學(xué)會(huì)了中間件的變更要走和業(yè)務(wù)發(fā)布一樣的流程不能因?yàn)樗且粚哟砭偷粢暂p心。5. 寫在最后的一點(diǎn)體會(huì)做完 Atlas 這套中間層之后我對(duì)“數(shù)據(jù)庫(kù)治理”這件事的理解深了不少。以前總覺得數(shù)據(jù)庫(kù)不夠用就加緩存、加隊(duì)列、加機(jī)器實(shí)際上如果沒有一個(gè)統(tǒng)一的流量入口加再多資源也只是把問(wèn)題往后拖延。我個(gè)人的建議是如果你的系統(tǒng)已經(jīng)出現(xiàn)連接數(shù)打滿、讀寫混合導(dǎo)致鎖競(jìng)爭(zhēng)激烈、或者表數(shù)據(jù)量增長(zhǎng)速度明顯超過(guò)預(yù)期Atlas 這類中間件是一個(gè)非常值得考慮的分層方案。它不能解決所有問(wèn)題但它能讓數(shù)據(jù)庫(kù)拓?fù)涞淖兓辉贍縿?dòng)整個(gè)應(yīng)用側(cè)這一點(diǎn)在業(yè)務(wù)擴(kuò)張期尤其重要。最后再送一個(gè)小技巧投入運(yùn)行之后定期寫一個(gè)檢查腳本去從庫(kù)看真實(shí)流量分布。別只依賴 Atlas 自己的統(tǒng)計(jì)真實(shí) SQL 的執(zhí)行情況會(huì)告訴你很多中間件日志里看不到的細(xì)節(jié)比如哪些表才是真正的熱點(diǎn)、哪些查詢?cè)摫痪彺娑底?。掌握了這些一手?jǐn)?shù)據(jù)你才能把 Atlas 的路由規(guī)則調(diào)得越來(lái)越聰明。