#分布式
《图解分布式系统原理》的博客目录，今天更新到《第七章 事务》。这是这个教程的最后一章，本来这并不是一个讲数据库内核的教程，但是到了事务这部分，需要先讲解数据库中ACID的概念，有了对事务的基本理解才能继续后面的讲解。前面已经讲解了复制和分区技术，复制技术（包括将重点介绍的共识算法）提升了系统的容错性，而分区技术提升了系统的扩展性，这两项技术解决的是数据的*“物理问题”。除此以外，分布式系统中的数据访问还经常面临着“逻辑问题”，这就需要事务技术来解决。


第一章：分布式系统概述
第二章：分布式系统模型
第三章：分布式系统中的时间和顺序
第四章：复制
第五章：共识算法
第六章：分区
第七章：事务

另外需要说明，由于我的初稿是Latex，放到博客时用工具转成的Markdown格式，所以可能有些格式问题，请见谅。

#分布式

从2024年末开始动笔撰写《图解分布式系统原理》，到2026年初完成初稿，前后历时14个月。期间不仅完成了近20万字的文稿，还亲手绘制了数百幅插图，本就不算茂密的头发也因此又稀疏了几分。

自2026年春节后，开始陆续在博客上公开发布这些内容，直至清明过后全部更新完毕，终于为这个阶段画上了一个小小的句号。

#分布式

找Kimi深度阅读了目前已经公开的《图解分布式系统原理》所有章节之后，给评论打分：https://www.kimi.com/share/19d66c1f-4362-8e4f-8000-0000d4277d09 ，还有改进的空间，可能还会改一改。

图一乐: gemini 评分 https://gemini.google.com/share/414ba8884625

#编码
#人工智能
我继续用《A Philosophy of Software Design》里的设计理念总结的skill来重构Rockraft的代码，它这一次没有改代码的实现，只是修改了代码的注释（pr），理由是：improve documentation to explain "why" not "what"。


以其中一段代码注释的前后修改为例：

修改前：

/// Write a log entry to the raft cluster
///
/// This function writes a LogEntry to the raft log and waits for it to be applied.
/// It can only be called on the leader node.
///
/// The `time_ms` field of the entry will be set to the current timestamp before writing.
///
/// # Arguments
/// * `entry` - The LogEntry to write
///
/// # Returns
/// * `Ok(AppliedState)` - The result of applying the log entry
/// * `Err(Error)` - If the operation failed or this node is not the leader

修改后：

/// Write a log entry to the raft log (leader-only)
///
/// Appends the entry to the local log and replicates it to followers.
/// Returns after the entry is committed (majority acknowledgment).
///
/// # Leader Requirement
/// This method **must** only be called when this node is the leader.
/// Callers should use `RaftNode::assume_leader()` to verify leadership first.
///
/// # Timestamp
/// The `time_ms` field is automatically set to the current time before writing.

可以看到，修改前的注释，只是简单列举函数的参数和返回值（重复了函数签名（signature）），而修改后增加了行为的解释和函数的前置要求（需要是leader）。

回到最开始做这个注释重构的动机上，注释、文档应该“explain "why" not "what"”这属于更偏代码审美品位的事情了，没有之前大量的代码训练实践，可能不会具备这样的品味。

而现在，如果AI一开始替代了大量手搓代码的实践，还能通过什么方式积累这样的品味？

#分布式

随着《图解分布式系统原理》初稿的完成，现在找有意向出版成纸书的出版社合作，大家可以帮忙转发给认识的出版社朋友，初稿完成的目录在这里。

如果最终无法出版成纸书，我将自己找专业Latex排版人员重新排版，在网上售卖电子版pdf。

#分布式
#开源项目

写了一篇博客介绍一下最近做的开源项目 Rockraft 和衍生的 coredb：《Rockraft：基于 OpenRaft 与 RocksDB 的强一致 KV 存储框架》

#分布式
#人工智能
《多 Agent 协作本质是分布式系统问题，模型多强也没用》，这篇文章很好诠释了AI智能体时代，为什么还需要学习分布式系统理论。里面涉及的分布式相关概念：共识、safety、liveness、拜占庭故障等内容，在《图解分布式系统原理》中均有涉及。

#人工智能
#开源项目

