一、前言
- 初始阶段，业务量小，直接操作数据库。
- 业务增长，引入缓存提高性能，但引发数据一致性问题。
二、数据一致性问题
- 双写操作可能导致缓存与数据库数据不一致。
- 并发读写操作难以保证操作顺序，容易产生脏读。
三、一致性类型
- 强一致性：写入即读出，但影响性能。
- 弱一致性：写入后不立即保证读到最新值，但最终会一致。
- 最终一致性：保证在一定时间内数据达到一致状态，适用于大型分布式系统。
四、情景分析
- 读场景：通常不会引起数据不一致。
- 写场景：需同时更新缓存和数据库，注意并发操作导致的问题。
五、同步策略
- 先更新缓存，再更新数据库：不推荐，可能导致数据不一致。
- 先更新数据库，再更新缓存：不推荐，可能读到旧数据。
- 先删除缓存，后更新数据库：可能数据不一致，使用延时双删策略减少风险。
- 先更新数据库，后删除缓存：推荐方案，但也可能失败。
六、解决办法
- 双写一致性：业务代码中同时更新MySQL和Redis，需检测和修复数据不一致。
- 异步更新（异步通知）：数据库更新后，异步通知Redis删除旧数据，降低不一致风险。
- 使用Redis的事务支持：事务确保MySQL和Redis的原子更新，但非严格ACID。
- 用Redisson实现读锁和写锁：控制并发，保证写操作时数据一致性。
七、总结
- 根据业务需求和系统环境，选择合适方案提高数据一致性。
- 对于并发几率小的数据，可以容忍短时间不一致，使用缓存过期时间策略。
- 对于高并发容忍度低的业务，需采用更严格的一致性保证措施。
八、注意事项
- 每种方案都有优缺点，需综合考虑。
- 业务容忍度和系统性能需权衡。
