在系统中缓存最常用的策略是：服务端需要同时维护DB和cache，并且是以DB的结果为准–Cache-Aside Pattern（缓存分离模式、旁路缓存）
读数据
单纯的读数据是不会产生数据不一致，只有并发下读和写才会存在数据不一致。
写数据
- 先更新缓存再更新数据库
- 先删除缓存再更新数据库
- 先更新数据库再更新缓存
- 先更新数据库再删除缓存
以上操作步骤总结下来就是两点：
- 更新缓存还是删除缓存？
- 推荐使用删除，因为缓存的更新成本更高，因为写入缓存的值一般要经过一系列复杂的计算再写入缓存；删除缓存操作简单，副作用只是增加了一次cache miss
- 先操作缓存还是先操作数据库？
数据不一致
先操作缓存
经过上述过程之后，出现了数据不一致；redis中是老的数据，而DB中是新的数据（写延迟）；所有后续其他的线程都是从缓冲中拿到的老数据，直至该老数据缓存过期。
如何解决这种情况下的数据不一致性？
通过延迟双删的策略可以解决，且保证了最终一致性。虽然线程2依然拿到的是老数据，但是后面的线程拿到的都是新数据。
最终一致性：最终能够保证redis和DB的一致性。
强一致性：redis操作和DB操作设置成原子操作，虽然保证了一致性但是降低了吞吐量，违背了使用redis的初衷。
先操作数据库
通过先操作数据库，然后操作缓存，虽然线程2在删除之前拿到的是老数据（脏数据），但是可以保证最终一致性，推荐使用该方式。
删除重试
上述两种方式不管是延迟双删还是先操作数据库，保证最终一致性的前提是删除缓存成功，如果在极端条件下删除缓存失败怎么办？
如上图所示，通过向MQ发送异步消息，通知客户端进行重试删除来解决。引入canal组件，可将该删除重试功能从业务代码中解耦，canal客户端可以使用springboot应用来实现。
