缓存和DB一致性

读操作，一般是先查询缓存，查询不到再查询数据库，最后回写进缓存。
写操作，究竟是先删除(更新)缓存，再更新数据库，还是先更新数据库，再删除(更新)缓存呢？

1、先更新数据库，再更新缓存
如果利用到缓存，那么肯定是读多写少的场景
缺点：
写多读少时，频繁更新缓存会降低性能
并发情况下可能存在将脏数据写回缓存的风险

为什么会有脏读：
首先线程1更新数据库，还没来得及更新缓存，线程2更新数据，在更新缓存成功，然后线程1在更新缓存，结果就变成了数
据库和缓存的数据不一致。

2、先更新缓存，再更新数据库
和方案2类似，也会存在相同的问题。
缺点：
比如线程1更新缓存，还没来得及更行数据库，线程2更新缓存在更新数据库，最后线程1更新数据库，这个时候数据和缓存不一致。


3：先更新数据库，再删除缓存
既然方案2与方案3都是更新缓存，这里不妨直接删除缓存呢？
缺点：
这种也有一个问题就是：当线程1准备更新数据库，线程1还没来得及执行，线程2过来读，还没写入缓存，然后线程1更
新数据，并且删除缓存，线程2在写入缓存就造成了数据不一致。

4、先删除缓存，再更新数据库
缺点：线程1删除缓存，线程2过来读，还没写入缓存，结果线程1更新了数据库，线程2在写入缓存，这个时候，缓存和数据
库的数据也不一致。

1、给缓存设置过期时间
适用于对数据一致性要求较低或者写请求很少的业务
当读请求没有命中缓存时，就从数据库中读，之后回写到缓存里，同时设置一个过期时间。
写请求直接更改数据库，不用操作缓存。

2、方案：延时双删
更新请求：先删除缓存，在更新数据库，在删除缓存。
缺点：
存在第二次删除失败的情况

3、方案：消息队列
先更新数据库，接着将删除缓存的消息投递到mq中。自身拿到消息后，尝试进行删除缓存。如果失败，则不断进行重试。
缺点：
引入了消息队列，系统的复杂性提升，可用性降低。
也会带来各种各样的问题，例如消息丢失、乱序与重复消费等。乱序与重复消费的问题，在删除缓存的场景下，不会造
成任何问题。

4、方案    消息队列+订阅binlog
复杂度提升了

缓存和DB一致性-canal，其实这个也是基于Binlog+Mq的方式跳转