缓存和DB一致性

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

1、给缓存设置过期时间
适用于对数据一致性要求较低或者写请求很少的业务当读请求没有命中缓存时，就从数据库中读，之后回写到缓存里，同时设置一个过期时间。
写请求直接更改数据库，不用操作缓存。2、先更新数据库，再更新缓存
如果利用到缓存，那么肯定是读多写少的场景
缺点：
写多读少时，频繁更新缓存会降低性能
并发情况下可能存在将脏数据写回缓存的风险为什么会有脏读：
首先线程1更新数据库，还没来得及更新缓存，线程2更新数据，在更新缓存成功，然后线程1在更新缓存，结果就变成了数
据库和缓存的数据不一致。3、先更新缓存，再更新数据库
和方案2类似，也会存在相同的问题。缺点：
比如线程1更新缓存，还没来得及更行数据库，线程2更新缓存在更新数据库，最后线程1更新数据库，这个时候数据和缓存不一致。4：先更新数据库，再删除缓存
既然方案2与方案3都是更新缓存，这里不妨直接删除缓存呢？缺点：
这种也有一个问题就是：当线程1准备更新数据库，线程1还没来得及执行，线程2过来读，还没写入缓存，然后线程1更
新数据，并且删除缓存，线程2在写入缓存就造成了数据不一致。5、先删除缓存，再更新数据库
缺点：线程1删除缓存，线程2过来读，还没写入缓存，结果线程1更新了数据库，线程2在写入缓存，这个时候，缓存和数据
库的数据也不一致。方案6：延时双删
更新请求：先删除缓存，在更新数据库，在删除缓存。缺点：
存在第二次删除失败的情况方案7：消息队列
先更新数据库，接着将删除缓存的消息投递到mq中。自身拿到消息后，尝试进行删除缓存。如果失败，则不断进行重试。缺点：
引入了消息队列，系统的复杂性提升，可用性降低。
也会带来各种各样的问题，例如消息丢失、乱序与重复消费等。乱序与重复消费的问题，在删除缓存的场景下，不会造
成任何问题。方案8    消息队列+订阅binlog
复杂度提升了

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