5.5/5.6 半同步的效能痛點

舊架構中 Dump Thread 獨攬兩項串行任務：
1. 發送 Binlog 給 Slave。
2. 同步等待 Slave ACK。
高併發下 Dump Thread 成為單點瓶頸，TPS 明顯下降。

增強一：ACK Collector 線程 —— 發送與接收解耦

5.7.4 引入專用 ACK Collector Thread：

• Dump Thread 專心發送 Binlog（Group Commit 批次）。
• ACK Collector 以 select() 多路復用監聽所有 Slave Socket，非阻塞接收 ACK。
• 雙線程並行，發送不再阻塞於等待，TPS 大幅提升。

增強二：rpl_semi_sync_master_wait_point —— 控制等待時機

新參數控制 Master 在事務生命週期的哪個節點等待 ACK：

值	行為	資料安全性	適用場景
AFTER_SYNC (預設)	寫 Binlog → 刷盤 → 發送 Slave → 等待 ACK → Commit → 回覆 Client	最高：Master Crash 時，已 Commit 事務必在至少一 Slave Relay Log 持久化	金融、核心交易、強一致性要求
AFTER_COMMIT	寫 Binlog → 發送 Slave → Commit → 等待 ACK → 回覆 Client	略低：Master Crash 後 Failover 到 Slave，可能出現 Master 已 Commit 但 Slave 未 Apply 的「幻讀」窗口	高併發、可容忍極小窗口不一致、追求極致 TPS

其他 5.7 改進（略）

• Server 層預判 Slave 是否需半同步，減少 Plugin 鎖衝突。
• 解除 Binlog Dump Thread 與 LOCK_log 爭用。

配置建議

[mysqld]
plugin-load-add=rpl_semi_sync_master=semisync_master.so
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_wait_point=AFTER_SYNC  # 或 AFTER_COMMIT
rpl_semi_sync_master_timeout=1000  # ms，超時自動降級異步
rpl_semi_sync_slave_enabled=1

決策指引

1. 核心交易、資金系統 → AFTER_SYNC，寧可犧牲些許延換資料零遺失。
2. 高併發非核心業務（Feed、日誌、統計）→ AFTER_COMMIT，榨乾吞吐。
3. 監控 Rpl_semi_sync_master_wait_sessions、Rpl_semi_sync_master_tx_wait_time 觀察等待分佈。