数据库与缓存的一致性问题的两个疑问

mitu9527 会员 2022年8月19日 10:18 发表

• 

  zjj19950716 会员

  2022年8月19日 10:18
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 10:47
  额，文章看完了，但是不太理解你引入这篇文章想表达什么，能明示么？
  0 0
  评论

• 

  lmshl 会员

  2022年8月19日 10:47
  一般对于缓存问题，我都会先问一句，缓存服务是必须引入的组件吗？ 你的业务量在可预见的未来，会增长到单机数据库难以支撑的程度吗？ 然后问第二句，你是否真的理解 CAP 。不要试图去挑战 CAP ，这里面水太深，你把握不住。 据我观察除了头部公司几个流量业务外，99% 项目的并发量直到项目死掉都没有超出单机数据库的承载范围，引入 Redis 对你们是否真的有必要？ 如果真的有必要，请熟读 1 楼帖子
  0 0
  评论

• 

  javaisthebest 会员

  2022年8月19日 10:47
  个人看法 我会选第一种 愿意如下 1. 服务正常的时候远远多于异常的时候， 代码 1 可以覆盖这种场景 2. 代码 2 的话无非就是视为每次操作都是异常场景。再次都用 mq 去确保最终一致性 至于取舍的话，我感觉好像也没啥大的区别。看个人习惯吧
  0 0
  评论

• 

  siweipancc 会员

  2022年8月19日 11:18
  证书授权上缓存测试组一年提了上百个 bug ，仅供参考。
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 11:18
  第一，都在讨论这个问题了，当然缓存服务是必然的，不然我也不会提问了。 第二，那个帖子我看过，也看完了，我在讨论 Cache Aside Pattern ，应该不会有人觉得我在讨论另外两种方案吧。 最后，你都说了这么多了，感觉如果我的理解有问题，你也应该能轻易指出来，就别只说到一半了，能明示么？不胜感激。
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 11:18
  第一，都在讨论这个问题了，当然缓存服务是必然的，不然我也不会提问了。 第二，那个帖子我看过，也看完了，我在讨论 Cache Aside Pattern ，应该不会有人觉得我在讨论另外两种方案吧。 最后，你都说了这么多了，感觉如果我的理解有问题，你也应该能轻易指出来，就别只说到一半了，能明示么？不胜感激。
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 11:18
  怎么说，有啥经验教训可以传授么？
  0 0
  评论

• 

  LeegoYih 会员

  2022年8月19日 12:17
  以前我也纠结过这个问题，始终没有一个完美的方案可以覆盖所有场景，针对不同场景用不同实现比较好。 普通场景允许短时间内缓存不一致的话，一般用 Cache-Aside pattern 。 如果缓存不一致可能带来生产问题，比如，可能造成资损，建议还是用 事务 /分布式锁 方式保证强一致。 Cache-Aside pattern 实现简单，性能也是最好的，很多大厂都在用：
  0 0
  评论

• 

  kidlj 会员

  2022年8月19日 13:16
  Friends don't let friends do dual writes. 更新完数据库紧接着更新缓存或者写入消息队列，这就是双写或者多写，总会有第一步成功了下一步失败的概率（比如网络抖动等原因），这时候就会造成数据不一致。 我个人的项目实践了一种事件驱动的异步架构，也就是 CDC （ change data capture ）架构，选型上使用的是 Debezium + Kafka connector ，当然 Java 生态的也可以用 Canal 替换 Debezium 。简单来说 Debezium 的工作就是监听数据库的写入变更（ pg 的 wal log 或 mysql 的 bin log ），为每条变更记录生成一条 Kafka message （包含变更记录的主键 id 等其他字段信息），通过 Kafka connector 自动写入到一个数据库表对应的 Kafka Topic 。采用这种架构处理缓存过期就很简单了。业务端只要更新数据库就可以，（避免了双写的问题），更新缓存的逻辑起一个线程或 goroutine 监听这个表对应的 Kafka topic ，拿到消息以后解析出主键 id ，然后 purge 掉对应记录的缓存。如果消费了这条消息以后 purge 缓存失败怎么办？有这种可能的。Kafka 的 message 有 commit 机制，purge 失败可以一直重试，当成功了以后再 commit 消息。虽然这种架构是异步的，不过得益于 Kafka 的良好吞吐性能，几乎可以做到 real-time 的使用体验。
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 13:47
  我开头说的 binlog 指的就是你的这种方案，当然你的方案是完整的。不过就算用你的方案，也应该要在应用程序中更新完数据库后立即删除一次吧。只做更新，不先尝试立即删除一次，然后直接交给其他程序异步删除兜底，这样做可以么？
  0 0
  评论

