忍者算法的博客

没有完美的系统，只有权衡与组合分布式、事务、流处理等都是从不同角度应对现实复杂性的解法核心维度本书贡献可靠性冗余、复制、容错机制可扩展性分区、分布式架构、无共享设计可维护性模块化系统、幂等、可重放逻辑一致性保障事务、隔离级别、MVCC、共识算法数据流转机制批处理、流处理、ETL、窗口机制未来系统趋势流批融合、HTAP、事件驱动。

Martin 开篇给出定义：流处理 =处理不断到来的数据事件（event stream），并实时更新结果持续运行的程序（不关心“处理完没”）以事件为单位驱动的（而不是一堆文件）通常输出状态变化或中间结果流处理是对实时性要求更高系统的“自然进化”“Exactly-once” 是终极目标，但也最难实现时间不再是绝对的，而是相对的、混乱的Flink 是当前功能最全面的流处理平台Kafka + Flink 构成现代数据平台中非常主流的流处理架构下一章（第12章）是全书最后一章，

收集数据 → 处理转换 → 输出结果通常用于大数据量、非实时的分析任务，比如：日志分析数据仓库构建特征提取 & 建模预处理报表生成批处理不是过时技术，而是大数据系统的主力MapReduce 是批处理设计的里程碑，但 Spark 提升了开发效率与性能良好的批处理系统必须是可重放、幂等、模块化的批处理是构建数据仓库、特征平台、风控系统、报表平台等的基石下一章是第11章：流处理系统（Stream Processing）

一致性有强有弱，线性一致性是最强但代价最大共识是实现强一致性的前提分布式共识本质上是在“网络不可信”的情况下达成确定的、不可撤销的决议Raft 是工程界的共识首选协议，理解它就能看懂 ZooKeeper、Etcd 等系统“共识不是数据库的功能，而是整个系统的基础结构。下一章进入批处理（第10章），我们从分布式系统的底层一致性问题转向大数据的处理模型：MapReduce、Spark、ETL 架构等等，偏向实际应用与数据流动。

当你的系统跨多台机器、多进程，互相协作完成任务时，它就是一个分布式系统。分布式系统的本质，是在一个你永远无法完全知道全局状态的环境中，做出合理决策。CAP、时钟、分区、消息不可靠，这些不是 bug，而是自然法则。接下来是第9章：一致性与共识（Consistency and Consensus），是分布式数据库、Raft、ZooKeeper、区块链等系统的理论基础。

一个事务就是一组操作的组合，这些操作要么全部成功，要么全部失败，系统状态不会处于“中间状态”。ACID事务是构建“正确系统”的基石但在分布式环境中，完美事务 ≠ 高可用性所以实践中需要权衡：局部事务（本地原子性）最终一致性（容忍短暂不一致）幂等性 + 补偿机制Martin 的经典语录：“一致性是系统的可预测性，而事务是达成一致性的强大工具。下一章《第8章：分布式系统的挑战》会深入讨论现实中的网络分区、时钟漂移、CAP 原则等，这些是构建真实可用系统绕不开的“真相”。

将深度解析 ACID 特性、隔离级别、多版本并发控制（MVCC）、分布式事务的挑战等，是理解现代数据库和分布式系统不可跳过的一章。分区系统的难点不在“怎么分”，而在**“之后的一切操作”**如何适配。：一致性哈希（Consistent Hashing）尽量在设计初期就考虑好分区策略，避免后期大手术。由一个路由层记录每个 key 属于哪个分区。

维度单主多主无主写入点一个多个任意节点冲突风险无高高实现复杂度低中高一致性强（同步时）低低，最终一致性用例Martin 的核心观点是：复制是高可用的基础，但必须明确你要哪种一致性、能接受多少冲突、系统是否能“自动和解”。下章是《第6章：分区（Sharding）》，会讲如何拆分大表/大集群为多个子集，是分布式数据库/消息系统/存储系统设计的核心之一。

演化是数据系统的生命力Martin 说得很狠的一句话是：“不是支持演化的数据系统，都只能活在短命的原型阶段。下章是《第5章：复制》，会深入讲主从复制、多主复制、复制延迟、冲突解决等问题，内容开始涉及分布式的核心机制了。

结构类型优点缺点适用场景B-Tree查询快、支持范围查找写入有磁盘随机 I/O关系数据库、分页、事务LSM Tree写快、顺序写查询慢，复杂合并写多读少系统、日志型系统行式存储一次取全行快聚合查询慢OLTP、用户系统列式存储聚合快查询整行慢OLAP、报表、数据仓库Martin 的核心观点：“没有万能的数据结构，只有权衡取舍。你需要根据“读多还是写多”、“随机访问还是顺序处理”、“是数据更新还是追加写入”来选择底层结构。

关系模型（Relational Model）起源：1970年，E.F. Codd 提出，SQL就是它的查询语言。特点：表格形式（行-列）强类型、模式严格（schema）支持 JOIN、事务（ACID）优点抽象能力强（范式、约束）有丰富的查询语言（SQL）工具和社区成熟缺点模式变更困难（需要迁移）对复杂嵌套结构支持差（比如文章下的评论、用户信息）数据模型 ≠ 存储格式，而是系统的结构化思维选择模型是权衡：结构灵活性 vs 查询复杂性声明式查询语言是生产力工具。

系统的瓶颈在数据，比如读写速度、存储量、并发访问。存、取、传、处理数据。典型例子：数据库、搜索引擎、电商网站、社交平台、广告系统、日志平台等。Martin 想传达的不是某个技术技巧，而是系统设计要从这三大目标反推实现手段，而不是被技术细节牵着走。