读 DDIA 之前，我用过 MySQL、Redis、Kafka、Elasticsearch，但这些东西在我脑子里是散的。读完之后最大的变化是，它们连起来了。B+ 树解释了 MySQL 为什么这么设计，LSM 树解释了 Kafka 和 HBase 为什么写入快，复制和分区解释了为什么分布式系统总有那些别扭的一致性问题。
Martin Kleppmann 这本书被叫分布式系统的圣经，不是夸张。它几乎不教你用具体工具，而是讲透底层原理，为什么这么设计、各方案的代价是什么。一旦建立这套底层认知框架，再遇到新技术能很快看透它的本质。这篇把这套框架最核心的部分梳理出来。
一切的起点，三个目标和一个分类
图：可靠性、可扩展性、可维护性三个目标两两之间存在权衡，全书都在讲如何在这些冲突中取舍。
数据密集型应用是和计算密集型相对的概念。它的复杂性不来自 CPU 算力，而来自数据本身，数据量大、数据之间关系复杂、数据变化速度快。DDIA 全书围绕这三类挑战展开。
所有设计决策服务于三个目标。可靠性，故障下仍然正确工作。可扩展性，负载增长时仍然表现良好。可维护性，未来好维护好演进。听起来像废话，但真正难的是，这三个目标经常互相打架，而全书就是在讲怎么在这些打架里做取舍。
数据模型决定你怎么想问题
很多人把数据模型当成单纯的存储方式，这是个误区。数据模型决定你思考问题的方式。
关系模型让你想「表和关联」，适合结构化、强事务的场景。文档模型让你想「聚合根」，适合灵活、半结构化的数据。图模型让你想「节点和边」，适合关系密集、多跳查询的场景，比如社交网络。
选错数据模型的代价很大，后续的查询、扩展、维护全都会别扭。DDIA 给的判据是，先理解数据本身的特征，再倒推选什么模型，而不是先选个流行的数据库再硬塞数据进去。
我经手过的蜂控平台查 TB 级发票就是个例子。发票字段多、结构半嵌套，还要支持各种组合查询。最后用的是 ES 做辅助索引（先根据查询条件拿到 Rowkey），再回 HBase 大宽表取明细数据。这套「索引和存储分离」的设计，拆到底就是对数据特征和访问模式的回应，不是拍脑袋。
存储引擎，B 树和 LSM 各自的最优解
图：B 树读优写一般、LSM 写优读需合并，两者源自同一磁盘物理约束，却走向截然不同的最优解。
这是 DDIA 最精彩的章节之一，因为它把两种主流存储引擎拆到了磁盘 IO 的物理层面。
B 树是原地更新，读优写一般，是大多数关系型数据库的默认。它为什么是胖的、非叶子层只存索引，因为一个磁盘块能装下越多索引项，树就越矮，IO 次数就越少。
LSM 树走追加写加合并的路线，写优读需合并，适合写密集场景。它利用了一个物理事实，顺序写远快于随机写。Kafka 把消息追加写到底、HBase 底层用 LSM，都是这个道理。代价是读放大和写放大，以及_compaction_带来的额外开销。
理解这两个引擎的本质差异，能解释为什么不同数据库选不同的存储引擎，也能帮你在选型时做出正确判断。这不是记工具用法，是理解工具背后的物理约束。
复制和分区，分布式的两根支柱
图：复制保证可靠、分区实现扩展，二者各有三种模式和代价，组合后复杂度指数级上升——这正是分布式系统的难点所在。
数据要可靠、要扩展，就得多副本、要分片。DDIA 把这两件事讲得特别透。
复制有三种模式。主从，单主写多从读，简单常用。多主，多个主节点都能写，适合多数据中心。无主，Dynamo 风格，高可用但一致性复杂。每种模式都有它的代价，复制延迟、冲突解决、一致性级别，全是需要权衡的点。
分区（分片）实现水平扩展。按范围分区容易热点，按哈希分区均匀但范围查询难，一致性哈希对扩容友好。这里有个反复被印证的规律，分区键的选择几乎决定了查询的命运。选错了，后续所有的跨片查询和重分布都是噩梦。
复制和分区往往一起用，数据先分区再在每个分区内复制，这套组合的复杂度是指数级上升的。这也是为什么分布式系统这么难，每一层都简单，叠在一起就成了地狱。
事务和一致性，权衡的集中爆发区
DDIA 把事务隔离级别讲透的那一章，是我读过最清晰的版本。
从 READ UNCOMMITTED 到 SERIALIZABLE，每一级解决一类并发问题，也付出一份性能代价。脏读、不可重复读、幻读，每一级往上都是堵住上一级的漏洞。SERIALIZABLE 完全隔离但性能差，生产里多数系统停在 REPEATABLE READ（快照隔离）这个平衡点。
一致性也是一个谱系。线性一致性最强，操作有全局顺序。因果一致性弱一点，保留因果关系。最终一致性最弱，收敛但中间可能不一致。加上 Paxos 和 Raft 这些共识算法，讲的是分布式节点怎么在不可靠的网络里达成一致。
更强的隔离级别等于更强的一致性，等于更低的性能。没有免费的午餐。落到业务，关键是搞清楚你的场景到底需要多强的一致性，为它选合适的级别。账户和支付要强一致，多数互联网场景用最终一致就够了。盲目追求最高级别，要么拖垮性能，要么根本达不到。
批处理和流处理
DDIA 最后讲数据处理的两大范式。批处理处理有界数据，MapReduce 和 Spark 那一套，适合离线分析。流处理处理无界实时数据，Flink 和 Kafka Streams 那一套，适合实时计算。从 Lambda（批流两套并行）到 Kappa（统一用流处理）的演进，反映的是业界对「一套系统搞定批和流」的追求。
这块的现实意义在于，越来越多的业务要求实时性，离线 T+1 的数据已经不够用了。理解批和流的边界和取舍，能帮你在该实时的地方实时，在该离线的地方离线。
DDIA 给我的最大收获
读完 DDIA，最大的收获不是记住了多少知识点，而是建立了一种看系统的方式。
理解原理优先于学工具。工具会换、会过时，但底层原理几十年不变。B 树和 LSM 的原理搞懂了，无论未来冒出什么新存储，你都能快速判断它的定位。
每个方案都有代价。这是全书反复强调的主线，没有银弹。看到一个「完美方案」的时候，第一反应应该是，它的代价是什么，它把复杂度藏在了哪里。
数据、复制、分区、事务是个整体。这四件事相互咬合，动一个牵动其他。把系统当一个整体看，而不是孤立地优化某一环，这是从工程师走向架构师的关键认知跃迁。
DDIA 不好读，它厚、它密、它需要你停下来想。但它是那种读一遍能用很多年的书。新技术层出不穷，能让你在喧嚣里保持清醒的，就是这套底层的、慢的、但永不过时的认知。
