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

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

看了一下，select for update 加上 (cache miss)select for share 确实可以实现写时阻塞读，所以我(在 #49)说的竞态确实不存在。

@imchuncai

你关于缓存更新或删除给出的流程图中，我并没有看到释放锁的步骤，只看到“4. 删除 key 或关闭持有 key 锁的连接”后提交事务，我的理解是，删除 key 之后，读写锁应该释放了吧，不然你还能对一个不存在的 key 加读写锁么？

关于 #37 的方案，所有的对缓存的写入都集中到了同一地方（事件消费者），但你认为还存在竞争，我实在想不出具体什么情况还会出现竞争？

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

关于 cloudzhou 在 #37 给出的最终方案，我的理解是，最开始的方案（由 cdc(update/delete) + 客户端(cache miss)更新缓存）会导致竞争，后来的改进的方案（#37 ）是统一由事件消费者异步串行完成缓存填充/更新，从而避免了竞争。

@imchuncai 看具体业务吧，“读都是命中缓存”只适合读多写少的情况，但在更新和删除场景，你的方案也无法保证强一致性，因为数据库的事务作用域无法跨越到外部缓存。比如在更新流程中，如果客户端在删除了缓存之后、提交数据库事务之前发生异常崩溃或回滚，此时数据库数据未变，但外部缓存已经被改了/删了。

你认为 cloudzhou 给出的方案会在缓存驱逐时无法达到最终一致，实际这种情况只有在非常极端情况才会发生（缓存空间太小，导致刚更新的缓存立马遭到驱逐），退一步来讲，如果 key_v2 真遭到驱逐，key_v1 被缓存成功，给 key_v1 设置一个可以最大可以忍受不一致的过期时间就可以了，最终一致性还是可以达到的。

@imchuncai 强一致本身就很难实现，你给出的方法大体可行，代价就是丢失了性能，读写都需要锁，几乎等同于串行，如果涉及到集群，就更复杂了。

@cloudzhou #1 基于 Redis 给出的最终一致性（允许短暂的不一致）方案，即便在这个基础上再做一些修改，还是无法保证强一致性，优点就是性能更好。

@infinityv 开通一个 O'Reilly 试用会员（有效期 10 天），里面两本书的电子版都有，短期内高强度阅读完，如果你看过第一版，两本书的第二版改动都不大，10 天的话应该是够的。

1. 利好苹果。

2. 关于“手工”编珵：

- 从我的观察来看，程序员是一群追求效率的群体，许多工具及 DSL 的发明初衷就是为了减少重复劳动（少打些字）。倘若 AI 能切实替代繁琐工作，推广普及自然会水到渠成。目前 AI 确实能在许多场景提升效率，但并非实现全场景替代。

- 程序员学习使用 AI 并无太大障碍——既然掌握（难的）编程本身，适应（简单的） AI 辅助编程自然也不困难。

- 编写提示词本身也可视为一种编程，只是抽象层次更高点，为何老有人关注程序语言是否是手写的。难道将来也会有人用“嘴工”（口头描述提示）来嘲讽手工输入提示词的程序员？我之前看过一篇报道，即便在电影工业高度发达今天，仍有导演会手绘分镜。电影好看就可以了，管它怎么来的。

- 假设真存在一个 AI 系统（采用最先进的模型和最强 Skill ），你只需输入少量提示词，它就能为你生成一个完全可用的复杂程序。对于你没有提供的信息，系统会用默认值替代，但如果默认值不符合你的需求（例如红紫渐变），根据信息论，你所需的提示词长度可能会无限接近代码本身的长度，甚至有可能超过。

@care 用来学习应该没关系的吧，核心的概念都一样的，不然讲部署一个集群都需要好多章节了吧，我学习的时候，是自己部署了一个 K3s 2 节点集群来学的。

@wenwei1202k 确实，高阶部分（如内部原理和 K8s 扩展）已被删除，因此读过第一版的话，再买第二版的必要性没那么强。此外，第二版第一章对此也有所说明：

> this book focuses on the basics of developing and running applications on a development cluster. Topics such as control-plane high availability, security, cluster installation, and addons are outside the scope of this book but are covered in our follow-up volume.
> 本书主要聚焦于在开发集群上运行应用的基础知识。控制平面高可用性、安全性、集群安装和扩展组件等内容不在本书讨论范围，但会在后续的书中涉及。

简言之，第二版更侧重于实践应用，其他内容将收录于另一本书中。

对于初学者而言，第二版仍然十分值得推荐，图文并茂，浅显易懂。

@YanSeven 这个应该没有授权的吧，翻译的应该不是正式版本，有些许不同，比如 https://ddia.vonng.com/ch10/#sec_consistency_faces , 正式版关于“共识的几种表达方式”列出了 4 种情况，翻译版的只有 3 种，不过对阅读影响不大。

@flyqie 内容变化不大，一些核心概念没有太多变化，删除了一些过期内容（如 ReplicationController ），最大的变化就是单独用一章来讲 Gateway API 。

@liuxiaocs 查看下邮箱，有可能归到垃圾邮件中去了。另外，只有一个月的会员权利，就是为了买这本书开通的，不打算续费。

@liuxiaocs 已经邀请

两本书的第二版都已经按时发布了，看过第一版本的，可以开通一个 O'Reilly 十天试用会员，集中看下更新内容。

假设 AI 真能让效率翻倍，从而使公司整体能力大幅提升，就像给团队进行了免费升级，其直接反应本应是竞争力倍增——好比一个二流团队突然跃升为顶级团队。那么，正常老板第一反应不应该是去开拓市场、提升竞争力、加快交付，反而想着裁员呢？况且，万一竞争对手没有裁员（竞争对手实力大增），又该如何应对？

另外，如果 AI 能胜任大部分工作，那么公司的竞争力又是什么？毕竟模型供应商都是公用的。

就目前基于大模型的 AI 水平而言，它远非万能。模型输出的质量高度依赖于输入，即所谓的“垃圾进，垃圾出（ Garbage in, garbage out ）”，且目前幻觉问题仍无法完全根除。在实际应用中，上下文窗口不仅容量有限，其处理能力还会随着长度接近极限而衰减；此外，上下文污染（引入无关信息）和上下文冲突（指令自相矛盾）也很难完全避免。

更核心的问题在于，自然语言并非理想的编程语言，其天然的歧义性难以完全消除，另外，如何对语言进行组织、规范、复用和调试等也是一大难题。

谈到未来，有几种乐观的可能：
- 程序员若过度依赖 AI ，导致程序员整体水平下降，从而需要更多的程序员。
- AI 降低了编程门槛，但受限于使用者的水平，极易产生大量难以维护的冗余代码，最终仍需（更多的）专业人士介入。

OpenClaw 是一个 AI 构建复杂系统的典型案例。我昨天看了下该代码库，其中 Issue （ 8k+）和 PR （ 6k+）不知是好还是坏，但有一点可以肯定的就是，AI 还不是（在编程领域）万能的。

@wanmyj 如果把房子当成消费品，买房后能大大提升生活质量的话，买房也是不错的选择，最起码没买到最高点。