《设计数据密集型应用》(DDIA, 2nd ed.) 心智模型导览——《Designing Data-Intensive Applications》书介绍导航

《设计数据密集型应用》(DDIA, 2nd ed.) 心智模型导览——《Designing Data-Intensive Applications》书介绍导航写给还没读过这本书、想先在脑子里有张地图的读者目的装上6 个内容枢纽——不只是抽象概念每个枢纽下面挂着这本书真正讲的具体子概念、权衡轴、和真实产品基于Martin Kleppmann Chris Riccomini《Designing Data-Intensive Applications》第二版O’Reilly, 2026 年 2 月导航一、这本书在解决什么问题二、锚点命题抽掉这一句整本书就站不住]三、六个内容枢纽]3.1 枢纽一三角约束可靠 / 可扩展 / 可维护3.2 枢纽二两类系统物种OLTP vs OLAP3.3 枢纽三分布式的两个正交维度复制 / 分片3.4 枢纽四故障是常态部分故障是一等公民3.5 枢纽五一致性是连续谱一致性与共识3.6 枢纽六派生数据 Dataflow 架构四、六个枢纽之间的结构关系五、读这本书前后应该问自己什么附新版相对一版的变化一、这本书在解决什么问题1.1 它面对的具体场景你正在构建一个会被人使用的软件系统——它要存数据、找数据、改数据、算数据。一旦数据量或用户量超过一台机器跑 Postgres 一个 Redis 就够的临界点你立刻撞上几十个问题选哪个数据库要不要拆库分表要不要加缓存要不要做副本要不要分布式要不要分析数仓要不要消息队列每个选项后面都有十几种现成产品——MongoDB、Cassandra、Kafka、Snowflake、ClickHouse、Pinecone……DDIA 不教你用其中任何一个具体产品。它教你怎么判断这些产品在底层做了什么权衡从而选得对。1.2 作者真正在反对谁这点很重要——一本全面综述和一本有论敌的书是两件不同的东西。DDIA 是后者。论敌表现形式单一技术普适论“Oracle 关系型解决一切” → “MongoDB 文档型替代 SQL” → “Snowflake 云数仓搞定所有分析” → 当下的 “向量数据库是 AI 时代的新基建”学院派纯粹主义把分布式系统理论当形式游戏写出脱离工程现实的论文工程师的技术身份认同把工具选择当人格符号“我是 Rust 派 / 我是 Postgres 派”而非工程决策云供应商的封装叙事二版新增“用我们的全托管服务就不用懂这些”——书的存在本身就是对这种姿态的反驳精神血脉来自 Michael Stonebraker 2005 年的论文“One Size Fits All: An Idea Whose Time Has Come and Gone”——这是 DDIA 的圣经。1.3 这本书不适合谁只写 CRUD 应用、数据量小到 Postgres 单机就够的开发者——杀鸡用牛刀想找具体产品教程的人“教我用 Kafka”——这本书不教操作教原理纯研究分布式协议的学者——它不够形式化会嫌不够严谨二、锚点命题抽掉这一句整本书就站不住数据系统不存在普适最优解——任何技术选择都是在硬约束下的权衡决策声称某某技术解决一切的论断必然为错。作者在第 1 章开篇用 Thomas Sowell 的题词把这一句钉死“There are no solutions; there are only trade-offs. But you try to get the best trade-off you can get, and that’s all you can hope for.”——这一题词在一版里没有二版作者意识到 AI/云时代的银弹叙事更猖獗了所以把锚点显式化。三个论证支柱物理与数学约束——CAP 定理、FLP 不可能性、网络异步、存储层级速度差……这些是数学/物理保证的硬边界。即使你想做全能系统物理上不允许。三个非功能维度彼此牵制——可靠性、可扩展性、可维护性互相拉扯优化任一维度都有代价。真实大型系统的组合性——LinkedIn、Google、Netflix 的内部数据栈都是多种系统组合没有一个用单一技术栈走到底。这个锚点可以怎么被证伪如果存在一种数据系统真的同时满足——高一致 高可用 分区容忍 高吞吐 低延迟 易维护 灵活演进——那 DDIA 整本 600 多页就是废话。作者明确知道自己押在这里。这种自觉性反而是可信度的来源。证伪的概率极低——因为锚点的根基是 CAP、FLP 这类已经数学证明的不可能性定理。三、六个内容枢纽这一节是这份导览的核心。每个枢纽不是一个抽象标签而是一个内容容器——里面装着这本书在那个方向上真正讲的子概念、权衡轴、真实产品。读完六个枢纽你应该能在听到任何数据系统相关的术语如 “LSM-tree”、“Raft”、“CDC”、“Snapshot Isolation”时立刻知道它在哪个枢纽下、解决什么问题。3.1 枢纽一三角约束可靠 / 可扩展 / 可维护数据系统必须同时关心三件事故障下仍正确可靠性、负载增长下仍能用可扩展性、长期演化下仍可改可维护性。三个维度互相牵制所有技术决策都是在三角上选位置。这个枢纽统领的子概念群A. 可靠性Reliability一族Fault vs Failure— fault 是组件层小问题一块磁盘坏failure 是系统层整体崩用户看不到服务。容错的目标是把 fault 隔离住不让它升级成 failure故障类型分层硬件故障——磁盘、内存、电源通常独立可用冗余解决软件故障——bug、级联失败往往强相关难处理人为故障——配置错误、误删是最大的故障源头之一Metastable failures二版新增—— 系统进入自维持的坏状态如雪崩重试用指数退避、断路器、负载脱卸缓解Blameless postmortems—— 不追责的事故复盘文化从事故中学习B. 可扩展性Scalability一族度量负载QPS、读写比例、活跃用户数每种应用有自己的主导参数度量性能用 P50/P95/P99 百分位不能用平均值——尾部延迟才是用户体验的真实指标“Tail at scale” 问题随系统规模上升单个请求触发更多下游调用P99 变成主导三类基础架构Shared-memory垂直扩展简单但单机有上限Shared-disk多机共享存储Shared-nothing水平扩展大型系统的事实标准C. 可维护性Maintainability一族——三个子分量Operability让运维生活容易可观测性、自动化、监控Simplicity管理复杂度好的抽象、低耦合Evolvability / Irreversibility可改性不可逆操作如不能切回旧数据库是最大的演化障碍核心权衡优化 X代价典型例子更强可靠性成本上升、复杂度上升多副本 vs 单机更大可扩展性一致性下降、维护性下降分片 vs 单库更易维护可能牺牲性能简单架构 vs 极致优化真实产品在三角上的位置SQLite / 单机 PostgreSQL易维护可扩展性低DynamoDB可扩展性极强但用法受限、调优难Spanner兼顾强一致扩展性但成本极高、运维门槛高对应章节Ch2 专门讲但三角贯穿全书3.2 枢纽二两类系统物种OLTP vs OLAP数据系统大体分两类——OLTP 服务每天业务读写点查询、个位数行操作、OLAP 服务分析查询扫几百万行算聚合。它们的存储结构、索引、查询模式都不一样。这个枢纽统领的子概念群A. OLTP 侧——两大存储引擎流派Ch4 的核心对立流派机制代表产品强项Log-structured日志结构只追加定期合并崩溃后从日志恢复LSM-tree → RocksDB、Cassandra、HBase、ScyllaDB、Lucene 索引层写吞吐高Update-in-place原地更新固定大小页可覆盖写WAL 保崩溃一致B-tree → 几乎所有关系型数据库 很多 NoSQL读吞吐高、响应快关键辅助技术Bloom filterLSM 加速读、WALB-tree 崩溃保护、覆盖索引covering index、多列索引、In-memory 数据库Redis、VoltDBB. OLAP 侧——为分析重新设计的存储列存Column-oriented storage同一列数据连续存放——压缩率极高同列数据相似、扫描时只读需要的列。代表Parquet、ORC、ArrowSnowflake / BigQuery / ClickHouse / Druid 内部都是列存向量化执行 / JIT 编译把查询编译成 SIMD 优化代码Materialized views data cubes预计算常见聚合Vector embeddings二版新增高维向量索引——HNSW、IVF服务 RAG、推荐、相似度搜索Full-text search倒排索引Lucene 是事实标准底层C. 配套术语Data warehouse数仓vsData lake数据湖vsLakehouse湖仓一体ETL / ELT把 OLTP 数据搬运到 OLAP 的过程Star schema / Snowflake schema分析数据的经典建模法System of record vs Derived data连接到枢纽 6核心权衡 — 一个系统能不能两边都好物理上不行列存对 OLTP 的点查询是灾难要重组多列行存对 OLAP 的聚合也是灾难。折中尝试HTAPHybrid TP/AP系统如 SingleStore、TiDB——代价是复杂度极高主流做法OLTP 做真相源 → ETL/CDC → OLAP 做派生这就走向枢纽 6典型产品分类类型代表底层OLTP 行存PostgreSQL、MySQL、MongoDBB-treeOLTP LSMCassandra、HBase、ScyllaDBLSM-treeOLAP 数仓Snowflake、BigQuery、Redshift列存 MPPOLAP 实时ClickHouse、Druid、Pinot列存 索引优化向量Pinecone、Weaviate、pgvector、LanceDBHNSW / IVF全文Elasticsearch、OpenSearch、MeilisearchLucene 倒排索引对应章节Ch1分类 Ch3数据模型 Ch4存储引擎深度展开3.3 枢纽三分布式的两个正交维度复制 / 分片当数据 / 流量超出单机能力只有两个独立机制复制每台机器存同样数据和分片每台机器存一部分数据。它们正交——可以单做也可以叠加。这个枢纽统领的子概念群A. 复制Replication, Ch6——三大模式模式写法代表强项 / 代价Single-leader单主一个 leader 接受写复制到 followersPostgreSQL 主从、MySQL replication、MongoDB replica set易理解、强一致缺点是 leader 是单点Multi-leader多主多个 leader 都能写互相同步CouchDB、Galera、地理分布的 Postgres适合多区域 / 离线工作必须处理冲突Leaderless无主客户端同时写 N 个副本读时从多个副本取Cassandra、Riak、DynamoDB部分模式容错性强一致性弱B. 复制的几个核心机制同步 vs 异步复制同步——写要等所有副本确认慢但不丢数据异步——写到 leader 就返回leader 挂了刚提交的数据可能丢失最容易被忽略的灾难半同步——折中复制日志的实现基于语句、基于行行级、基于 WAL、逻辑复制故障切换failover自动 vs 手动自动切换有脑裂风险C. 复制延迟下的一致性问题读自己的写read-your-writes、单调读monotonic reads、一致前缀读consistent prefix reads——这些是最终一致和强一致之间的中间档详见枢纽 5。D. 冲突解决多主 / 无主必须面对LWWlast-write-wins简单粗暴可能丢写Version vectors检测并发写CRDTs无冲突复制数据类型数学保证可合并的数据结构——这是 sync engine / local-first software 的基础二版新章节E. 分片Sharding, Ch7——两大策略按 key range按键范围每个分片管一段连续的 key优点范围查询好如时间范围缺点容易热点如最新日期的数据全打到一个分片按 hash of key按键哈希哈希均匀分布优点负载均匀缺点范围查询要扫所有分片F. 分片的几个核心机制Hot spots / Skewed workloads明星用户问题书里举了 Bieber 占 Twitter 3% 服务器的真实例子需要二次拆分Rebalancing节点加入/退出时数据重新分布——一致性哈希是常见方案请求路由客户端直接路由 / 路由层mongos/ service discovery 协调服务ZooKeeper、etcd、Consul二级索引的分片难题本地二级索引——写快读慢要查所有分片全局二级索引——读快写难要分布式事务真实架构组合模式代表单主 不分片PostgreSQL 单机单主 分片VitessMySQL、CitusPG无主 分片Cassandra、DynamoDB多主 分片CouchDB、Riak共识 分片CockroachDB、TiDB、Spanner对应章节Ch6复制 Ch7分片3.4 枢纽四故障是常态部分故障是一等公民分布式系统中部分故障是默认状态——某节点挂、某链路断、某时钟跑偏但其他部分正常。单机假设全部成功 vs 全部失败分布式必须把半成功半失败当作正常情况设计。这是从单机到分布式的核心心智跃迁。作者在 Ch9 直接写“In distributed systems, suspicion, pessimism, and paranoia pay off.”这个枢纽统领的子概念群A. 网络是不可靠的Ch9TCP 不解决问题——它只让字节流可靠延迟 / 连接断开 / 网络分区都还在Network partition网络分区部分节点能互相通信但和其他部分不能你永远无法区分对方挂了和网络断了——这是分布式系统最基本的不确定性真实世界的故障源头交换机、网线、电源、空调、鲨鱼咬海底光缆书里真的举了这个例子、海狸啃光纤、误操作 BGPB. 时钟是不可靠的Ch9Time-of-day clock墙钟可以跳跃、可以倒退NTP 同步、闰秒绝不能用于排序Monotonic clock单调钟保证不倒退但只在本机内部有意义逻辑时钟用因果关系代替物理时间Lamport timestamps全序但不能区分并发Vector clocks能检测并发Hybrid Logical Clocks (HLC)结合物理 逻辑TrueTimeSpanner 用基于 GPS 原子钟保证有界误差——成本极高时钟漂移即使开 NTP节点时钟差几十毫秒是常态几秒钟也不罕见依赖同步时钟做关键决策如租约过期 等着出事C. 进程暂停Ch9GC 暂停JVM / Go 的 stop-the-world 可能 100ms 到几秒虚拟机迁移、CPU 抢占、磁盘 I/O 阻塞——都能让一个进程消失几秒钟后果被其他节点判定为死亡但自己以为还在工作 → 脑裂D. 故障检测的根本困难心跳 超时——但超时设多少短了误判长了响应慢不可能完美检测——FLP 不可能性定理在说这事失效慢fail-slow的节点比直接挂掉更难处理——它在响应但慢到拖垮整个系统E. 知识、真相与谎言Ch9真相由多数派决定quorum不靠单点判断谁是 leaderFencing tokens单调递增的 token 防止假 leader伤害数据拜占庭故障Byzantine faults节点不只是挂还能说谎除区块链等特殊场景大多数数据系统假设非拜占庭系统模型同步 / 半同步 / 异步崩溃-停止 / 崩溃-恢复 / 拜占庭——证明任何算法正确性都得说清楚假设的模型F. 形式方法 随机化测试二版新增TLA用形式化语言描述系统、机器验证正确性AWS、MongoDB 在用Deterministic simulation testingFoundationDB、Antithesis、TigerBeetle 用的方法——把所有非确定性时钟、网络、调度替换成可控的在模拟中跑无数种故障组合Jepsen 测试Kyle Kingsbury 的工作已经把被 Jepsen 测过做成了分布式数据库的事实标准认证反直觉的核心洞察“我们可以用一堆不可靠的机器拼出比单机更可靠的系统。”但前提是要明白每一个组件都可能以你想不到的方式坏并设计相应的容错——这就需要枢纽 5 的工具。对应章节Ch8事务 Ch9故障的本质 Ch10解决方案3.5 枢纽五一致性是连续谱一致性与共识数据库的一致性不是布尔值。从最终一致 → 因果一致 → 线性一致是一个连续谱。越强一致 越多协调 越慢 可用性越低。选择哪一档是核心工程决策没有最强一致的银弹。这个枢纽统领的子概念群A. 事务与隔离级别Ch8ACID 的真实含义——很多人对 ACID 的理解是错的Atomicity原子性全做或全不做Consistency应用层不变量保持注意这个 C 和 CAP 的 C 不同Isolation并发不互相干扰Durability提交后不丢弱隔离级别——为了性能放松 Isolation级别防止什么残留问题Read Committed不读未提交的脏数据不可重复读Snapshot Isolation / Repeatable Read整个事务看同一快照多数数据库的默认级别写偏write skew、幻读phantomSerializable看起来像事务一个个串行执行最贵Serializable 的三种实现Actual Serial Execution真的串行VoltDB、Redis 单线程Two-Phase Locking (2PL)传统锁机制慢Serializable Snapshot Isolation (SSI)乐观并发性能好PostgreSQL、CockroachDB 用这个分布式事务Ch8 末2PC两阶段提交跨多节点的原子提交脆弱、阻塞、易脑裂XA跨系统事务标准现代系统大多在弃用现代趋势用 Saga 模式 idempotent 重试代替分布式事务连接到枢纽 6B. 一致性模型谱Ch10档位保证代价适用Eventual等够久了一致过程中可能乱最便宜、最快点赞数、评论计数Read-your-writes你能看到自己刚写的较便宜个人设置类Monotonic reads不会时光倒流看到旧数据较便宜阅读类应用Consistent prefix因果顺序保留中等社交媒体时间线Causal consistency所有因果相关操作顺序一致较贵协作编辑Linearizability整个系统像一台机器每读拿到最新最贵——要跨节点协调账户余额、库存计数、锁关键洞察更强一致 ≠ 更好。Instagram 点赞数选最终一致是对的银行账户余额选线性一致也是对的。C. ID 生成与逻辑时钟Ch10 重要新内容单机自增 ID线性一致但不容错UUID分布式生成但无序Snowflake-style ID时间戳 节点 ID 序列号有序但依赖时钟Lamport timestamp / HLC保证因果序但不是线性一致现代选择越来越多——这一节是二版重写章节的重点D. 共识Consensus, Ch10 的核心共识 让一组节点对某件事的决定达成一致即使有节点挂掉 / 消息丢失主流共识算法Paxos——理论先驱实现极难Raft——最易理解etcd、CockroachDB、TiDB、Consul 用它Zab——ZooKeeper 用的关键不变量Committed write 不丢失不出现脑裂两个 leader 同时接受写实现方式每次写、每次线性化读都需要多数派quorum确认书的核心洞察——一系列问题都等价于共识等价问题它在系统中是什么线性化 CAScompare-and-swap原子寄存器锁 / 租约分布式锁唯一性约束唯一索引、用户名注册共享日志total order broadcast复制日志原子提交跨节点事务Leader 选举failover解决其一就解决全部——这是为什么 ZooKeeper、etcd 这类协调服务如此重要它们把共识封装成原语你直接用就行。E. CAP 的真实位置CAP 在二版被淡化了——不是因为错是因为太粗糙。现代讨论更精细PACELCpartition 时 A/C 取舍 没 partition 时 latency/consistency 取舍才是更现实的框架。PACELC是 CAP 定理的扩展ifPartition → 在Availability 和Consistency 之间选Else → 在Latency 和Consistency 之间选。它戳破了 CAP 的盲点——CAP 让人以为没分区就没烦恼但强一致永远要付钱分区时付的是可用性平时付的是延迟跨节点协调一次就是几十到几百毫秒。主流系统大多在两个对角Cassandra/DynamoDB 属于 PA/EL始终选可用低延迟Spanner/CockroachDB/etcd 属于 PC/EC始终选一致付协调延迟的钱。真实产品的一致性档位产品默认档位PostgreSQL 单机Serializable如选 SSI/ Read Committed默认MySQL 单机Repeatable Read默认MongoDB可配置默认偏弱CassandraEventual可调到 Quorum-basedDynamoDBEventual可选 StrongSpanner / CockroachDBLinearizable基于共识 TrueTime/HLCetcd / ZooKeeperLinearizable专门做协调对应章节Ch8事务 Ch9不可能性 Ch10共识二版几乎完全重写3.6 枢纽六派生数据 Dataflow 架构大型系统不是一个数据库是一个 system of record 多个派生表征。系统不是存数据的盒子是数据从权威源头流向多个被消费形态的管道。一旦接受这点event sourcing、CDC、stream processing 都自然落地。Ch13 引 Thomas Aquinas“如果船长最高目标是保住船他会让船永远停在港口。”—— 数据系统不是为了保存数据而存在是为了被使用。这个枢纽统领的子概念群A. 为什么必然走向多系统组合Ch13 开场论证没有一个软件能同时高效服务所有访问模式这是锚点命题在数据集成层面的具体化复杂应用必然要把数据存在多种形态OLTP 数据库 全文搜索索引 缓存 数据仓库 ML 特征库 推荐系统……问题变成如何让这些系统保持同步两种方案的对决方案机制优缺点分布式事务2PC原子提交保证一致慢、脆弱、跨系统难派生数据log-based dataflow用日志做真相源下游异步派生可恢复、可重跑、可扩展DDIA 明确押注后者。B. 批处理Ch11Unix philosophy小工具组合管道 标准输入输出——这是 dataflow 思想的源头MapReduce作者明确称为 “now largely obsolete”二版重要变化一版当核心讲的内容现在被砍光Dataflow enginesSpark、Flink、Beam——比 MapReduce 更灵活、更快DataFrames二版新增重点Pandas、Polars、Arrow——为 ML 训练数据准备而生典型用例ETL、analytics、ML 训练数据准备、服务派生数据C. 流处理Ch12消息系统的两种风格风格机制代表经典队列AMQP 风格消息消费后删除RabbitMQ、ActiveMQ基于日志的消息队列消息持久化、可重读Kafka、Pulsar后者是 dataflow 架构的物质基础——可重读意味着下游派生系统可以从任意点重建。核心机制Change Data Capture (CDC)把数据库的变更流出来给下游——Debezium 是事实标准Event sourcing把事件流本身当真相源状态是从事件计算出来的流处理用途监控告警、复杂事件检测、维护派生数据、流式分析时间是流处理的核心难题event time vs processing time、watermarks、窗口故障容忍exactly-once 语义、checkpointing、idempotenceD. 派生数据架构Ch13 的哲学核心概念System of record数据进入系统的第一个地方唯一真相源Derived data从真相源算出来的——可以重算、可以丢失再重建关键心智转变派生数据丢了不可怕因为可以从源头重新派生“Unbundling databases”传统数据库内部做的事索引、视图、查询优化现在拆出来用独立组件实现E. End-to-end 原则与正确性Ch13数据库提供的不变量只在它内部有效端到端的正确性要在应用层保证Idempotence end-to-end request IDs用幂等性 全局唯一 ID 代替分布式事务异步约束检查 必要时道歉很多业务实际上能接受先做了再道歉——这比维持严格强一致便宜得多Trust, but verify用审计 数据完整性检查代替事前严格保证这里和区块链思想有相似性F. 二版新增的相关主题Durable executionCh5Temporal、Restate、Inngest——把整个工作流当成可恢复的状态机MCP / AI Agent 系统本质上是这类问题Sync engines local-firstCh6CRDT 让本地优先软件成为可能和 Kleppmann 自己 2019 的研究方向一致Workflow engines把业务流程建模成 dataflow——这是后端开发越来越主流的范式真实落地的派生数据架构[用户写入] │ ▼ [OLTP 数据库] ←── system of record │ │ CDCDebezium ▼ [Kafka 日志] ←── 不可变事件流是真相源的延伸 │ ├─► [Elasticsearch] ←── 派生全文搜索 ├─► [Snowflake] ←── 派生数仓分析 ├─► [Redis] ←── 派生:缓存 ├─► [向量库] ←── 派生语义检索 / RAG └─► [ML 特征库] ←── 派生:模型训练数据任何派生系统坏了 → 从 Kafka 重放即可重建——这就是为什么这种架构既容错又灵活。对应章节Ch5部分 Ch11批 Ch12流 Ch13哲学全书精神归宿四、六个枢纽之间的结构关系4.1 主轴从单机到分布式到多系统组合这条主轴与书的章节顺序基本一致——Kleppmann 是按这条心智路径组织全书的。[起点单机数据系统] │ ▼ 枢纽 1三角约束可靠 / 可扩展 / 可维护 │ ← 元约束所有其他枢纽都在三角内取舍 │ ▼ 枢纽 2OLTP vs OLAP 物种分类 │ ← 把后续讨论分两条主路 │ ▼ [临界点单机已不够] │ ▼ 枢纽 3复制 / 分片 两个扩展机制 │ ← 一旦走分布式 │ ▼ 枢纽 4故障是常态partial failure 心智 │ ← 分布式的**前提心智**不接受这点5/6 都白讲 │ ▼ 枢纽 5一致性谱 共识 │ ← 在故障前提下你能保证系统看起来像单机到什么程度 │ ▼ [终点单系统也不够] │ ▼ 枢纽 6派生数据 / dataflow 架构 ← 多系统组合的架构原则4.2 哪个枢纽是其他枢纽的前提枢纽它的前提是没有它谁讲不通枢纽 1三角无元约束所有枢纽 2OLTP/OLAP枢纽 1枢纽 6枢纽 3复制/分片枢纽 1枢纽 4、5、6枢纽 4故障是常态枢纽 3枢纽 5、6 都依赖它枢纽 5一致性 共识枢纽 3、4枢纽 6枢纽 6派生数据枢纽 2、3、4、5 都需要——关键依赖枢纽 4partial failure是分布式心智的元前提。如果你只能选一个枢纽带走应该选这个——它是从单机思维切换到分布式思维的最关键跃迁。4.3 初学者最容易理解错的反直觉点复制 ≠ 备份—— 复制是实时的、为可用性服务备份是定期的、为灾难恢复服务。两件不同的事一致性不是布尔值—— 不能问这个数据库一致吗要问它提供哪一档一致性ACID 的 C 和 CAP 的 C 是两个 C—— ACID 的 C 是应用层不变量CAP 的 C 是线性一致性这是历史命名混乱更强的一致性 ≠ 更好的系统—— 强一致 更多协调 更慢 可用性更低TCP 可靠 ≠ 网络可靠—— TCP 只保证字节流不乱序不丢但连接断、超时、分区都还在MapReduce 已过时二版重要变化—— 不要再花时间深入学 MapReduce学 Spark/Flink/Beam派生数据丢了不可怕—— 这是最反直觉的心智之一多数人本能想备份所有东西但 dataflow 架构告诉你派生数据可以重算五、读这本书前后应该问自己什么5.1 读之前问自己决定要不要读、读哪几章我现在面对的具体决策是什么做架构设计 → 通读 Ch1-2、6-7、9-10选数据库 → Ch3-4准备 system design 面试 → 通读仅好奇 → 读 Ch1-2 任选一章看深度我的应用是 OLTP 主导还是 OLAP 主导OLTP → Ch4 前半 Ch6-10OLAP → Ch4 后半 Ch11两者都有多数复杂应用 → 全书我是否真的需要分布式数据量 1TB、QPS 1万 → 单机基本够Ch6-10 可略读数据量大或多区域用户 → 分布式章节是核心5.2 读之后能不能回答建立心智模型的检验读完书 装上 6 个枢纽后你应该能给一个具体场景如做一个支持 1000 万用户的社交 App 时间线说出它涉及哪几个枢纽的权衡以及在每个枢纽上的选择当有人说X 数据库最适合所有场景给出反例并说出反例为何成立在你自己的项目里识别真相源和派生视图给一个系统出错了的场景如用户看到点赞数忽大忽小从一致性谱定位问题听到任何术语LSM-tree、Raft、CDC、Snapshot Isolation、CRDT立刻能说它在哪个枢纽下、解决什么问题如果第 1、2 题答不出来 没读懂锚点3-5 题答不出来 内容没装进认知系统。附新版相对一版的变化如果你或身边有人读过 2017 一版这是 2026 二版的真实 diff基于作者在 Preface 的自述新增向量索引Ch4—— 服务于语义检索 / RAGDataFramesCh3—— 服务于 ML 训练数据Durable execution workflow enginesCh5—— Temporal、Restate 一类Sync engines local-first softwareCh6—— CRDT、本地优先软件Formal methods 随机化测试Ch9—— TLA、deterministic simulation testingGraphQLCh3GDPR 与法律语境Ch1、Ch14Cloud native思路贯穿全书基于对象存储而非本地盘Metastable failuresCh2删除/弱化MapReduce 几乎被砍光“now largely obsolete”Ch11 整章重写Tolkien 风格地图作者自嘲式删除重写Ch10一致性与共识“几乎完全重写”——ID 生成器、逻辑时钟、共识等价问题这些章节都更系统Ch11批处理重写结构章节编号变了总篇幅 60 页Chris RiccominiApache Samza、SlateDB 作者加入合著没变锚点命题没变trade-offs 仍是核心六个内容枢纽的骨架没变全书叙事节奏没变一句话总结二版是把 2017 的精神骨架重新校准到 AI 工作负载和云原生地形上。最终检验读完这本书 装上这 6 个枢纽后你应该能在不看书的情况下向一个完全外行的朋友讲清楚数据系统为什么没有最优解OLTP 和 OLAP 为什么不能用一套东西做复制和分片解决的是什么不同问题为什么故障是常态对分布式系统这么关键一致性为什么是连续谱共识算法解决什么为什么真实大系统都是真相源 派生数据的组合讲不清楚任何一条 这条枢纽还没装稳回到对应章节重读。