按你的理解其实也是一样，这个方案的问题就是向 kafka 的请求是不允许失败的： 1. 客户端 A：Get cache miss, 发送 event A 2. event A 执行，set cache version = 1 3. 客户端 B: Update DB version=2,发送 event B 失败。

发过 Hacker News ，AI 的产出泛滥了，哪里都一样。

一共有两个锁。第 4 步的 key 锁是在 Umem-cache 上的。而事务里拿到的写锁是在数据库的，通过 select for update 拿到的，这个写锁在事务提交后才会自动释放。你说的竟态是被数据库的锁保护住了的。任何试图缓存的客户端都要先读数据库才能取到数据，它会被更新占有的写锁阻塞。 #37 的方案： 我现在有点不理解你说的`竞争`是什么意思了，我一直是把它当作`不一致`来理解的。你

Umem-cahce 是 Redis 作为缓存的替代品,我设计它的初衷就是提供强一致性，这是 Memcached 和 Redis 都做不到的。

绝大部分的读都是缓存命中，不会涉及数据库的锁。然后修改数据，数据库先持有写锁也很必要，能避免并发的修改，这一点不管你用不用缓存都是要这样操作的。 然后我跟 讨论的内容是不涉及强一致性的，他的修改是由 CDC 提交到 redis 的，强一致是不可能达成的。我一直要表的的观点是他的方案保证不了最终一致。

监听 redis Keyspace Notifications 是改不了现状的，只是延长了步骤 10 的时间，只要二次驱逐发生在步骤 11 之前，就没有意义，因为步骤 11 的 version 是在第 5 步拿到的。引入 redis Keyspace Notifications 只是把极限的情况拉到更加极限罢了，此时业务又在不知不觉中变复杂了。另外 Umem-cache 是一个缓存，它有内存上限，

#43 唯一的问题就是第 4 步和第 6 步不可以失败。

我是保证强一致的。第一，Umem-cache 不提供修改的选项，更新和删除在 Umem-cache 都是删除 第二，提交数据库事务之前发生异常崩溃或回滚，Umem-cache 的数据最多是被删掉了，不影响一致性。 你这个过期时间确实可以达到最终一致，这跟定时清空缓存差不多，只要缓存没数据，就是一致的。你一旦提供 ttl ，你就没法处理用户会续期的行为，只要用户持续续期，这个不一致就会影响很久。 你

是 get 两次，防止中间有被驱逐的更新。

1. 你的延迟周期我是不认同的，它是很侥幸的，没有任何保证的。 2. 我不能同意你说的 mysql 在 select by id 这一块，速度高的，因为我一旦同意这个，缓存就没有存在的意义了。 3. Umem-cache 和 etcd 是不一样的东西。etcd 的本质是持久化的数据库，它的集群中的每一个节点都存相同的数据，它的命令都是要靠 leader 来执行，它要求多数节点完成执行，而且这个执行

我的续期的意思就是 GETEX 传入相同的过期时间 然后你的方案： 1. 客户端 A：Get cache miss, Get DB version=1 3. 客户端 B：Update DB version=2, Update cache version=2, 发送 event X 5. event X 触发, Update cache version=2 6. cache 驱逐, 发送 event

如果 key 被驱逐了就重新 Set ，只会反复触发驱逐。

我的系统就是放弃了可用性来换取一致性，而你的方案是放弃了一致性来换取可用性。就是取舍的问题，我的观点就是你的方案最终一致也不能做到。

查看#33 的第 4 点。

这个竟态在我的方案里是被数据库的锁保护住了的，因为事务提交之前更新操作持有该 key 的写锁，其他客户端缓存未命中要获取读锁，会被阻塞，因为要等写锁释放。 #37 的方案没有避免掉竞争，而是在每一个可能导致不一致的操作后面都跟了一个同步 cache 和 db 数据的操作。

数据库更新和向 Kafka 发送消息是可以做到原子化的，方案其实就是我 update 的方案，把向 Kafka 发送消息放进数据库更新的事务里。 然后你说的补救方案是没问题的，前提是要按你的理解，不让客户端去操作 redis 。但是这样一来你又处理不了缓存击穿的问题了。于是你又得让客户端可以去 set cache ，你一旦打开这个口子，我就有办法让它 set 进去过时的数据去破坏最终一致性。 所以

第一个问题：我又想了下，不 set 会有更严重的并发问题，相当于此时没法用 version 去避免覆盖了 1. 客户端 get key ，miss ，查数据库 version=1 2. 数据库更新，version=2 3. CDC 触发更新，redis 不存在该 key,所以不更新 4. 第 1 步在查询完成后 set redis version = 1 第二个问题:监听驱逐事件会触发数据库的读取

不明白你说的，缓存只是加速查询。更新本来就是只依赖 db ，也就是 select for update ， 是绝不可能从缓存查数据的。

在所有服务和网络都正常的情况下，你的方案是可以做到最终一致的，因为缓存变更和数据库变更的后面，都会跟一个序列化的缓存和数据库同步操作。

我就是有强迫症的，我才设计了 Umem-cache 来引入强一致的方案。我是很满意这个方案的，同时解决了一致性和缓存击穿的问题。

酒逢知己千杯少 这是我写的 Umem-cache: https://github.com/imchuncai/umem-cache 第一个问题：你说的是对的，我昨天也是想过了，确实是策略问题，CDC 甚至可以直接选择 delete 操作，就跟我的方案一样了 第二个问题：我设计 Umem-cache 是直接不支持 ttl ，我认为这很烦人，很多时候我根本就不知道要设多久。我是统一采用了 S3-FIF

在所有服务和网络都正常的前提下，可以简化一下你的方案，看看对不对： Get cache miss: 1. Get DB 2. set Cache 3. Get DB 4. set cache cas and only exists Update: 5. Update DB 6.。

你给的方案太多了，我有点绕不过来了，而且越来越复杂，引入的组件越来越多。

在我的步骤里读写 cache 没有失败，只是有延迟。缓存最重要的就是驱逐的设计，而数据库是没有驱逐的。

有时间看看 README 也不至于写这么大一段。 1. cache 命中和吞吐的优势不是我张嘴就来的，talk is cheap 。README 有基准测试项目的链接，谁都可以复现，你也可以去看详细测试结果。而且这个基准测试是得到同行认可的： https://github.com/kividbio/kividb/issues/202 2. Umem-cache 就是一个缓存,不是什么分布式锁，认为

还有个一理论上存在比较极限的一个情况，比中途引入 redis 更极限，会破坏最终一致性： 1. 连接 1 cash miss ，get 数据库 version = 1, set redis 还没发射请求 2. 连接 2 更新数据库 version = 2, cdc set redis version = 2 成功 3. redis 因为缓存压力驱逐了该 key ，在中途迁移的情况是，大量 key

你可能没理解我 10 楼说的情况，我说的就是 db 有 version 列的情况下，没法达到最终一致。我画个图： :: 客户端 redis 数据库 1.客户端 A：get key |------------------------->| | 2.未命中 3.返回 miss | |<-------------------------| 4.客户端 A：get key |---------------

如果是中途引入 redis 呢？你这种方案应该怎么操作？应该会很比较复杂吧。

我的方案只有 Get 操作才会对缓存进行写入，而你的方案所有的操作都会对缓存进行写入，我的方案对热点数据更友好，冷数据的修改可能永远都不会触发写入缓存。

另外在部署集群的情况下多个 cache 更新，redis 连最终一致性都保证不了，因为 redis 不支持跨节点的 lua 脚本。