数据库和缓存如何保持一致性

服务器访问速度越来越差，如何解决

给服务器加上Redis,让其作为数据库的缓存
这样叫客户在请求数据时，如果能在缓存命中数据，就查询缓存，不用查数据库数据库，从而减轻数据库的压力，提高服务器性能

先更新数据库还是先更新缓存

1. 先更新数据库，再更新缓存
   
2. 先更新缓存，再更新数据库
   

由于并发，这两个方法都可能产生数据库和缓存数据不一致的问题

不更新缓存，而采用删除缓存的策略

Cache Aside策略（旁路缓存策略）：不更新缓存，而是删除缓存中数据，读数据时，如果发现缓存中没数据之后，再从数据库中读数据，更新到缓存中
读策略：
如果读取的数据命中了缓存，则直接返回数据
如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入缓存，并且返回给用户
写策略：
更新数据库中数据
删除缓存中数据

写策略是先更新数据库，后删除缓存，还是先删除缓存，后更新数据库

先删除缓存，后更新数据库
A要更新数据库值，B要读取这个值
写入时删除缓存后，又有读取的请求时缓存未命中，将更新成数据库旧值，然后数据库才进行更新
当读+写并发时，还是会出现缓存和数据库不一致的问题

先更新数据库，后删除缓存
缓存中不存在该值，A要读取这个值，在未写入缓存时，B要更新这个值
因为缓存写入的速度往往快于数据库写入，实际中很难出现B已经更新数据库并删除缓存，请求A才更新为缓存的情况
可以保证数据一致性
为了确保万无一失，还可以给缓存数据加上过期时间，保证缓存数据最终一致

先更新数据库，后删除缓存，会对缓存的命中率带来影响

如果业务对命中率有很高的要求，可以采用更新数据库+更新缓存的方案，因为更新缓存不会出现缓存未命中的情况
但如果出现两个线程并发更新它们，就会由于写入顺序的不同造成数据不一致
解决方法：

1. 在缓存更新前，先加分布式锁
   保证同一时间只运行一个请求更新缓存，就不会产生并发问题，但引入了锁之后，对写入的性能会产生影响
   2.更新完缓存时，给缓存加上较短的过期时间
   即使出现缓存数据不一致的情况，缓存数据也会很快过期，对业务还是能接受的

对先删除缓存，后更新数据库产生的并发问题的解决方法——延迟双删

删除缓存
更新数据库
睡眠
删除数据库

具体睡眠时间多久很难指定，这个方法只能尽可能保证一致性，还是建议使用先更新数据库，再删除缓存的方案

先更新数据库，再删除缓存，可能存在删除缓存失败的问题

如果删除缓存失败，就会导致数据库和缓存不一致
数据库存旧值，缓存存新值
如果缓存设置了过期时间，从用户视角来看，用户所更新的数据没有立即变更，而是过了一段时间才发生变更

既然删除缓存有可能失败，如何保证两个操作都能执行成功

采用异步操作缓存

1. 重试机制
2. 订阅Mysql binlog,再操作缓存

1. 重试机制

可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列。由消费者来操作数据
删除缓存失败：
采用重试机制，从消息队列中重新读取数据，然后再次删除缓存
如果重试超过一定次数，需要向业务层报错
删除缓存成功：
把数据从消息队列中移除，避免重复操作

2.订阅Mysql binlog,再操作缓存

先更新数据库，当数据库更新成功，就会产生一条变更日志，记录在binlog里
我们就可以通过订阅binlog日志，拿到具体要操作的数据，然后再执行缓存删除
阿里巴巴开源的Canal中间件就是基于这个实现的
Canal模拟MySQL主从复制的交互协议，把自己伪装成一个MySQL的从节点，向Mysql主节点发送dump请求，Mysql收到请求后，就会开始推送Binlog给Canal,Canal解析Binlog字节流之后，转换为便于读取的结构化数据，供下游程序订阅使用