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

[zhongpingjing]

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

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

[wqhui]

看业务是不是要求强一致性，还是说最终一致性也可以，强一致性的话代价肯定是大的了

[BBCCBB]

没有解决.. 不能容忍的地方我们都查 db.

只要两个地方没有事务. 总是有不一致的窗口存在.

[vindac]

我们都是缓存定时淘汰，有个服务去更新缓存。。

[zhongpingjing]

@vindac 意思是你们的业务服务自身不会去更新缓存是吗，那如果缓存过期了，会去查 DB 呢还是直接返回 null ？去查 DB 的话，查完会把结果放到缓存中吗？

[abigeater]

业务操作对缓存操作不直接写到 DB
服务定时将缓存写到 DB
读取从缓存读取 没有数据从 DB 读取后写到缓存

[zhongpingjing]

@vindac 专门的更新缓存服务，那要如何定位到失效缓存，如何更新它啊，比如缓存 A 过期了，缓存服务就需要去 DB 拉取数据放到缓存中，如何发现缓存 A 失效了，并及时更新它

[raaaaaar]

定时是个思想，大概可以参考下 cache 和内存的做法？没命中时再装载到 cache 里，满了就置换，根据修改位先写会再换什么的

[zhongpingjing]

@abigeater 这样有可能丢失数据

[zhongpingjing]

@raaaaaar 有点听不懂大佬在讲什么[笑哭]

[InkAndBanner]

@abigeater 从 DB 读 写到缓存里面不好吗？

[potatowish]

1.先更新 DB，再删缓存
2.订阅 binlog 日志去单独做更新，比如 canal

[fkname]

一般有缓存时间兜底

[lsp7572]

延时双删了解下

[zhch602]

@lsp7572 别误导人了，延迟双删也就面试八股文用用，真正生产中使用就是找死

[iyaozhen]

@zhch602 咦，为啥。比较简单有效

[Croxx]

来看经典老文 https://www.scylladb.com/2017/07/31/database-caches-not-good/

[leafre]

删除缓存失败，那就补偿，直到成功为止，单机不一致解决
主从不一致使用选择性读主解决

[ryd994]

双删和后删有什么区别呢？
如果你速度快，别人速度慢，你更新完了别人再去取数据。和你先更新再删缓存又有什么区别？
如果你速度慢，别人速度快。别人把旧值取了，你再去把旧值再删一遍。

提供的保证是基本一样的，就是缓存对 db 的延迟一致性。考虑到写入者挂掉的情况，这甚至不是最终一致性。

你如果要求强一致，那只能用锁了。不那么蛋疼的办法就是：写一个中间件代理。对同一数据的请求由这同一台代理序列化。中间件可以在修改数据库的时候加锁。用本地锁实现了强一致。
但是现在问题就转移到了如何保证对同一数据的请求总是由同一代理处理的问题。看起来是 hash 一下不难。但是你得考虑代理服务器上线离线的情况。

[bthulu]

不管双删后删, 因网络问题, 都可能导致数据不一致.
如果需要最终一致性, 操作 db 时, 同时在数据库中标记一下需要更新的缓存, 因与 db 操作在同一数据库, 可以保证这里的强一致性.
然后再开定时任务从 db 中捞取需要更新缓存的数据, 去更新缓存, 更新成功后, 再清除此更新标记, 更新缓存失败, 不做处理, 等待下一次任务执行周期就行.

[abigeater]

@InkAndBanner em..你这里是 从 DB 读，写到缓存吗 还是从 DB 读写到缓存 这个空格分的不够开不知道是哪个意思
1.从 DB 读，写到缓存：我这用定时服务从缓存写到 DB 那如果从 DB 读 就会有个时间差 定时服务还没写进 DB 时被读取就会拿到旧数据 那数据就不一致了
2.从 DB 读写缓存：就是这个意思，只是把从缓存写回到 DB 的压力减少