你们引入缓存中间件，会去解决数据库缓存双写一致性的问题吗

[zhongpingjing]

看了一篇博文了解了一些相关的内容，了解到引起不一致性的原因：
先删缓存，再更新 DB （这种策略应该没有人用？）
先更新 DB，再删缓存（这种发生不一致性的概率虽然可以忽略不计，但是是否需要去防止？）
先更新 DB，然后删除缓存失败（真的会发生删除缓存失败吗？网络原因？）
DB 主从复制的延迟造成不一致
。。。

解决这个双写一致性问题，需要双删和重试。感觉这种方式代价有点大啊。
在实际生产中，会这样去解决吗？有没有更好的办法？

[abigeater]

@zhongpingjing 不会丢吧 边界值可以直接写回 DB 后清缓存和删写回队列 其他的都可以走这个流程 一般 DB 崩都是瞬发的请求导致的 在定时服务写回 DB 可以是频繁的不间断的所以写回 DB 队列应该不会造成堵塞（可能，目前我还没遇过堵塞至少）

[lsp7572]

@zhch602 当然是视业务场景而定，你这一句话找死还没我四个字的信息量大好吧。。起码给个例子，我也能学习。。

[xuanbg]

大多数程序员可能没有意识到的是：缓存失效的时序其实并没有辣么重要。假设先读到数据，然后数据被删除，再用这个数据创建了新的数据。在业务上有问题吗？一点问题就没有呀。例如某个客户被删除了，原先基于这个客户的数据失效了吗？并没有啊，所以你们在纠结什么呢？

所以，先删数据库再删缓存就行了。

[zhch602]

@lsp7572
@iyaozhen
因为即使用了延迟双删还是有可能不一致，最关键的是 我没听说过哪个业务敢在线上让线程 sleep 个几百毫秒甚至更多
至于资料，你们随便在 google 上搜延迟双删第一页就有文章，直接放个链接 https://www.cnblogs.com/zhouj-happy/p/12616906.html

[lsp7572]

@zhch602 你发的这文章只是提出了问题，没有解决问题。

至于你说的 sleep 这个就是业务来决定的

延时双删就是一定程度可以解决缓存一致性问题的解决方法

[lsp7572]

另外删除操作可以另起线程，这个是业务方可以考量的虽然会增加编码复杂度

[zhch602]

@lsp7572 解决方法就是没有完美的解决方法，要视业务而定，要强一致只能加锁，最终一致的话延迟双删也是下下策

[JasonLaw]

<amp-youtube data-videoid="ZAZJqEKUl3U" layout="responsive" width="480" height="270"></amp-youtube>

[liian2019]

@potatowish 这得单独整一套分布式缓存服务才行，太重了