Redis缓存数据一致性

实际业务中常使用Redis缓存来提升读写效率，减少存储层的压力。因为数据在缓存和DB中各存储一份，所以会出现数据一致性的问题。总体来说导致数据不一致的原因主要有两个。请求并发和操作非原子。
请求并发是指同时可能有多个读写请求同时请求Cache或者DB，前后乱序，最终导致缓存/DB数据更新不一致。
同时操作Cache和DB属于两个操作，两个非原子性操作，如果出现第二步失败，同样也会出现数据的不一致。

请求并发

缓存处理方式

对Cache数据的处理方式有两种，分别为更新和删除。哪种方式更能保证数据一致性呐？接下来一个个来分析。

更新缓存

使用更新Cache的方式，无论是先更新Cache还是后更新Cache，都有可能出现数据不一致问题。
举例说明，假如并发A、B两个写请求。A将数据X更新为1，B将数据更新为2。其中B更新晚于A。

先更新Cache，后更新DB

最终结果Cache=2，DB=1

先更新DB，后更新Cache

最终结果Cache=1，DB=2

删除缓存

先删除Cache，后更新DB

举例说明，假如并发A、B两个请求。A为写请求，B为读请求。

先更新DB，后删除Cache

举例说明，假如并发A、B两个请求。A为读请求，B为写请求。
先更新DB，后删除Cache的方式可以看出也会存在一致的场景。但是仔细思考下，出现这种场景的概率非常低。他需要满足A读请求写Cache的耗时大于B请求更新数据库+删除Cache的耗时。因为DB操作的耗时要远大于Cache的操作耗时。所以先更新DB，后删除Cache出现数据不一致的问题出现几率比较小。

总结

综上，针对cache处理方式和操作顺序进行分析，最终最靠谱的方案就是先更新DB，后删除Cache。

但是如果业务场景要求为弱一致性或者最终一致性。先删除Cache后更新DB的方式也是可以接受的，同时安全起见，可以引入延时双删的策略。在写请求更新完DB后休眠一会儿，再次将缓存删除，可以达到最终一致性的要求。

操作非原子

上面讨论的情况都是在两步操作都成功的前提下进行的。但是如果第一步操作成功，但是第二步操作失败，那么无论是Cache数据如何操作都会导致数据的不一致。
那么如何保证两步操作都保证成功，最简单的解决方案就是重试。重试的方案最为常见的就是引入MQ，进行异步重试。以先更新DB，后删除缓存方式为例。如果在第二步操作删除缓存失败时，可以发通知给MQ，然后通过消费者接受通知消息然后重试删除Cache。

另外除了MQ方案，还有订阅binlog的方案。在DB数据发生变更时，通过订阅binlog在更新/删除Cache。