雙寫一致性問題的本質與場景

雙寫一致性指的是當修改數據庫數據時，也需要同步更新緩存數據，確保緩存和數據庫的數據保持一致。這一問題在高并發場景下尤為突出，據統計，電商大促期間因緩存不一致導致的訂單異常可達總故障的37%。

典型不一致場景分析

??并發寫操作導致的不一致??

線程A更新數據庫為100，開始更新Redis時出現卡頓
線程B更新數據庫為80，并成功更新Redis為80
線程A恢復后繼續更新Redis為100
最終結果：MySQL=80，Redis=100，數據不一致

??讀寫交叉導致的不一致??

線程A更新數據庫為99
線程B從Redis讀取舊值100
線程A刪除Redis緩存
最終用戶B獲得過期數據

??主從同步延遲導致的不一致??

主庫更新后立即刪除Redis緩存
從庫尚未同步最新數據
查詢請求從從庫讀取舊數據并回填Redis
導致Redis中保留舊數據

解決

延遲雙刪策略（推薦）

在更新數據庫前后各刪除一次緩存，第二次刪除采用延遲方式（??考慮到主從同步延遲??和??并發讀寫競爭??）

優點??：

• 實現相對簡單
• 性能影響較小
• 保證最終一致性

??缺點??：

• 無法保證強一致性
• 延遲時間難以精確設定(需考慮主從同步時間)
• 吞吐量會降低
• ??適用場景??：允許數據短暫不一致、對性能要求較高的場景，如文章瀏覽量更新

分布式讀寫鎖方案

??核心思想??：通過讀寫鎖控制并發訪問，讀操作加讀鎖，寫操作加寫鎖

優點??：

• 保證強一致性
• 從根源避免讀寫并發問題

??缺點??：

• 性能影響較大(吞吐量可能下降40%-60%)
• 代碼侵入性強
• 鎖競爭可能導致延遲
• ??適用場景??：金融交易、賬戶余額等對一致性要求極高的系統

消息隊列異步補償

??核心思想??：通過消息隊列(MQ)保證緩存操作最終執行

數據庫 → Binlog → 消息隊列 → 緩存更新Worker → Redis