MySQL 與 Redis 數據保持一致性是一個常見且復雜的問題，一般來說需要結合多種策略來平衡性能與一致性。
傳統的解決策略是先讀緩存，未命中則讀數據庫并回填緩存，但方式這種維護成本較高。
隨著云數據庫技術的發展，目前國內云廠商數據庫很多采用磁盤 kv 存儲，內存+磁盤結合的方式來解決這個問題。
比如百度智能云的 PegaDB、騰訊的 KeeWiDB 等等。
傳統解決策略與挑戰
在多地域數據管理中，保持數據的同步性常常著面臨諸多挑戰。不同地域的數據信息同步需要使用專業的數據復制和同步工具（如 GoldenGate、SharePlex 等）手動寫入，并且操作過程中需要專業人員執行、維護。此外，還有一種方法是將數據庫的事務日志定期或實時傳輸到遠程地點，然后在遠程數據庫上重放這些日志來實現數據同步。盡管這種方法可以在不同地域之間同步數據，但整個過程復雜性高、時間周期長。
百度智能云 PegaDB 解決方案
Redis 容量型（PegaDB）自研多活實例組產品。多活實例組由至多 5 個實例組成, 每個實例均可以進行本地域讀寫。無需專業人員手動寫入、維護，每個地域數據由同步組件自動化同步至其他地域，省時省力。多活實例組應用場景如下：
-
異地多活: 業務需求應用就近訪問同時數據整體一致。
-
數據災備: 可實現同城災備、兩地三中心災備及三地災備等多種數據災備場景。
百度智能云數據庫 Redis 容量型（PegaDB）異地多活同步通道單向可達 5 萬 QPS。本地域讀寫與單實例的延遲基本一致。跨地域間同步，延遲幾十毫秒至幾百毫秒。不僅通過異地多活的架構設計解決了多地域數據同步一致性的問題。同時，數據自動化同步至其他地域，無需專業數據復制與同步工具手動寫入，節省了人力成本。
具體實現
-
在異地多活集群中，每個實例都會為其配置一個數據同步組件，這個同步組件的叫做 SyncAgent。單個分片內部，只有主節點的 SyncAgent 會工作。SyncAgent 會解析 Redis 生成的 AOF 并將增量的 AOF 同步到目標集群。
-
當 SyncAgent 故障重啟后，SyncAgent 需要繼續從之前的同步位點繼續同步，這就需要對 AOF 中的每一條命令增加一個編號。在 PegaDB 架構中，引入了一個叫 operator header 的結構。有了 op header 后，SyncAgent 就可以記錄下 opid 來追蹤同步進度了。
-
當 SyncAgent 啟動后，它會嘗試獲取同步點，并且在工作過程中，會周期性地記錄更新后的同步點，而這些信息可以存儲在一個 PegaDB 節點中。
