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 节点中。
