什么是Redis数据一致性？如何解决？

在系统中缓存最常用的策略是：服务端需要同时维护DB和cache，并且是以DB的结果为准–Cache-Aside Pattern（缓存分离模式、旁路缓存）

读数据

单纯的读数据是不会产生数据不一致，只有并发下读和写才会存在数据不一致。

写数据 先更新缓存再更新数据库先删除缓存再更新数据库先更新数据库再更新缓存先更新数据库再删除缓存

以上操作步骤总结下来就是两点：

更新缓存还是删除缓存？ 推荐使用删除，因为缓存的更新成本更高，因为写入缓存的值一般要经过一系列复杂的计算再写入缓存；删除缓存操作简单，副作用只是增加了一次cache miss 先操作缓存还是先操作数据库？ 数据不一致 先操作缓存

经过上述过程之后，出现了数据不一致；redis中是老的数据，而DB中是新的数据（写延迟）；所有后续其他的线程都是从缓冲中拿到的老数据，直至该老数据缓存过期。

如何解决这种情况下的数据不一致性？

通过延迟双删的策略可以解决，且保证了最终一致性。虽然线程2依然拿到的是老数据，但是后面的线程拿到的都是新数据。

最终一致性：最终能够保证redis和DB的一致性。 强一致性：redis操作和DB操作设置成原子操作，虽然保证了一致性但是降低了吞吐量，违背了使用redis的初衷。

先操作数据库

通过先操作数据库，然后操作缓存，虽然线程2在删除之前拿到的是老数据（脏数据），但是可以保证最终一致性，推荐使用该方式。

删除重试

上述两种方式不管是延迟双删还是先操作数据库，保证最终一致性的前提是删除缓存成功，如果在极端条件下删除缓存失败怎么办？

如上图所示，通过向MQ发送异步消息，通知客户端进行重试删除来解决。引入canal组件，可将该删除重试功能从业务代码中解耦，canal客户端可以使用springboot应用来实现。