- 服务器访问速度越来越差，如何解决
- 先更新数据库还是先更新缓存
- 不更新缓存，而采用删除缓存的策略
- 写策略是先更新数据库，后删除缓存，还是先删除缓存，后更新数据库
- 先更新数据库，后删除缓存，会对缓存的命中率带来影响
- 先更新数据库，再删除缓存，可能存在删除缓存失败的问题
- 既然删除缓存有可能失败，如何保证两个操作都能执行成功
- 1. 重试机制
- 2.订阅Mysql binlog,再操作缓存
给服务器加上Redis,让其作为数据库的缓存
这样叫客户在请求数据时，如果能在缓存命中数据，就查询缓存，不用查数据库数据库，从而减轻数据库的压力，提高服务器性能
- 先更新数据库，再更新缓存
- 先更新缓存，再更新数据库
由于并发，这两个方法都可能产生数据库和缓存数据不一致的问题
不更新缓存，而采用删除缓存的策略Cache Aside策略（旁路缓存策略）：不更新缓存，而是删除缓存中数据，读数据时，如果发现缓存中没数据之后，再从数据库中读数据，更新到缓存中
读策略：
如果读取的数据命中了缓存，则直接返回数据
如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入缓存，并且返回给用户
写策略：
更新数据库中数据
删除缓存中数据
先删除缓存，后更新数据库
A要更新数据库值，B要读取这个值
写入时删除缓存后，又有读取的请求时缓存未命中，将更新成数据库旧值，然后数据库才进行更新
当读+写并发时，还是会出现缓存和数据库不一致的问题
先更新数据库，后删除缓存
缓存中不存在该值，A要读取这个值，在未写入缓存时，B要更新这个值
因为缓存写入的速度往往快于数据库写入，实际中很难出现B已经更新数据库并删除缓存，请求A才更新为缓存的情况
可以保证数据一致性
为了确保万无一失，还可以给缓存数据加上过期时间，保证缓存数据最终一致
如果业务对命中率有很高的要求，可以采用更新数据库+更新缓存的方案，因为更新缓存不会出现缓存未命中的情况
但如果出现两个线程并发更新它们，就会由于写入顺序的不同造成数据不一致
解决方法：
- 在缓存更新前，先加分布式锁
保证同一时间只运行一个请求更新缓存，就不会产生并发问题，但引入了锁之后，对写入的性能会产生影响
2.更新完缓存时，给缓存加上较短的过期时间
即使出现缓存数据不一致的情况，缓存数据也会很快过期，对业务还是能接受的
对先删除缓存，后更新数据库产生的并发问题的解决方法——延迟双删
删除缓存
更新数据库
睡眠
删除数据库
具体睡眠时间多久很难指定，这个方法只能尽可能保证一致性，还是建议使用先更新数据库，再删除缓存的方案
先更新数据库，再删除缓存，可能存在删除缓存失败的问题如果删除缓存失败，就会导致数据库和缓存不一致
数据库存旧值，缓存存新值
如果缓存设置了过期时间，从用户视角来看，用户所更新的数据没有立即变更，而是过了一段时间才发生变更
采用异步操作缓存
1. 重试机制
- 重试机制
- 订阅Mysql binlog,再操作缓存
可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列。由消费者来操作数据
删除缓存失败：
采用重试机制，从消息队列中重新读取数据，然后再次删除缓存
如果重试超过一定次数，需要向业务层报错
删除缓存成功：
把数据从消息队列中移除，避免重复操作
先更新数据库，当数据库更新成功，就会产生一条变更日志，记录在binlog里
我们就可以通过订阅binlog日志，拿到具体要操作的数据，然后再执行缓存删除
阿里巴巴开源的Canal中间件就是基于这个实现的
Canal模拟MySQL主从复制的交互协议，把自己伪装成一个MySQL的从节点，向Mysql主节点发送dump请求，Mysql收到请求后，就会开始推送Binlog给Canal,Canal解析Binlog字节流之后，转换为便于读取的结构化数据，供下游程序订阅使用
