MySQL 5.7 增強版 Semi-sync Replication 性能優化深度解析

MySQL 5.7 版本對半同步複制進行了重大架構升級，針對舊版本中「傳送 binlog」與「等待 ACK」串行執行的瓶頸，引入了異步化發送機制與事務提交前等待 ACK 兩大核心優化，顯著提升了高併發場景下的事務吞吐量（TPS）。本文將深入剖析這兩項改進的技術原理與實際效能提升。

一、背景與痛點：傳統半同步的性能瓶頸

在 MySQL 5.5/5.6 時代，半同步複制的運作邏輯是：主庫寫入 binlog 後，由 dump 線程同步發送至從庫，並阻塞等待從庫回傳「已寫入 relay log 並刷盤」的 ACK 確認，才向會話層返回提交成功。這一過程中，dump 線程獨自承擔「發送 binlog」與「接收 ACK」兩項高頻任務，且強制串行執行——必須等待上一筆事務的 ACK 返回，才能發送下一筆。在高併發業務場景下，網絡延遲與從庫處理時間被放大，dump 線程成為系統 TPS 的核心瓶頸。

二、核心優化一：發送 Binlog 與接收 ACK 異步化

MySQL 5.7.4 重構了半同步框架，引入專門的 ACK Collector 線程，實現「發送」與「接收」的解耦並行：

• Dump 線程：專注於將 binlog 事件組裝發送給從庫，不再阻塞等待 ACK，可持續推流後續事務的 binlog（支援 Group Commit 批次發送）。
• ACK Collector 線程：後台運行，使用 select 監聽所有從庫連接的 socket，專職接收從庫回傳的 ACK 確認。

這一設計利用 TCP 全雙工特性，讓讀寫 socket 同時進行。主庫啟用半同步時即啟動 Collector 線程，從庫 IO 線程照常交互。實測顯示，異步化後主庫不再因單一從庫延遲而阻塞整個複制管道，TPS 提升顯著。

三、核心優化二：事務提交前等待 ACK（rpl_semi_sync_master_wait_point）

新增參數 rpl_semi_sync_master_wait_point 控制主庫在什麼時機等待 ACK，提供兩種模式：

1. AFTER_SYNC（預設值，強一致性）

• 主庫寫入 binlog → 發送至從庫 → 刷盤（sync binlog）
• 等待從庫 ACK（已收到並寫入 relay log 刷盤）
• 主庫本地提交事務 → 返回客戶端成功

特性：所有客戶端看到的已提交數據均已雙副本落盤。主庫崩潰時，所有已提交事務必然存在於至少一台從庫，切換後數據零損失，適合金融級強一致性場景。

2. AFTER_COMMIT（高性能，弱一致性）

• 主庫寫入 binlog → 發送至從庫 → 刷盤
• 主庫先本地提交事務
• 提交後等待從庫 ACK
• 收到 ACK → 返回客戶端成功

特性：主庫提交不阻塞於網絡往返，TPS 更高。但若主庫在提交後、從庫 ACK 前崩潰，且故障轉移至該從庫，應用層會發現「主庫已提交、從庫未應用」的數據不一致（即「牆頭事務」），需業務層或校驗機制修復。

四、總結與建議

MySQL 5.7 通過「異步化發送/接收」破解了 dump 線程串行瓶頸，通過 wait_point 參數讓業務在「強一致性」與「高吞吐」間靈活權衡。建議：

• 核心交易、資金系統：堅持 AFTER_SYNC，配合 sync_binlog=1、innodb_flush_log_at_trx_commit=1。
• 高併發讀寫混合、可容忍極低概率不一致的業務：嘗試 AFTER_COMMIT，並建立主備數據校驗定時任務。
• 升級前務必全鏈路壓測，驗證網絡抖動、從庫延遲對主庫 TPS 的實際影響。