cloudzhou

@imchuncai 你很适合做一致性高的业务，这个考验很多设计细节，很多人都不会考虑一致性的

@imchuncai 严格从并发安全看这个不够的，这是我之前一个妥协方案，“引入一个延迟周期”，只是说尽量避免

Get cache miss:
1. Get DB
2. set Cache
3. Get DB
4. set cache cas and only exists

这个不知道什么逻辑？ get 两次？

@imchuncai 除了你说的，“发送 event Z 失败” 这种情况，目前最终一致是可以做到的，你再看看我的方案。

而我的意思，你不能把这个失败也纳进来讨论，可以说失去讨论意义了。

@imchuncai

续期的意思就是 GETEX 传入相同的过期时间
过期时间是否相同一点都没影响啊，下次更新就是新的数据了，我们的核心是，旧数据最多 ttl 时间内
你的意思是每次 get 的时候，还延续 ttl ？这个我的实践上，没有这么做的

---
你不能把发送 event z 失败，这个事情纳进来，正如 raft 脑裂整个系统失败了一样。
这么说的话不用举这么复杂的例子，只要 version=1 事件设置 cache 成功，version=2 事件因为各种原因失败就行了，缓存已经不一致

CAP 理论里，只能有两个，而 cache ，实践上都是纳入弱一致性范围。

@imchuncai

你一旦提供 ttl ，你就没法处理用户会续期的行为
cache ttl 是没有续约概念的，只会中途刷新，或者到期消失，影响范围只有 ttl 时间

我再次总结不出现 ttl 范围 cache 不一致的设计：

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

重点：同一个 table 只有一个处理点，消息不管先后乱序，都是 select by id 拉最新数据和 cache 同步

@imchuncai

1. 我的 append 还有两个实现，那个是解决最终一致
2. mysql by id 是真的快，尤其是已经在 innodb cache ，问题是 db 很宝贵，让 db 做事务严格一致的行为
3. etcd 只是一个例子，因为他们就是 raft 协议，只要你要 raft 就存在多节点协商，其实你这个 case ，没有用 raft 的需要
4. raft 所谓的锁，等于一个写指令，对你这里来说也等于多点协商
5. qps 就是最重要的事情，衡量一个技术方案是否可行，对 qps 要有一个非常直观的了解，经典的 Latency Numbers Every Programmer Should Know
https://gist.github.com/jboner/2841832
同样可扩展到对于 raft 、redis 、mysql 读写的 qps 的时延衡量

@naixiangapp 那你的问题，就应该是提出 bug 被改这个问题，而不是去说关了这个 bug 问题

重写 bug 描述，这个不专业

但是：
“是固件问题，不是软件问题，把这个 bug 单关闭吧”

这也不专业，你不能叫测试关闭 bug ，你让测试部门怎么想？
一个具体流程：
开发对于 bug ，解决 or 不需要处理，然后 issue 描述具体上下文，为什么不需要处理，之后交给测试决定就好了

都按流程来，没必要置气，你提你的，我解决我的