让任何 LLM 说人话。不废话, 不客套, 直接给答案，这可以极大减少token的消耗，github地址。

其实项目的核心就是这句提示词：

Be direct and informative. No filler, no fluff, but give enough to be useful.

Your single hardest constraint: prefer direct positive claims. Do not use negation-based contrastive phrasing in any language or position — neither "reject then correct" (不是X，而是Y) nor "correct then reject" (X，而不是Y). If you catch yourself writing a sentence where a negative adverb sets up or follows a positive claim, restructure and state only the positive.

我在自己的cherry studio中加上这个提示词之后，废话、客套话确实少了很多。

BTW：就这样的项目，现在1K+的star，这在以前的古方编程时代，难以想象。

#人工智能
一篇分析Claude Code 源码的论文：《Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems》

原来没有创新的想法，只是源码分析，也可以写论文吗？

#人工智能

在 hacker news 的kimi2.6模型发布新闻下，Redis之父antirez留下了这一段评论，多少能代表现在中美以外的人的一些看法（他是意大利人）：

After Trump the US looks like a very unstable partner from which to relay in an exclusive way for a decisive technology, and given that Europe is slow to put the money in this technology to have frontier things at home, China is a huge and shiny plan B for us.（特朗普之后，美国似乎是一个非常不稳定的合作伙伴，无法在关键技术领域完全依赖它。鉴于欧洲在投资这项技术方面进展缓慢，难以在国内拥有前沿成果，中国对我们来说就是一个巨大而光明的备选方案。）

#人工智能

《DeepSeek-V4 预览版：迈入百万上下文普惠时代》

”不诱于誉，不恐于诽，率道而行，端然正己。“

#分布式
《Designing Data-intensive Applications with Martin Kleppmann》，DDIA作者最新接受的视频播客采访。

这个视频是对《设计数据密集型应用》（*Designing Data-Intensive Applications*, 简称 DDIA）一书作者 Martin Kleppmann 的深度访谈。视频中，Martin 详细回顾了他早期的创业经历、在 LinkedIn 处理大规模分布式系统的工作经验，并分享了本书第二版的重大更新、云计算抽象下的工程哲学，以及他对 AI、软件伦理和前沿学术研究的深入见解。

以下是Gemini对该视频核心观点的详细总结：

