Designing Data-Intensive Applications
Kleppmann把50年分布式系统研究浓缩成一句话：没有银弹，只有权衡——理解取舍比记住某个具体工具值10倍，因为工具会变，原理不变。
- 没有银弹：一致性vs可用性、延迟vs吞吐、简单vs性能，每个数据库都是取舍不是完美方案
- 网络是不可靠的：分布式系统的根本问题是丢包/延迟/分区/时钟不同步，接受不可靠才是真工程
- 日志（append-only log）是分布式数据系统最强抽象：复制是复制日志，数据库是日志加索引
核心观点
没有银弹：每个系统都是权衡，理解取舍比懂工具更值钱
一致性和可用性之间要取舍，延迟和吞吐之间要取舍，简单和性能之间也要取舍。工具会换代，但底层的权衡关系不会变——懂具体工具的人会随技术迭代过时，懂权衡原理的人永远有效。
| 权衡维度 | 选A的代价 | 选B的代价 |
|---|---|---|
| 一致性 vs 可用性 | 牺牲可用性换强一致 | 牺牲一致性换高可用 |
| 延迟 vs 吞吐 | 低延迟通常吞吐受限 | 高吞吐通常延迟增加 |
| 简单 vs 性能 | 简单架构性能天花板低 | 高性能架构复杂度陡增 |
网络是不可靠的：接受这个前提，才能设计出真正健壮的系统
分布式系统的根本问题是：网络可能丢包、延迟、分区；时钟可能不同步；节点可能随时崩溃。把「网络可靠」当默认假设是天真的工程思维，真正的工程能力是为这些不可靠情况提前设计好应对方案。
- 假设网络请求总会成功返回
- 假设多个节点的时钟是同步的
- 为超时、重试、幂等性提前设计
- 用逻辑时钟而非物理时钟排序事件
一致性是光谱不是二元：从线性一致到最终一致有N种中间态
强一致和最终一致不是唯二的选项，中间还有顺序一致性、因果一致性、读己之写、单调读等多种一致性级别。选对适合业务场景的一致性级别，才能同时兼顾性能和正确性——选强一致性能会受损，选太弱正确性会出问题。
日志是分布式数据系统最强抽象：理解日志就理解了80%的系统
复制的本质是复制日志，数据库的本质是日志加索引，流处理的本质是处理日志，快照的本质是日志压缩。这个append-only的简单结构，是分布式系统里几乎所有复杂功能的共同底层实现。
理解append-only日志能解释的系统机制比例
复制/数据库/流处理/快照——全部可以归约到日志这一个抽象
批处理和流处理的边界正在模糊：Lambda架构向Kappa架构演化
Hadoop、Spark做批处理，Kafka、Flink做流处理，这两者曾被视为两条完全不同的技术路线。但本质上两者都是在时间维度上处理日志，现代架构越来越倾向用统一的流处理框架（含窗口聚合）覆盖原本需要批处理才能完成的任务。
| 架构范式 | 核心技术 | 本质 |
|---|---|---|
| Lambda架构 | Hadoop/Spark（批）+ Kafka/Flink（流） | 两套系统并存 |
| Kappa架构 | 统一流处理+窗口聚合 | 批处理是流处理的特例 |
免费部分到这里。墙内还有：
本书与另外 4 本书的观点交锋 · 应用篇
金句摘录
「There is no silver bullet in distributed systems—only tradeoffs.」
「Logs are the most fundamental abstraction.」
「Network failures are inevitable; design for them.」
常见问题
这本书讲了什么？
Kleppmann把50年分布式系统研究浓缩成一句话：没有银弹，只有权衡——理解取舍比记住某个具体工具值10倍，因为工具会变，原理不变。
适合谁读？
从核心观点看，适合想搞清楚「没有银弹：每个系统都是权衡，理解取舍比懂工具更值钱」这类问题的人。
最核心的一个观点是什么？
没有银弹：每个系统都是权衡，理解取舍比懂工具更值钱