redis和mysql缓存一致性
一、单点（推荐先更新数据库，在延时删除缓存）
这也有不一致概率的问题，但是很小 为什么说此方案可行？因为更新请求会给数据库加锁，查询不会，查询请求比更新请求快，很少出现上图情况 大概率流程是下面 更高保证：请求B更新数据库后，线程B sleep几百毫秒，等请求A将旧值写完之后，让线程B醒过来删除缓存
1. 不推荐先更新缓存，在更新数据库
更新缓存成功，更新数据库失败，数据库回滚，还得回滚缓存，而且缓存不是简单的数据，还可能经过复杂的计算结果缓存到redis中。数据库回滚，前面的计算白算啦。此外持久化方面，数据库的持久化做的比缓存好些，而且存储以数据库为中心，先更新数据库，在怎样怎样…
2.不推荐先更新数据库，在更新缓存
3.不推荐先删除缓存，在更新数据库
二、读写分离（主从架构模式）
如果对数据一致性要求很高，此时线程B读取数据的时候，不去从库查，一直去主库查，因为主库始终是最新数据 改进后的流程 如果网络拥堵或网络中断，更新redis缓存失败如果处理 消息队列有持久化机制，保证数据不会丢，顺序不会乱，消费消息队列不成功，还可以重复消费，可以做到系统的高可用，订阅binlog日志顺序性，采用单线程去订阅
上一篇：
Java基础知识总结（2021版）
下一篇：
华为机试3——工程最大利润