双写一致性

双写一致性
咱们可以通过设置过期时间保证最终一致性，但是内存是有限的，不可能为每一个key设置过期时间，一般我们对一致性要求比较高，我们就采取一些策略 区保证咱们的一致性。
大致上有这么一些策略，
第一，更新缓存，再更新数据库
第二，更新数据库，在更新缓存
第三，删除缓存，再更新数据库
第四，更新数据库，在删除缓存
下面我们依次进行分析
首先第一个，更新缓存，再更新数据库、
更新缓存之后，更新数据库失败，会造成数据不一致问题
第二个，更新数据库，在更新缓存
从线程安全角度来讲：线程A更新数据库，同时线程B更新数据库，线程B更新缓存，线程A更新缓存,会造成脏数据问题
从业务场景角度来讲：如果更新了数据库，需要走一大段逻辑再去更新缓存，会造成咱们性能的浪费，所以，直接删除缓存更为合适
第三个，先删除缓存，再更新数据库
线程A请求写入数据，删除缓存
线程B读取缓存，没有，去数据库读取旧值，并更新到缓存
线程A将新值更新至数据库
可采用延时双删策略，就是在更新数据库之后，设置休眠时间，再进行缓存的删除，mysql主从架构也是如此
向主库写入数据，删除缓存，还没来得及同步，缓存找不到，就从从库当中读取旧值更新到缓存，主从同步完成

第四个呢，先更新数据库，再删除缓存
有这么一种情况
线程A读取数据（旧值）
线程B进行更新
线程B删除缓存，
线程A将旧值写入缓存
咱们知道，mysql读写，读的效率要比写的效率要高，这种情况发生的唯一可能就是，线程B更新操作要快于线程A读取操作，那么才有可能线程B删除缓存，才会在线程A 写入缓存之前，这种情况发生的概率非常之小。
但是存在这种情况，可以采用设置过期时间，或者延时双删
还会有一种情况就是，删除失败怎么办？
有两种解决方案，
第一种
业务代码更新数据库，删除缓存失败，将删除失败的key存入消息队列，再次传回到业务代码中进行删除
这种方式有一个缺点，就是会造成代码侵入，每次都需要再执行一次业务代码
那么就有第二种方案
业务代码更新数据库，将key值存入binlog日志当中，将生成的binlog日志传入订阅binlog系统（canal），订阅系统提取出key值在非业务员代码中执行删除操作，删除失败，存入到消息队列，再次传回至非业务代码删除。这样可以保证咱们的一致性

当然，如果对一致性要求不是很高，可以另起一个线程，每隔一段时间去重试。