redis缓存一致性问题解决方案

使用缓存来存储热点数据是应对高并发的常用手段之一，通过使用缓存，大大减轻了数据库的压力，同时减少了响应请求的时间。

但是引入缓存之后，随之而来的问题就是当DB数据更新时，缓存中的数据就会与db数据不一致，这时候就需要对缓存的数据进行更新或者淘汰缓存，这篇文章就是分析各种处理缓存一致性问题的解决方案。

先更新DB还是操作缓存

更新DB和操作缓存两个动作之间，明显缺乏原子性，有可能更新DB完成，但是操作（淘汰或者更新）缓存失败，反之亦然。所以两者之间必然是由断层的，那么先选择操作谁才是最佳的方案？

这里推荐先更新DB，然后再更新或者淘汰缓存，原因如下

• 如果先更新缓存，然后更新DB的动作失败了，下一个读请求过来，读取到的缓存数据就是未曾更新到DB的数据，这样的数据明显是业务错误的。因此建议先更新DB，再后续选择操作缓存。
• 如果采用先淘汰缓存，后更新DB操作，如果在DB更新完成之前，来了一个新的读请求，那么就会查询出数据库的旧数据，缓存到redis，导致DB更新完成之后，两者数据不一致。
• 如果先更新DB，然后操作缓存失败，客户端读取到的是旧的数据，此时也是存在DB与缓存不一致，但是实际业务上，我们更多的还是以DB数据为准，这种读取到旧数据的业务影响可能比读取到为未更新到DB的数据影响要小。

保证更新DB和操作缓存之间的连续性

两个动作之间原则上是非原子性的，一个是更新DB，一个是更新redis。但是，通常我们使用一个妥协的方案，类似于分布式事务最终一致性的实现，这里也可以使用消息队列实现最终一致性的消息保证。

• 先更新DB数据，然后通过发送操作缓存的消息到消息队列，进行更新缓存操作，这里还需要的一个操作就是利用消息队列的重试机制，保证缓存能够更新成功，如果多次消费失败，可能是由于网络原因或者redis服务挂了，此处可以添加告警处理。

更新缓存还是淘汰缓存

严格上来说，不论是更新缓存，还是淘汰缓存，都是可能出现缓存不一致的，但是从分析上来说，更新缓存的方式出现缓存不一致的可能性更大，如果是业务上对缓存不一致容忍性比较大，那么选择更新还是淘汰都是可以的，下面来分析一下，两个综合的方案可能出现的问题。

• 采用先更新DB，后更新缓存可能出现问题
  • 采用更新缓存的方式，需要考虑在操作完DB之后，后续的更新缓存操作，是否需要比较复杂的操作才能得到应该set进缓存中值？例如需要复杂计算或者DB交互查询。如果是的话，那么不建议使用更新缓存的方式，二是采用淘汰缓存的方式
  • 并发写问题。假如两个写请求A和B同时进行写DB操作，A先于B，B基于A做更新，此时假如是使用传值进行更新缓存，可能出现的问题就是B的写缓存操作，后于A的写缓存操作，从而导致缓存被A的更新数据覆盖，缓存中的数据变成旧的数据。出现缓存不一致。
  • 采用mq重试和告警，更新DB与更新缓存之间也可能存在断层。

所以，如果要使用更新缓存的方式来保证缓存与DB数据一致性，需要考虑以上三个问题。

• 采用先更新DB，后淘汰缓存可能出现问题
  • 采用mq重试和告警，更新DB与淘汰缓存之间也可能存在断层。

通过上面的分析，可以知道更新DB在更新缓存的实现方案，可能面临更多的问题需要考虑，对比之下，也许是方案二比较好。在实际生产中，两个方案都可能出现DB与缓存数据不一致，如果对数据不一致容忍度比较低，那么建议是采用先更新DB，后淘汰缓存方案。

这里只是简单方案分析，如果复杂点的场景，还需要考虑DB读写分离时，主从数据同步延时导致的缓存不一致。