- 问：了解缓存更新策略吗？
了解 先说旁路缓存策略
说了那个写策略
- 问：然后问为什么要用那种：
答：降低不一致情况出现
- 问：为什么会不一致？
答：请求1先将缓存删了，然后更新数据库 但是更新数据库比较耗时 导致还没更新完 就有一个请求2 来读 读到了数据库中的数据，然后放到缓存中 最后请求一
将数据库数据修改了，导致缓存中的数据是脏数据
- 问：就没有解决办法吗？非得先更新数据库，再删缓存吗？
答：有解决办法：
- 因为缓存中是脏数据 因此我只需要再次将缓存删掉即可
使用延时双删的策略 隔一段时间再将缓存删掉 或者是添加缓存的时候加上过期时间也行
- 这里是因为我还没写完 另外一个请求就去读了
因此可以通过加读写锁的方式，读写是互斥的 必须写完才能读
5.问：先更新然后删缓存就一定没问题吗？
答：
- 还是会出问题的，比如说
请求1去db中读数据A 请求2去数据库更新数据A 然后请求1再将数据A写入缓存（当然这种因为写入缓存很快，因此不会缓存还没写完 另外一个请求就进来操作了）
但是一般是不会出现这种问题的，因此可以采用这种写的方案，所以旁路缓存的写策略也是采用的这种
- 另外还可能出现删除缓存失败的情况，如果没删成功，那么缓存中还是旧数据
那么有什么办法吗？可以使用消息队列，将失败的key放入到消息队列中，然后进行消费，如果消费失败就重新放入到消息队列中。一直要消费成功才手动ack
那么使用消息队列就没有缺点了吗？还是会有缺点的，因为使用了消息队列，就会对业务代码造成大量的侵入，深深的耦合在一起。
此时还有另一种解决方案：订阅binlog日志的方案，因为只要修改了数据库，binlog中就会有记录，订阅这个binlog服务，将要删除的key放入到消息队列即可
6.问：那么这种旁路缓存策略就没有问题了吗？
答：因为这种写的策略是删除策略，所以不适合写多的场景
-
如果是写多，就会频繁的删掉，造成每次都读不到 造成命中率低
-
另外这个老是删了，导致如果马上需要数据的话，就不便利 比如说注册
7.问：那么有什么办法可以解决这个问题呢？
也就是解决写多的场景
答：可以使用先更新数据库再更新缓存的写方案，这种因为马上更新了缓存，导致缓存中是有最新数据的，所以就能马上获取到数据，能够命中
8.问：那么这种就没问题了吗？
答：因为这是应对写多场景，因此就会存在写并发
如果说请求1更新先更新数据库然后 因为更新不是那么的快 现在请求2也来更新数据库 请求2在马上更新完数据库之后，又马上更新了缓存，但最后请求1将数据库更新了
导致数据库中存的请求1的数据，而缓存中存的是请求2的数据，造成缓存不一致
那么有解决方案吗？
因为这是写并发，可以使用加锁/分布式锁的方式 这是强一致 影响性能，如果对暂时一致性要求不高，可以使用加过期时间的方式
9.问：那么我可以使用先更新缓存，再更新数据库吗？
一样可能会出现像上面的那种情况 请求1还没更新完数据库呢 第二个请求就干完所有了 然后请求1将数据库修改了 但是缓存中就是旧数据了
解决方案同上