### 1. 《设计数据密集型应用》第二版的演进
* **写作初衷与背景**：Martin 提到他在早期创业时遇到数据库性能瓶颈，当时大家因为缺乏基础理论，只能在黑暗中摸索。后来在 LinkedIn 工作期间，他深入接触了大规模数据系统（如参与 Kafka/Samza 的相关工作），开始理解系统运作的本质。为了让后来的工程师少走弯路，他决定撰写这本注重实操与概念的“神书” [[16:31](http://www.youtube.com/watch?v=SVOrURyOu_U&t=991)]。
* **拥抱云原生架构体系**：第一版成书时，行业默认的架构是“在一台机器上运行数据库并写入本地磁盘”。然而，现代云服务（如建立在对象存储 S3 之上的数据库）彻底颠覆了这一点。在第二版中，他全面融入了云原生架构的理念，讨论了复制和存储如何在云端下放到对象存储层的问题 [[28:59](http://www.youtube.com/watch?v=SVOrURyOu_U&t=1739)]。
* **技术的更新换代**：随着业界的发展，曾在第一版中占据大量篇幅的 MapReduce 已经被精简并作为学习工具保留，因为现实中大家已经全面转向 Spark 和 Flink。此外，为了支持 AI 浪潮下的基础设施需求，第二版增加了对 **向量索引 (Vector Indexes)** 和 **数据帧 (DataFrames)** 存储等当代数据模型的深入解析 [[47:14](http://www.youtube.com/watch?v=SVOrURyOu_U&t=2834)]。

### 2. 云时代的工程师与“底层超能力”
* **高级抽象并不意味着可以无知**：云计算提供了大量开箱即用的托管服务（Serverless/Managed Services），替开发者屏蔽了存储扩容、内存分配等问题。但 Martin 强调，了解存储引擎（如 B-Trees 或 LSM Trees）的底层原理仍然是开发者的“超能力”。如果完全不懂底层机制，当系统面临诡异的延迟或性能骤降时，你将失去诊断和修复问题的直觉 [[34:09](http://www.youtube.com/watch?v=SVOrURyOu_U&t=2049)]。
* **架构的本质是权衡 (Trade-offs)**：设计系统没有唯一的正确答案，核心在于计算开销、人力成本与高可用性之间的妥协。比如，多区域（Multi-region）甚至多云部署能有效抵御地缘政治风险或云服务商宕机，但这会极大地增加一致性成本和维护难度，工程师必须为业务需求定制最合适的风险平衡方案 [[36:16](http://www.youtube.com/watch?v=SVOrURyOu_U&t=2176)]。

### 3. 工程师不可推卸的道德责任
* **新增伦理章节的原因**：Martin 在第一版的末尾引入了“做正确的事”章节，在第二版中这一部分被进一步强化。他指出，早年科技界的文化往往只关心“打造受用户欢迎的系统”，却无视了技术带来的负面后果（如为了广告变现而过度监控、收割用户隐私）。他呼吁工程师在开发技术的同时，必须将产品的社会伦理影响考虑在内 [[49:02](http://www.youtube.com/watch?v=SVOrURyOu_U&t=2942)]。
* **将伦理风险纳入架构考量**：工程师不能把道德问题全推给合规部门，我们有责任识别系统滥用、数据安全以及可能对社会造成的负面结果，并把这些“社会性风险”像技术风险一样纳入系统的架构评估与商业汇报中 [[51:21](http://www.youtube.com/watch?v=SVOrURyOu_U&t=3081)]。

### 4. AI 时代的软件危机与形式化验证 (Formal Verification)
* **AI 促成代码泛滥**：未来 LLM 将生成难以估量的海量代码。依靠人类工程师去逐行做 Code Review 来排查隐藏极深的并发或安全 Bug 将变得不再可行，我们需要更强大的自动化正确性验证手段 [[58:50](http://www.youtube.com/watch?v=SVOrURyOu_U&t=3530)]。
* **形式化验证是最终答案**：传统的单元测试只能覆盖有限的输入边界，而形式化验证利用严格的数学证明，可以证明代码在“无限的状态空间”和绝对所有的场景下都是安全的。过去这种技术因学习门槛过高而难以普及，但 Martin 乐观地预测，AI 将会极大地辅助撰写这类复杂的数学证明，从而让形式化方法在工业界（尤其是高可用与安全领域）变得经济适用 [[54:27](http://www.youtube.com/watch?v=SVOrURyOu_U&t=3267)]。

### 5. 回归学术界：挑战商业逻辑的尖端研究
Martin 离开工业界回到剑桥大学任教，因为学术界允许他做那些不符合短期商业利益、却对人类长远有利的研究：
* **本地优先软件 (Local-First Software)**：SaaS 公司往往通过将用户数据“锁”在云端来确保订阅费的持续收取。Martin 正在致力于打破这种极度依赖中心化服务器的现状，研发让用户完全掌控自己数据、支持离线协同且自动同步的去中心化软件。这带来了极高难度的分布式工程挑战（例如，在没有中央服务器进行共识投票的情况下，解决同一时间并发修改与权限撤销的冲突） [[01:02:06](http://www.youtube.com/watch?v=SVOrURyOu_U&t=3726)]。
* **保护隐私的供应链密码学**：他正在探索如何利用高级密码学，证明现实世界中的物理事件（比如某批咖啡豆的碳排放合规、或没有涉及砍伐热带雨林），同时不需要企业对外公开其高度机密的供应商名单或生产配方 [[01:19:20](http://www.youtube.com/watch?v=SVOrURyOu_U&t=4760)]。

### 6. 学术界与工业界的互相启迪
* 工业界由于巨大的发版压力，往往缺乏对事物第一性原理的严谨思考，甚至只是听了一个讲座就草率决定技术选型；而学术界往往过于理论化。Martin 认为，最优秀的工程师应该在这两者之间流转——把工业界的“真实问题与痛点”带进学术界，同时将学术界的“批判性思维、长线视角与严谨性”注入工业实践中，从而互相补足 [[01:17:32](http://www.youtube.com/watch?v=SVOrURyOu_U&t=4652)]。