ddia-systems

设计数据密集型应用框架

以有原则的方法构建可靠、可扩展且易于维护的数据系统。在选择数据库、设计架构、规划分布式系统，或分析一致性与容错能力时，运用这些原则。

核心原则

数据比代码长久。 应用会被重写，框架也会更迭，但数据会保留数十年——应优先确保数据层长期正确、持久且可演进。大多数应用都是数据密集型，而非计算密集型：难点在于数据量、复杂度和变化速率；明确权衡一致性、可用性和延迟，才能打造稳健的系统，而非脆弱的系统。

评分

目标：10/10。 根据下方“快速诊断”的七项为数据架构评分：每项有证据（经过审慎权衡并形成文档）且回答“是”，得约 1.4 分；回答“否”或未知，得 0 分。

• 9-10： 每个领域的选择——数据模型、存储引擎、复制、分区、隔离、派生数据、故障处理——都经过审慎考量并形成文档，且符合实际读写及一致性需求；故障切换经过测试。
• 5-6： 已做出核心选择，但有两三项诊断未通过——例如，默认隔离级别未知、未处理热点键风险，或故障切换未经测试。
• <=3： 选择基于熟悉程度，而非需求；忽略故障模式（复制延迟、写偏斜、热点分区），意外复杂性占主导。

报告当前分数、未通过的诊断项，以及达到 10/10 所需的改进措施。

DDIA 框架

分析数据密集型系统的七个领域：

1. 数据模型与查询语言

核心概念： 数据模型会塑造你对问题的思考方式。关系型、文档型和图模型各有不同的约束，并支持不同的查询模式。

有效原因： 选择错误的数据模型，会迫使应用代码弥补表示方式不匹配的问题，从而增加意外复杂性，并随着时间推移不断累积。

关键见解：

• 关系型模型擅长处理多对多关系和临时查询；文档型模型擅长处理一对多关系和局部性；图模型擅长遍历互联数据中的递归关系
• 写入时定义架构（关系型）可及早发现错误；读取时定义架构（文档型）则更灵活
• 多语言持久化——针对不同访问模式使用不同存储——往往是正确的选择
• 对象关系阻抗失配确实会产生代价；对于自包含聚合，文档模型可以减少这种问题

代码应用：

场景	模式	示例
包含嵌套数据的用户资料	使用文档模型表示自包含聚合	在一个 MongoDB 文档中存储资料、地址和偏好设置
社交网络连接	使用图模型遍历关系	Neo4j Cypher：MATCH (a)-[:FOLLOWS*2]->(b)，查找朋友的朋友
包含联接的财务分类账	使用关系型模型确保引用完整性	PostgreSQL 中账户、交易和分录之间的外键

选择关系型、文档型或图模型，或评估读取时定义架构时，请参阅 references/data-models.md，其中提供完整的权衡矩阵和查询语言对比。

2. 存储引擎

核心概念： 存储引擎需要在读取性能和写入性能之间权衡。日志结构引擎（LSM 树）优化写入；面向页的引擎（B 树）则兼顾读取和写入。

关键要点：

• LSM 树：仅追加写入，定期压实，写入吞吐量出色，但读取放大较高
• B 树：原地更新，读取延迟可预测，但页分裂会造成写入放大
• 写入放大（一次逻辑写入导致多次物理写入）对写入周期有限的 SSD 很重要
• 面向列的存储通过压缩和向量化处理，大幅提升分析查询性能
• 内存数据库之所以快，是因为避免了编码开销，而不是因为它们不使用磁盘

代码应用：

场景	模式	示例
高写入吞吐量	LSM 树引擎	使用 Cassandra 或 RocksDB，以每秒 100K+ 次写入的速度摄取时间序列数据
混合读写 OLTP	B 树引擎	PostgreSQL B 树索引，用于事务性点查找
分析查询	面向列的存储	使用 ClickHouse 或 Parquet 扫描数十亿行中的少数列

当工作负载受读写性能限制或必须选择索引时，请参阅 references/storage-engines.md——其中包含读写路径图、压实策略、列式存储以及基于基准测试的决策流程。

3. 复制

核心概念： 复制会在多台机器上保存数据副本，以实现容错、可扩展性和降低延迟。核心挑战在于如何一致地处理变更。

原理： 每种复制策略都需要在一致性、可用性和延迟之间权衡。明确权衡取舍，可以避免那些只有在负载过高或发生故障时才会出现的细微异常。

关键要点：