• 

  kidlj 会员

  2022年8月19日 13:47
  不需要立即删除，可以完全避免掉双写的。异步消息几乎是实时的，而且是可重试的，采用 kafka consumer group 还可以多重订阅一个消息。 当然，采用这种方案会带来架构的改变和额外的维护成本。不过我个人的实践来看，这种架构非常灵活，省去了一些传统上需要用分布式事务或者双写带来的复杂性，维护一套 Kafka + connector 还是值得的。
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 13:47
  那应用程序中更新完数据库后，再立即删除缓存一次（哪怕失败也无所谓），然后再用你的方案呢？是不是更好？感觉你的方案依赖性太强了，一旦出事就是灾难性的，所有缓存都不删除了。
  0 0
  评论

• 

  kidlj 会员

  2022年8月19日 14:18
  多立即删除这一次就像是心理安慰，没大用处。Kafka 集群挂了，未消费并 commit 的消息是持久化的，集群恢复以后消息还在，有什么好怕的。
  0 0
  评论

• 

  kidlj 会员

  2022年8月19日 14:18
  如果你指的“灾难性”是指 Kafka 挂掉以后缓存过期的实效性的话，可以适当缩短缓存的存活时间，让它自动快速过期。
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 14:18
  我不担心消息队列丢数据，我担心的是实时性。我在研究研究吧，看看是不是可以省去这一次删除操作，目前我认为省去就会删除不及时。
  0 0
  评论

• 

  tairan2006 会员

  2022年8月19日 14:18
  updateDB 成功了，然后服务挂了
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 14:46
  这种就得用监控 binlog 的方式吧，只要数据库更新成功了，就会事件产生去执行删除缓存操作。是一种情况，但不是我想讨论的问题。
  0 0
  评论

• 

  tairan2006 会员

  2022年8月19日 14:46
  如果你不想做 binlog 方案，另一种方案是给缓存设置过期时间，然后通过过期触发自动更新缓存，这样也可以达到最终一致。
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 14:46
  deleteCache 其实不就是等价于立即过期么。就算设置为立即过期，不还是有问题么？比如： （ 1 ）缓存刚好失效 （ 2 ）请求 A 查询数据库，得一个旧值 （ 3 ）请求 B 将新值写入数据库 （ 4 ）请求 B 删除缓存（或者设置为立即过期） （ 5 ）请求 A 将查到的旧值写入缓存
  0 0
  评论

• 

  sy20030260 会员

  2022年8月19日 14:46
  关乎业务代码的问题，脱离了具体业务场景来做技术选型，无异于纸上谈兵 回归实际业务场景：引入 cache 解决什么问题？引入 cache 之后期望穿透到 DB 的压力有多少？能否接受短时间内的数据不一致？可以的话最长能容忍多久的不一致？如果确实出现不一致会导致什么问题（用户体验下降 or 资损）...具体业务中还会有更多细节。不回答这些问题，实在无法做技术选型 在我遇到的大多数业务场景中，如果已经采用 cache-aside ，大多数情况下就是个逻辑简单、高并发、RT 敏感的读接口。这种业务场景对数据一致性并没有那么强的需求，设置个短一点的缓存过期时间就是了，甚至都不需要引入队列（徒增架构复杂度 在使用 cache-aside 的情况下，还需要纠结两种队列用法之间细微差异的业务场景，可能是我见识太少，实在没见过。如果是真实业务场景的话还希望 OP 分享下，让我也长长见识
  0 0
  评论

• 

  mitu9527 会员 (楼主)

  2022年8月19日 15:17
  我平时也不会引入消息队列，只是简单更新以下数据库，然后删除缓存。虽说讨论有些空乏，但是并不代表问题不存在啊，所以才拉出来讨论啊，不用实现强一致性，但是不是还是应该尽可能更完善一点呢。
  0 0
  评论

• 

  Jooooooooo 会员

  2022年8月19日 15:17
  你把每一步网络交互都假想会失败再看方案 比如第一种方案里, updateDB 你这边超时了, 但是数据库成功了, 还要不要往下走? 如何去补偿. 另外还有并发的问题 比如第一种方案里, 线程 1 updateDB1 成功之后, 线程 2 紧接着去执行 updateDB2, 和 deleteCache2, 然后线程 1 deleteCache1 才执行, 会不会造成数据错乱呢?
  0 0
  评论

• 

  tairan2006 会员

  2022年8月19日 15:17
  你说的这个并不影响最终一致，只要缓存过期时间设置的不太长就没关系。
  0 0
  评论

• 

  sy20030260 会员

  2022年8月19日 15:47
  这个问题当然是存在的，一个更「完善」的方案当然也是值得追求的。但可能我没表达清楚，核心问题在于：没有具体业务场景作为前提，是没法衡量哪种方案更完善的。方案 A 可能在某场景下是完善的，但在其他场景下可能就远远不如方案 B ，而且甚至起到反效果。这种实际业务中是很常见的。 啥叫前提啊？你读取一个数，前提是你要知道进制；你问现在几点，前提是你得告诉我啥时区；你求个坐标，前提是你得知道参考坐标系。不给你参考坐标系你会求坐标吗，不会的话就别绕开业务场景谈什么更完善的技术方案
  0 0
  评论