如何实现MySQL和Redis的数据一致
缓存一致性问题是什么？
如果缓存加载了数据源的数据，但对应数据要发生变化
首先是以旁路缓存模式（cache aside）为基础，来进行分析。
大方向有三个：
- 更新MySQL即可，不管Redis，以过期时间兜底
- 更新MySQL之后，操作Redis
- 异步将MySQL的更新同步到Redis
1.过期时间兜底
使用Redis的过期时间，MySQL更新时Redis不做处理，等待缓存过期失效，再从MySQL拉取缓存
优点：
- Redis原生接口，开发成本低，易于实现；
- 管理成本低，出问题概率小
缺点：
- 完全依赖过期时间，时间太短容易造成缓存频繁失效；时间太长容易有较长时间不一致，脏数据多。
2.操作Redis
不光用Redis过期时间兜底，还需要在MySQL更新时，同时尝试操作Redis；
操作Redis的方式分两种，一种是更新Redis，一种是删除Redis，等待下次访问再加载回来
更新Redis：可能会因为网络延迟，出现时序性问题，一般不用。
删除Redis：只添加了删除逻辑，还减少了数据不一致的时间，即使删除失败也有过期时间兜底
3.异步更新Redis
通过引入消息队列来处理。消息队列的作用是将数据变化的事件通知到各个服务节点，实现异步的数据同步。
- 当 MySQL 中数据发生变化时，监听bin log日志，解析日志将操作（如数据插入、更新、删除）以事件的形式推送到消息队列。
- 消费端监听消息队列，接收变更事件后，根据事件类型，决定是更新 Redis 缓存中的数据，还是删除缓存
优点：
- 和业务完全解耦，在更新MySQL时，不需要做额外操作
- 无时序性问题，可靠性强
缺点：
- 引入了消息队列这种比较重的组件，还需要搭建一个同步服务，维护需要额外成本
- 如果同步服务压力大，崩溃了，那么在较长时间内，Redis都是老旧数据
总结
这个问题没有标准答案，主要聊得是思路和解决方案，并结合业务场景说出为什么选择这个方案，
不同方案的优缺点对比。
原文地址：https://blog.csdn.net/Junhe4512/article/details/142299137
免责声明：本站文章内容转载自网络资源，如侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！