• 单主复制：简单，可以实现强一致性，但主节点会成为瓶颈和单点故障
• 多主复制：提升跨数据中心的写入可用性，但冲突解决更复杂
• 无主复制：通过法定人数读写实现最高可用性，但需要谨慎处理冲突
• 复制延迟会导致读己之写、单调读和因果一致性违规
• 同步复制可保证持久性，但会增加延迟；异步复制则可能在故障切换时丢失数据
• CRDT 和最后写入者胜出以截然不同的正确性保证解决冲突

代码应用：

场景	模式	示例
读密集型 Web 应用	单主复制并配置只读副本	PostgreSQL 主节点 + 通过 pgBouncer 接入的只读副本
多区域写入	多主复制	使用具有有界陈旧性的 CockroachDB 或 Spanner
购物车可用性	无主复制并合并	使用最后写入者胜出的 DynamoDB，或在应用层合并购物车

选择单主、多主或无主复制，或排查陈旧读取时，请参阅 references/replication.md——其中包含延迟异常、法定人数计算、冲突解决和 CRDT。

4. 分区

核心概念： 分区（分片）将数据分布到多个节点上，使每个节点只处理一个子集，从而实现超越单台机器能力的水平扩展。

关键要点：

• 键范围分区支持高效的范围扫描，但连续键可能导致热点
• 哈希分区可均匀分配负载，但会破坏排序顺序，使范围查询代价高昂
• 本地二级索引需要执行分散-收集查询；全局二级索引则需要跨分区更新
• 即便使用哈希，单个键极其热门时也会出现热点（名人问题）
• 重新平衡策略：固定分区数量、动态拆分或按节点数量成比例分区

代码应用：

场景	模式	示例
时间序列数据	按时间 + 来源进行键范围分区	按 (sensor_id, date) 分区，避免当天写入热点
大规模用户数据	按用户 ID 进行哈希分区	Cassandra 对 user_id 使用一致性哈希，实现均匀分布
名人／热门键问题	添加随机后缀拆分键	在热门键后附加随机数字，将读取分散到 10 个子分区

需要进行分片或解决热门键问题时，请参阅 references/partitioning.md ——其中还介绍了重新平衡策略、请求路由，以及本地与全局二级索引之间的权衡。

5. 事务与一致性

核心概念： 事务提供安全保障（ACID），通过让你在事务范围内假设故障和并发问题不存在，简化应用代码。

原理： 如果没有事务，应用代码的每一部分都必须处理部分失败、竞态条件和并发修改。事务将这些复杂性转移到数据库中，由数据库统一正确处理。

关键要点：

• 隔离级别是一个范围：读未提交、读已提交、快照隔离、可串行化
• 大多数数据库默认使用读已提交或快照隔离——而非可串行化——因此你必须了解这些级别允许出现的异常
• 写偏斜：两个事务读取相同数据、各自作出判断并写入不同记录——行锁无法阻止这种情况
• 可串行化快照隔离（SSI）以乐观方式实现完全可串行化：不会阻塞，但冲突时会中止；两阶段锁定会阻塞，并在竞争时产生死锁
• 分布式事务（两阶段提交）代价高且脆弱；应围绕单分区操作来设计

代码应用：

场景	模式	示例
账户余额转账	可串行化事务	BEGIN; UPDATE accounts ... -100 WHERE id=1; UPDATE accounts ... +100 WHERE id=2; COMMIT;
库存预留	使用 SELECT FOR UPDATE 防止写偏斜	扣减前执行 SELECT stock FROM items WHERE id = X FOR UPDATE
跨服务操作	使用 Saga 代替分布式事务	扣款并预留库存；若失败，则执行退款补偿

设置隔离级别或排查并发错误时，请参阅 references/transactions.md ——其中还包含各隔离级别的异常对照表、写偏斜示例、2PL 与 SSI 的比较，以及分布式事务的陷阱。

6. 批处理与流处理

核心概念： 批处理以批量方式转换有界数据集；流处理则持续转换无界事件流。两者都会计算派生数据。

为什么有效： 将记录系统与派生数据（缓存、索引、物化视图）分离，可以分别优化，并在需求变化时从源数据重新构建派生数据。

关键见解：

• MapReduce 在概念上很简单，但在运维上不太方便；数据流引擎（Spark、Flink）通过任意 DAG 对其进行了泛化
• 变更数据捕获（CDC）将数据库写入转换为下游系统可使用的流
• 流表二元性：流是表的变更日志；表是流的物化状态
• 精确一次语义需要幂等操作或事务性输出
• 时间窗口（滚动、跳跃、会话）对于聚合无界流至关重要

代码应用：

