主從複製延遲的本質成因
在標準的主從讀寫分離架構中，所有寫入操作均在 Master 節點執行，並透過非同步或半同步機制將預寫式日誌（WAL / Binlog）傳輸至 Slave 唯讀節點。當 Master 發生大批量資料匯入、長交易提交或 Slave 節點遭遇 I/O 瓶頸時，Replication Lag 可能由數毫秒暴增至數秒甚至數十秒。此時使用者在前台提交訂單後立即刷新頁面，若請求被路由至 Slave，將會出現「訂單消失」或「餘額未扣除」的假象，造成客戶信任危機。
工程解決方案：精準路由與 Pinning 機制
要解決主從延遲引起的讀取不一致，不能盲目將所有查詢全部轉發回 Master（這會喪失讀寫分離的意義）。業界成熟的解決策略包括： 1. 寫入後時間窗鎖定（Write-After-Read Pinning）：當某個用戶端剛執行過寫入操作時，在 Session 或 Token 中標記時間戳記，在隨後的 2-3 秒內，該特定用戶端的所有讀取強制路由至 Master 節點，其他訪客仍走 Slave。 2. 基於 GTID 的一致性讀取（Wait For Executed GTID）：應用層在讀取 Slave 時帶入剛剛寫入成功返回的 GTID 位置，要求 Slave 必須回放進度達到該 GTID 後方可返回查詢結果。 3. 業務分類與容忍度隔離：嚴格區分「強一致性業務」（如支付結算、密碼修改、庫存核銷）與「最終一致性業務」（如歷史帳單查詢、商品評論列表），前者永久綁定 Master，後者充分利用 Slave 節點的橫向擴展能力。
架構師的省思：何時不該過早引入讀寫分離
許多團隊在資料庫出現效能問題時，第一反應就是加開唯讀副本。然而根據我們的顧問診斷經驗，超過半數的情況下，資料庫負載過高是因為缺乏有效索引或存在大量 N+1 查詢。在未將慢查詢優化至極限前過早引入讀寫分離，往往只會引入分散式一致性複雜度，而未能真正解決性能根源。