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