场景	模式	示例
每日分析流水线	使用 Spark 进行批处理	从 S3 读取当天的事件，进行聚合，并写入数据仓库
实时欺诈检测	使用 Flink 进行流处理	Kafka 支付事件，在 5 秒滚动窗口上应用规则
同步搜索索引	变更数据捕获	Debezium 捕获 PostgreSQL WAL，Kafka 将数据馈送到 Elasticsearch
审计跟踪／事件重放	事件溯源	存储 OrderPlaced、OrderShipped 事件；通过重放重建状态

设计流水线或从记录系统派生数据时，请参阅 references/batch-stream.md——其中补充了数据流引擎、CDC 接线、窗口处理和精确一次技术。

7. 可靠性与容错

核心概念： 故障不可避免，失效并非必然。即使个别组件发生故障，可靠的系统仍能正确运行。应面向故障进行设计，而不是试图消除故障。

关键见解：

• 故障是某个组件偏离规范；失效则是整个系统停止运行——容错可以防止前者演变为后者
• 硬件故障具有随机性且彼此独立；软件故障则相关且具有系统性（更加危险）
• 人为错误是导致服务中断的首要原因——尽量减少犯错的机会，并最大限度地提升恢复能力
• 超时是基本的故障检测机制，但调优很困难：过短会造成误报，过长则会延迟恢复
• 安全性属性（坏事不会发生）必须始终成立；活性属性（好事最终会发生）则可能暂时无法满足
• 除区块链之外，通常很少需要拜占庭容错；假设系统会发生崩溃停止或崩溃恢复

代码应用：

场景	模式	示例
服务通信	超时 + 指数退避重试	retry(max=3, backoff=exponential(base=1s, max=30s)) 并添加抖动
领导者选举	共识算法（Raft/Paxos）	使用 etcd 或 ZooKeeper 实现分布式锁和领导者选举
优雅降级	熔断器	Resilience4j：在 10 秒窗口内故障率达到 50% 后断开熔断器

调优超时／重试或添加共识机制时，请参阅 references/fault-tolerance.md——其中补充了故障分类、超时调优计算、Raft/Paxos 机制，以及安全性／活性保证。

常见错误

错误	失败原因	修正方法
因数据库受欢迎而选择它	不同引擎的权衡截然不同	根据实际读写模式选择存储引擎
忽略复制延迟	导致读取陈旧数据、幻读和更新丢失	实现读己之写和单调读保证
到处使用分布式事务	2PC 速度慢且脆弱；协调者是单点故障	设计单分区操作；跨服务使用 Saga
所有场景都采用哈希分区	会失去范围查询能力	时间序列采用键范围分区；使用复合键实现数据局部性
假设隔离级别为可串行化	默认级别较弱；生产环境中会出现写偏斜	检查实际默认级别；必要时使用显式锁定
混淆批处理和流处理	选错工具会增加延迟或带来不必要的复杂性	根据数据是否有界及延迟需求选择处理模型
认为所有故障都能恢复	数据损坏和拜占庭故障需要不同的处理方式	对故障分类；针对每一类设计恢复策略

快速诊断

问题	如果否	行动
你能解释为什么选择这个数据库而非其他选项吗？	选择依据是熟悉程度，而非需求	评估数据模型的适配性、读写比例、一致性需求和扩展路径
你知道数据库的默认隔离级别吗？	存在潜在的并发错误	查看文档；测试写偏斜和幻读
你是否明确选择了复制策略？	一致性和持久性假设不明确	记录同步与异步、故障转移行为和延迟容忍度
系统能处理热点分区键吗？	一个热门实体就可能拖垮集群	为热点键添加键拆分或负载丢弃机制
你是否将权威数据源与派生数据分开？	每次变更都需要迁移所有数据	引入 CDC 或事件溯源以实现解耦
超时和重试是否经过调优，而非沿用默认值？	可能导致级联故障或不必要的延迟	测量 p99；将超时设在 p99 之上、级联故障阈值之下
你是否在生产环境条件下测试过故障转移？	恢复计划只是纸上谈兵	运行混沌实验：终止领导者、隔离网络、填满磁盘

延伸阅读

如需查看包含详细图表和研究参考资料的完整论述：

• 《Designing Data-Intensive Applications》，作者：Martin Kleppmann

关于作者

Martin Kleppmann 是剑桥大学的分布式系统研究员，曾任职于 LinkedIn 和 Rapportive，因其在 CRDT 和本地优先软件方面的工作而闻名。他的著作 Designing Data-Intensive Applications（2017）是构建数据系统的工程师不可或缺的参考书，因其让分布式系统概念变得易于理解且实用而广受赞誉。