騰訊雲帳號快速認證 騰訊雲 CDB 實例唯讀唯寫分離（RO組）負載不均排查

問題現象與背景：RO 組負載不均

讀寫分離是擴展資料庫讀能力的常用手段。在騰訊雲 CDB for MySQL 中，透過建立 RO 組並給出一個對外的讀端節點，流量會依權重與健康策略分配到多個唯讀實例。然而，實際運行中常見的情況是：明明有兩三台唯讀庫，卻總有一台吃滿 CPU/QPS，其他機器空閒，應用延遲也被這台最忙的 RO 拉高。這類負載不均，既可能來自雲端分發策略配置，也可能源於應用層路由、連接池黏性、查詢特徵或資料熱點。

本文梳理 RO 組負載不均的典型症狀、成因圖譜與逐步排查方法，配合實操建議與案例，幫你快速定位並修復不均衡。

讀寫分離與 RO 組工作機制簡述

理解機制是定位的前提。CDB RO 組通常提供一個讀端接入點，後端掛載多個唯讀實例。核心要素：

• 權重：每個唯讀實例可配置權重，權重越高分流越多，權重為 0 則不分配。
• 騰訊雲帳號快速認證 延遲剔除：當複製延遲超過閾值，節點會暫時退出負載，避免讀到陳舊資料。
• 連線級分流：多數場景以連線為粒度做負載均衡，單一連線建立後路徑固定。
• 事務與一致性：事務內讀通常走主庫或固定路徑；強一致讀（讀寫之後強一致）也可能回落到主庫。

以上任何一項配置或行為不當，都可能導致表面上的「負載不均」。

快速體檢：三分鐘判斷是不是「假負載不均」

先做最小成本的判斷：

• 確認觀測窗口：同一時間段對比 RO 實例的 QPS、CPU、Threads_running、網路吞吐、慢查比例。若僅僅是單台出現長查或鎖等待，可能屬於瞬時業務特徵而非分配問題。
• 判斷連線數：如果單台 RO 連線數顯著高於其他（成倍差距），更可能是連線級分流與連接池黏性引起。
• 排除規格差：不同規格機器設置了相同權重也會出現負載差；先核實規格與權重是否匹配。
• 看延遲剔除：若某台因延遲退出負載，其他機器自然被打滿，這是保護機制而非不均衡。

若以上快速檢核仍顯示穩定的分流偏斜，則進入深入排查。

常見成因拆解

應用側連接池與長連線黏性

RO 組多以連線為單位做負載均衡。大量長連線在應用啟動早期建立，可能被分配到同一或少數 RO，後續流量就粘在這些連線上。常見表現：

• 騰訊雲帳號快速認證 某台 RO 的連線數、QPS、CPU 持續遠高於其他。
• 在應用重啟或擴容之後，負載分佈型態突然改變。

連線釘住後，即使其他 RO 空閒，請求也不會自動遷移。這是最常見的根因之一。

驅動或中間件讀寫策略錯配

框架或中間件（例如部分讀寫分離插件）可能存在以下問題：

• 事務內全部讀寫走主庫，或因配置誤將讀請求導入單一唯讀節點。
• 基於 SQL Hint 的分流規則不完整，將某些查詢固定到特定節點。
• 強一致讀時間窗過長，導致大量讀回落到主或單一可用 RO。

騰訊雲帳號快速認證 如果應用或中間件自行做了二次路由，但規則沒有考慮 RO 組權重與健康狀態，就可能與雲端負載策略打架。

權重與延遲剔除策略配置不當

常見錯誤配置包括：

• 不同規格 RO 設置相同權重，導致小機器被打爆或大機器吃不飽。
• 延遲閾值過緊，某些 RO 長期被剔除；或過鬆，個別 RO 讀到陳舊資料後被中間件屏蔽。
• 權重變更未生效到既有長連線，需要配合重建連線才會體現。

規格差異、資料傾斜與熱點鍵

即使分配均衡，查詢本身也可能呈現不均：

