cloudzhou

@imchuncai

Q 不 set 会有更严重的并发问题
A 你这个问题，和监听驱逐事件是一个类型，就是你说的竞争态：
“在短时间，高版本事件的不设置（不管是驱逐还是没有不处理 update 事件到 cache ），导致低版本进行覆盖”

所以这里我有一个简单处理方案：
*** 引入一个延迟周期，只更新 cache 已有的 key ，这样避免持久相互驱逐，同时更新并发竞态数据 ***
等于你的 3. CDC 触发更新，redis 不存在该 key,所以不更新，这一步，是有一个延迟周期的，确保 “理论上” 覆盖 1 ，4 这个 T 时间周期

一句话总结，按需写 cache 操作（驱逐、更新触发），延迟一个周期，以便覆盖可能历史低版本（读触发）

---

当然，这不是真正并发安全。
但是如果真要做到一致性，这个是好做的。逻辑如你实现方案
你看：
version=1 ，事件 1 ，4 ，是一个事务
version=2 ，事件 2 ，3 ，是一个事务

这两个事务都是同一个 data ，在这里面做分布式锁就可以了

---

更简单的工程实现：
触发事件然后缓存集中处理，也就是没有并发态：
1. 读触发 cache 更新，触发 event: (read, table, id)
2. 驱逐、写触发 cache 可能更新，触发 event: (write/volatile, table, id)
3. kafka 集中监控，按照 table 分区，同一个 table 事件顺序处理
4. 无论是 1 ，2 事件，从 db 拉去新数据，read 操作直接 cas 更新 cache ，write/volatile 一样，cas and only exists

mysql 在 select by id 这一块，速度高的超过你估计，这些事件都意味着对应 table, id 刚访问过，再次读取都只是从 db 的 cache 获取
无论是 ttl ，volatile 都可控

你看这个实际的工程事件：
1. 无论读写，对业务都没任何影响，分发事件可以搞个异步，goroutine channel with max length ，消费不了直接丢弃
2. cache 动态可控，消费点做逻辑，无论是 ttl 还是 update 事件是否进入 cache

@valord577 作为技术方案探讨，也很不错了，毕竟，ai 时代，已经不提技术了 :~

他这套方案，有应用场景，但不是 cache ，而是分布式 lock
lock 要做细腻，也有很多细节可思考：
1. 乐观/悲观，读/写锁，最高并发锁？令牌桶？（问号概念是我拍脑袋的）
2. 锁周期，不能导致资源长期不可用
3. 顺序，以及锁关联的 do once
等等

借助 raft 机制下，做一个全局的分布锁 lib ，用在敏感领域，大家用起来如同本地 lock

@imchuncai
昨天有几个问题没有回答：

Q: 而你的方案所有的操作都会对缓存进行写入，我的方案对热点数据更友好，冷数据的修改可能永远都不会触发写入缓存
A: 其实这是策略问题，我收到 update 事件，也可以根据是否在缓存里然后更新，缓存依然是按需的

Q: 驱逐的问题
A: 依然是策略问题
- 可以根据 ttl 尽量避免驱逐（现实中采取方案，因为 cache 驱逐是非常不好的行为，无法确定驱逐的数据是否重要）
- 在驱逐情况下，你提到的并发问题，可以根据监听 redis Keyspace Notifications 然后一个延迟周期，只更新 cache 已有的 key ，这样避免持久相互驱逐，同时更新并发竞态数据

@laodao 你父母给管孩子，要看你父母是否一起生活，以及相互付出。如果是传统的男方家庭为主，那么这个过程也就隐含着养老

@llCnll 那你可以看一下你有兄弟姐妹亲友没，刚好有孩子的，去当一下“德华”，别臆想，实际全天候带一两天小孩，然后再看看你的想法

这说的，婚恋早期，男性会看起来付出多一点
（放到自然界你就可以理解了，雄性争取配偶还在各种骚操作，人类起码还不需要决斗:0 ）

长久一点看，男女会趋向合作式一起生活，简单说就是日常伴侣
而你提到的所谓现在社会，根本不符合真实场景

女性工作概率很高的，甚至女性更愿意去工作的，没工作大部分反而是家庭原因
家务、孩子啥的，你一个人的话，不需要搞？你确定你带孩子会比女性多？
你父母给管孩子，大部分也隐含了帮你父母养老的义务

@br_wang 并且老板是个技术出身的狂人

@rockddd 单看交互没有多大，但是 ai 会话无状态下，会导致每次会话，其实是交互的前几个上下文，这个等于会话 x10 了。但是也不至于影响带宽。

我在乐鑫工作了三年，乐鑫非常有可能成为一家很 nb 的企业，比如 “边缘 ai 计算” 类似概念