Mysql与Redis如何保证数据的一致性？
2020-09-12 13:57:00
MySQL与Redis保证数据一致性，主要涉及最终一致性和强一致性两种策略，具体实现需结合业务场景权衡性能与数据准确性。以下是详细方案：
一、最终一致性：容忍短时不一致，最终达到一致适用于对实时性要求不高的场景，通过设计减少不一致的时间窗口。
1. 先删除Redis缓存，后更新MySQL- 问题：高并发下可能读到脏数据。
删除缓存后，未完成数据库更新时，其他请求发现缓存为空，从数据库读取旧数据并写入缓存，导致脏数据。
- 优化方案：
双删策略：
删除Redis缓存。
更新MySQL数据库。
延迟一段时间（如1秒）后再次删除Redis缓存（确保其他请求已完成数据库读取并写入缓存）。
读写分离场景：
若MySQL使用主从架构，查询请求可能从从库读取到旧数据。此时需强制查询主库填充缓存。
- 问题：极端情况下缓存未删除成功。
数据库更新完成后，线程宕机导致缓存未删除，后续请求持续读取旧缓存。
- 优化方案：
消息队列补偿：
更新数据库后，尝试删除缓存。
若删除失败，将缓存Key发送至消息队列（如RabbitMQ）。
消费者监听队列并重试删除缓存。
缺点：业务代码与补偿逻辑耦合，需额外维护消息队列。
适用于对实时性要求极高的场景，通过技术手段确保缓存与数据库同步更新。
1. 订阅MySQL Binlog实现同步- 原理：利用MySQL的Binlog（二进制日志）记录所有数据变更，通过监听Binlog实时更新Redis。
- 实现工具：
Canal：阿里开源的Binlog解析组件，模拟MySQL从库行为，订阅主库Binlog并解析为JSON格式，推送至消息队列或直接更新Redis。
Maxwell：轻量级Binlog解析工具，支持将数据变更写入Kafka、RabbitMQ等消息队列，再由消费者更新Redis。
- 流程：
MySQL开启Binlog（需配置log-bin=mysql-bin）。
Canal/Maxwell监听Binlog变更事件。
解析变更事件并生成Redis更新命令（如SET key value）。
执行Redis更新操作。
- 原理：通过两阶段提交（2PC）或三阶段提交（3PC）协议，确保数据库与缓存的原子性操作。
- 缺点：
性能开销大，高并发场景下延迟高。
需协调多个系统，实现复杂。
- 适用场景：金融等对数据一致性要求极高的领域。
- 集群部署：
使用主从复制（Master-Slave）或哨兵模式（Sentinel）提高可用性。
读写分离：写请求发往主节点，读请求分散至从节点。
- 持久化策略：
RDB：定时生成数据快照，适合数据恢复但可能丢失最后一次快照后的数据。
AOF：记录所有写操作命令，支持appendfsync always/everysec/no三种模式，平衡性能与数据安全性。
混合模式：结合RDB与AOF，兼顾恢复效率与数据安全。
- 缓存雪崩：
现象：大量缓存同时失效，请求直接打入数据库，导致数据库崩溃。
解决方案：
随机过期时间：为缓存Key设置随机过期时间，避免集中失效。
多级缓存：使用本地缓存（如Caffeine）与分布式缓存（如Redis）分层存储。
- 缓存穿透：
现象：查询不存在的数据，缓存未命中且数据库也无数据，导致每次请求均访问数据库。
解决方案：
布隆过滤器：预存所有可能存在的Key，查询前先过滤非法Key。
空值缓存：对数据库查询为空的Key设置短时间缓存（如1分钟），避免重复查询。
- 最终一致性：适合大多数业务场景，通过双删、消息队列补偿或Binlog同步实现。
- 强一致性：需牺牲部分性能，通过分布式事务或Binlog实时同步满足严格要求。
- 高可用设计：结合Redis集群、持久化策略及缓存防护机制，确保系统稳定运行。
实际选择方案时，需根据业务对一致性的容忍度、系统性能要求及运维成本综合评估。
热门标签