• 熱點主鍵或索引熱區導致某些查詢更耗算力，落到某台 RO 時容易引起瞬時飽和。
• 不同 RO 的 I/O 子系統表現有差（雖同規格但底層負載不同），在高峰時放大差異。

負載不均不一定是分流問題，也可能是資料與查詢分佈問題。

長查詢、臨時表與鎖爭用

長時間運行查詢會佔滿 CPU 與連線。某台 RO 上幾個慢查即可壓住整體吞吐，造成看似不均衡。此外，大量建立臨時表、排序與 filesort，會使單台 RO 受傷更重。

延遲與只讀庫不可讀

複製延遲超過閾值時，該 RO 會退出分流。如果多台 RO 先後因延遲退出，剩餘一台承壓會導致負載集中。延遲的根因可能是主從複製壓力、長事務或大表 DDL。

DNS/Endpoint 緩存與解析行為

若讀端接入點透過域名解析，應用容器或運行時對 DNS 的緩存與刷新策略會影響分流結果。極端情況下，所有應用副本解析到同一後端位址，形成嚴重偏斜。

排查步驟詳解

步驟一：觀測 CDB 指標

登錄監控後對比每個 RO 實例的：

• QPS/TPS、連線數、CPU、IOPS、網路吞吐。
• Threads_running、Threads_connected、平均延遲。
• 複製延遲與延遲剔除事件次數。

觀測重點是跨實例的相對差異，以及是否與業務高峰吻合。

步驟二：應用端可觀測性

在應用側拉取連接池分佈與活躍連線數，按實例維度統計。

指標示例：
- 每個資料庫連線串的活躍連線數
- 每個連線平均持續時間/閒置時間
- 不同節點的錯誤率/延遲分佈

如果應用層沒有記錄目標節點，可暫時在驅動層加上連線握手日誌或查詢路由日誌，短時期收集樣本。

步驟三：SQL 層面分析

進入負載高的 RO，檢視當前執行與慢查：

SHOW PROCESSLIST;
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;

關注長查、熱表、未命中索引與臨時表情況，同時比對另一台 RO 的同樣輸出，確認是否為查詢結構導致的不均。

步驟四：複製與延遲

在 RO 查複製狀態：

SHOW SLAVE STATUS\G

關注 Seconds_Behind_Master、延遲峰值與是否存在阻塞（如 Relay Log Apply 卡住）。若延遲頻繁高於閾值，RO 被剔除將導致其他機器承壓。

步驟五：網路與解析

確認應用運行環境的 DNS 解析與快取策略，觀察是否所有 Pod/實例解析到相同後端。短時將應用副本分批重啟或刷新 DNS 快取，觀察負載是否重新分配。

典型處理方案

騰訊雲帳號快速認證 調整 RO 權重與延遲閾值

• 按規格分配權重：計算型、內存型、磁碟型能力不同，權重需按 CPU 核數與 I/O 能力加權。
• 延遲閾值合理化：業務能容忍的讀陳舊程度不同。設太緊會頻繁剔除，設太鬆又會讀到過期數據。建議結合 P95 延遲、二級緩存策略與一致性需求調整。
• 變更後安排連線重建：讓新權重迅速生效。

騰訊雲帳號快速認證 連接池與路由優化

• 降低長連線黏性：在低峰分批重建連線，避免所有連線集中建立在某一台 RO。
• 連線預熱與分散：應用擴容時，控制副本啟動節奏，讓連線建立更隨機。
• 縮短 Keep-Alive：在不影響效能前提下，縮短閒置連線回收時間。
• 騰訊雲帳號快速認證 事務邏輯梳理：非必需的事務內讀移出事務；必要時在框架層標註只讀事務。
• 遵循雲側路由：避免中間件自定義將讀固定到少數節點，盡量讓 RO 組做統一分發。

查詢優化與熱點拆分

• 優化慢查：補索引、調整 SQL、避免全表掃描與過大排序。
• 拆分熱點：將熱門 key 做緩存、分桶或限流，削峰填谷。
• 騰訊雲帳號快速認證 減少臨時表與大排序：調整 sort_buffer、合理使用覆蓋索引，必要時加冗餘列避免回表。

