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

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

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

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

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

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

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

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

@cloudzhou 不好意思，我说的 redis 不支持跨节点的 lua 脚本的问题是不存在的，因为你的方案是一条一条独立更新的

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

@cloudzhou 你说的多个 cache 更新的问题是在我流程里是不存在的，因为第一步就是 select for update 去拿写锁，所有要改的都已经查出来了。 至于你说的前面一套方案，你还要考虑很多问题，第一你的业务和 cdc 是需要对 key 的格式有约定的，这一点是需要同步的；第二数据库需要维护 version 字段，业务上 insert/update/delete 这些操作你都需要

要问就问，不问拉倒，婆婆妈妈，语无伦次

@inostarling 第一，我没看怎么知道不想看；第二，就算有套路，都套路完了，别说假话了，谁还跟你说话呢

你问他啊，在这问个什么劲，莫名其妙

菜就多练

没有任何调查，张口就来，你眼里的专家级别在我这只是玩具级别

不知所云

自己都学不会，给别人做 app

现在变成我的软广了 Hi Imchuncai, I'm Ivan, founder of XERJ, an open-source, AI-native search engine: it give= s coding agents the exact passage of code or documentation they need instea= d of letting them gues

@v2zzzzz 那他是个毛线的产品经理，他就是你的老大，说白了，你能干就干，不能干就求他评审求他改，还能不干怎地？

你这跟产品经理有什么关系？ 是谁没评审就开发的？是谁不按原型开发的？

@xanthorz not solitaire