缓存一致性设计方案

缓存一致性设计方案
要保证缓存和DB数据一致，即在发生写操作时要清理缓存，这两个操作要是原子性的。
完整的方案一共需要四次删除。
我们的方案是将变更事件消息发送到msgbroker中，然后自己去订阅进行缓存清除。但是msgbroker是异步的，中间存在时间差，用户很容易访问到旧的数据。所以我们的优化方案是对缓存进行二次清理。第一次是在写操作后进行同步删除，同时忽略异常，保证强一致性。第二次则是保证最终一致，通过消息中间件订阅消息异步删除，这里会处理异常，发生异常重试。
注意：不在第一次jvm删除时直接处理异常的原因是为了保证用户操作的体验，防止出现失败或者延迟过大的情况。

在高并发情况下写操作delete，读操作put存在天然的bug，且无法消除。即在A读取旧数据后，put缓存的操作在B更新DB且删除缓存之后才发生，缓存里存放了旧数据。所以我们在msgbroker删除后延迟2秒再次删除，可以很大程度上缓解这种bug造成的并发问题。这种方式降低了缓存的命中率，对于花呗这种业务模式对于缓存脏数据的零容忍，我只有这样牺牲一些可用性来保证一致性。

还有花呗大促的时候，流量会在不同的LDC之间互相切换，导致不同的缓存数据这时候就需要借助ADDP进行全zone的删除。

发布过程中也存在缓存一致性问题