版本與規格加固

• 規格不匹配時，提升吃緊 RO 的規格，並同步調整權重。
• 發現 I/O 成為瓶頸，考慮升級磁碟型號或讀寫分拆到更多 RO。

故障時的回退與保護

• 臨時調整權重：短時降低問題 RO 的權重，讓流量遷移。
• 只讀節點下線維護：出現長查與延遲時，先下線該 RO，清理慢查後再加入。
• 應用側熔斷與重試：對特定 RO 異常延遲或錯誤率升高時，開啟熔斷，避免雪崩。

案例：雙 RO 組負載 8:2 的修復過程

背景：一個核心服務接入兩台 RO，權重各 50。業務高峰時，RO-A 的 QPS 約為 RO-B 的 4 倍，CPU 長期 80% 以上，延遲抖動明顯。

排查過程：

1. 監控對比顯示 RO-A 連線數為 RO-B 的 3 倍，兩台規格一致，無明顯延遲剔除事件。
2. 應用側統計顯示，部署在某一可用區的 60% 副本在啟動時建立了大量長連線，且恰好解析到 RO-A 的後端位址。
3. SHOW PROCESSLIST 顯示 RO-A 上多個耗時查詢，同類查詢在 RO-B 上數量明顯更少，印證連線黏性。
4. 短時在低峰分批重啟部分應用副本，並調整連接池閒置回收時間，促使連線重新分配。
5. 將 RO-B 權重暫調高至 70，觀察 10 分鐘後兩台 QPS 接近平衡。
6. 恢復權重至 50/50，保留連線優化策略，負載最終穩定在 55/45 波動。

結論：主要根因為長連線在應用擴容時集中建立於單一後端；輔因為缺乏連線回收，導致權重調整難以及時生效。措施包括連線分散、分批重建、臨時權重偏置，快速恢復均衡。

預防與日常運維建議

• 建立啟動節奏：批次拉起應用副本，避免瞬時大量連線落到同一後端。
• 指標對齊：應用側暴露按後端統計的連線數與錯誤率，與雲側監控對標。
• 慢查治理常態化：每週滾動清理 Top 慢查，避免偶發慢查演變成結構性不均。
• 權重版本化：變更權重與延遲閾值納入變更單與回退手冊，配合灰度實施。
• 壓測與演練：在壓測環境模擬 RO 剔除、延遲升高、熱點流量，演練自動化回退與熔斷。

常見誤區與迷思

• 誤以為改權重立刻見效：連線級分流下，權重改動對既有長連線不生效，需配合連線重建。
• 以為數量多就均衡：若 RO 相互規格差異大，對半分配反而降低整體吞吐。
• 忽視事務：事務內讀或強一致讀回落主庫，會擠占主庫資源，且掩蓋真正的讀負載走向。
• 把問題歸咎於「雲端 LB 不均」：多數案例根因在應用連接池、查詢結構與權重配置。

自檢清單

[配置]
- RO 權重是否與規格匹配？
- 延遲剔除閾值是否合理？
- 權重變更後是否重建連線？

[連線]
- 各 RO 連線數是否均衡？
- 連線平均持續時間是否過長？
- 應用擴容是否分批啟動？

[查詢]
- Top 慢查是否集中於單一 RO？
- 熱點鍵/熱門表是否已拆分或緩存？
- 臨時表與排序是否過多？

[複製]
- Seconds_Behind_Master 是否頻繁超閾？
- 有無長事務阻塞複製？

[網路/DNS]
- 是否存在偏向某一後端的解析？
- 容器或運行時 DNS 快取是否過長？

當上述各項達到可視、可控與可回退，RO 組讀負載才能在高峰下保持穩定與高效率。

結語

RO 組負載不均並非單一層面的問題，而是配置、連接、查詢與資料特徵的綜合作用。以連線為核心觀測對象，配合權重與延遲策略調整，再加上持續的慢查治理與熱點拆分，往往能在最短時間內把不均衡拉回合理區間。把這套方法論沉澱為日常運維流程，才能在業務節奏加速時，讓讀寫分離真正發揮價值。