强一致本身就很难实现，你给出的方法大体可行，代价就是丢失了性能，读写都需要锁，几乎等同于串行，如果涉及到集群，就更复杂了。 #1 基于 Redis 给出的最终一致性（允许短暂的不一致）方案，即便在这个基础上再做一些修改，还是无法保证强一致性，优点就是性能更好。

看具体业务吧，“读都是命中缓存”只适合读多写少的情况，但在更新和删除场景，你的方案也无法保证强一致性，因为数据库的事务作用域无法跨越到外部缓存。比如在更新流程中，如果客户端在删除了缓存之后、提交数据库事务之前发生异常崩溃或回滚，此时数据库数据未变，但外部缓存已经被改了/删了。 你认为 cloudzhou 给出的方案会在缓存驱逐时无法达到最终一致，实际这种情况只有在非常极端情况才会发生（缓存空间太小

你的方案中，关于缓存更新或删除场景下，我好像找到了一个竞态：在删除 key 之后（第 4 步）到提交事务（第 5 步）的短暂窗口，会存在竞态，删除 key 之后，可能存在其他客户端执行缓存未命中路径，因为事务还未被提交，所以其他客户端看到的可能（取决于 db 的隔离级别）是旧数据，写入缓存的也是旧数据。 关于 cloudzhou 在 #37 给出的最终方案，我的理解是，最开始的方案（由 cdc(u

我这里描述的“竞争”就是，同时会有两个程序在无法保证时序的情况下对同一个数据写入（不太严谨）。cloudzhou 提出的方案（仅仅是我的理解）是，只有一个程序（事件消费者）负责写入缓存，任何其他想写入缓存的程序都向它发送事件，你在 #38 中提到的第 8 步，客户端 A 无法直接操作缓存，他最多也就是向 Kafka 发送一个 event: (read, table, id)，最终还是由消费者响应更

你关于缓存更新或删除给出的流程图中，我并没有看到释放锁的步骤，只看到“4. 删除 key 或关闭持有 key 锁的连接”后提交事务，我的理解是，删除 key 之后，读写锁应该释放了吧，不然你还能对一个不存在的 key 加读写锁么？ 关于 #37 的方案，所有的对缓存的写入都集中到了同一地方（事件消费者），但你认为还存在竞争，我实在想不出具体什么情况还会出现竞争？

我理解你的意思，你是想说两个步骤，数据库更新和向 Kafka 发送消息，无法做到原子化（要么全做，要么不做）吧，目前的方案确实可能存在不一致。但是也有补救方案，比如由 CDC 中间件去发送更新/删除的消息。