Executive Summary

核心观点（金字塔原理）

结论先行: 大规模分布式系统通过Master-Slave架构实现并行计算，结合分布式协调、缓存、消息队列、文件系统等核心组件，构建可扩展的高性能系统。

支撑论点:

1. 并行计算将进程分配到不同节点，通过消息传递进行通信，突破单机计算瓶颈
2. Master-Slave结构是分布式并行计算的基础模式，Master负责调度，Slave负责执行
3. 分布式系统需要协调、缓存、消息队列、文件系统、作业调度等多个核心组件协同工作

SWOT 分析

适用场景

• 分布式系统架构入门学习
• 理解大数据处理平台的设计原理
• 分布式组件选型和设计决策参考

第1章 概述

• 梅森素数 Mersenne Prime
• 串形计算，分为”指令”和”数据”两个部分，并在程序执行时”独立地申请和占有”内存空间，且所有计算均局限于该内存空间。
• 并行计算将进程相对独立的分配与不同的节点上，由各自独立的操作系统调度，享有独立的CPU和内存资源，进程间相互信息交换是通过消息传递进行的。

第2章 分布式并行计算的原理与实践

• master-slave结构
• Fourinone

第3章 分布式协调的实现

• ZooKeeper 是典型的分布式协调服务，基于 ZAB 协议（Zookeeper Atomic Broadcast）保证数据一致性，提供树形结构的命名空间（ZNode）存储协调数据。
• 分布式选举（Leader Election）通过临时顺序节点实现：各节点创建临时顺序节点，序号最小者当选 Leader；Leader 宕机后临时节点自动删除，触发重新选举。
• 分布式锁的实现分为排他锁（Exclusive Lock）和共享锁（Shared Lock）。排他锁通过创建临时节点抢占实现；共享锁通过临时顺序节点区分读写请求，读锁可并发获取，写锁需等待所有读锁释放。
• 服务发现与配置管理利用 ZooKeeper 的 Watcher 机制，服务注册时创建临时节点，消费者监听节点变化实现动态发现；配置信息存储于持久节点，修改后自动通知所有订阅者。
• 分布式协调需权衡 CAP 定理：ZooKeeper 选择 CP（一致性+分区容错性），在网络分区时牺牲可用性以保证数据一致；而 Eureka 等方案选择 AP，优先保证可用性。

第4章 分布式缓存的实现

• Cache-Aside（旁路缓存）模式是最常用的缓存策略：读请求先查缓存，未命中则读数据库并回填缓存；写请求先更新数据库，再删除（而非更新）缓存，避免并发导致的数据不一致。
• 缓存与数据库的一致性保障有两种核心策略：Write-Through（同步写穿）在写缓存的同时同步写数据库，保证强一致但延迟较高；Write-Behind（异步写回）先写缓存后异步批量写数据库，性能更优但存在数据丢失风险。
• 一致性哈希（Consistent Hashing）将哈希空间组织成环形结构，缓存节点和数据 Key 映射到环上，数据顺时针找到最近的节点存储；引入虚拟节点解决数据倾斜问题，节点增减时仅影响相邻区间的数据迁移。
• 缓存三大异常场景及应对：缓存穿透（查询不存在的数据）使用布隆过滤器或缓存空值拦截；缓存击穿（热点Key过期）通过互斥锁或永不过期策略解决；缓存雪崩（大量Key同时过期）通过随机化过期时间和多级缓存架构防范。
• Redis 与 Memcached 对比：Redis 支持丰富数据结构（String、Hash、List、Set、ZSet）、持久化（RDB/AOF）和集群模式；Memcached 仅支持简单 Key-Value，但多线程模型在纯缓存场景下吞吐量更高，适合简单的大规模缓存需求。

第5章 消息队列的实现

• 消息队列核心模型由生产者（Producer）、消费者（Consumer）、消息代理（Broker）组成。Broker 内部通过主题（Topic）进行消息分类，Topic 可划分为多个分区（Partition）实现并行消费，消费者以消费组（Consumer Group）方式订阅消息。
• 消息投递语义分为三个级别：At-Most-Once（至多一次）发送后不重试，可能丢消息但不重复；At-Least-Once（至少一次）通过重试保证不丢失但可能重复，需消费端做幂等处理；Exactly-Once（恰好一次）通过事务机制或幂等生产者实现，性能开销最大。
• 消息顺序性保障：全局有序需将所有消息写入单一分区，吞吐量受限；分区有序（Partition-Level Ordering）通过相同业务 Key 路由到同一分区，在保证业务相关消息有序的前提下实现并行处理。
• 消息持久化策略直接影响可靠性与性能：Kafka 采用顺序写磁盘日志（Append-Only Log），配合操作系统 Page Cache 实现高吞吐；通过副本机制（ISR）保证消息不丢失，支持配置刷盘策略在可靠性和性能间权衡。
• 主流消息队列对比：Kafka 高吞吐适合大数据流处理和日志收集；RabbitMQ 基于 AMQP 协议，支持灵活路由和消息确认，适合企业级复杂业务场景；RocketMQ 支持事务消息和延迟消息，在电商等高可靠场景中广泛应用。

第6章 分布式文件系统的实现

• HDFS 采用 Master-Slave 架构：NameNode（主节点）管理文件系统元数据（目录树、文件与数据块的映射关系），DataNode（从节点）负责实际数据块的存储与读写。默认每个数据块 128MB，三副本存储于不同机架的 DataNode 上以实现容灾。
• GFS（Google File System）的设计原则深刻影响了 HDFS：假设硬件故障是常态而非异常；面向大文件顺序读写优化，而非随机小文件访问；采用”一次写入多次读取”模型简化一致性设计；通过追加写入（Append）而非覆盖写入提高并发性能。
• 分布式存储中的数据一致性通过多种机制保障：写入时采用流水线复制（Pipeline Replication），客户端将数据发送至第一个副本，再依次转发至后续副本；所有副本确认写入成功后才向客户端返回成功，保证写入一致性。
• 容错机制依赖心跳检测与自动恢复：DataNode 定期向 NameNode 发送心跳（Heartbeat），汇报存活状态和数据块信息；NameNode 检测到节点失联后，自动触发数据块的重新复制（Re-Replication），将副本数恢复至设定值。NameNode 自身通过 Secondary NameNode 或 HA 方案避免单点故障。
• 海量小文件问题是 HDFS 的核心挑战：每个文件占用 NameNode 约 150 字节内存用于元数据存储，百万级小文件将严重消耗 NameNode 内存。解决方案包括 HAR（Hadoop Archive）归档合并、SequenceFile 将小文件序列化为键值对存储、以及 CombineFileInputFormat 在 MapReduce 层面合并小文件输入。

第7章 分布式作业调度平台的实现

• 作业调度需满足多种触发需求：定时触发（Timer，指定时刻执行）、周期触发（Cron 表达式，如每天凌晨执行）、依赖触发（DAG 有向无环图描述任务依赖关系，上游任务完成后自动触发下游任务）。
• 调度架构分为集中式与去中心化两种模式：集中式调度（如 XXL-Job）由单一调度中心统一分配任务，实现简单但调度中心可能成为瓶颈和单点故障；去中心化调度（如 Elastic-Job）各节点通过 ZooKeeper 协调自主领取任务，扩展性更强但实现复杂度更高。
• 故障转移（Failover）与重试机制是保障作业可靠执行的关键：执行节点宕机时，调度中心检测超时后将任务重新分配至其他可用节点；支持可配置的重试次数和重试间隔（如指数退避），并记录失败日志便于人工干预和问题排查。
• 作业分片（Sharding）实现大任务的并行执行：将一个作业按分片参数拆分为多个子任务（如按数据 ID 取模），分配到不同执行节点并行处理；节点动态扩缩容时自动重新分片，实现弹性调度和负载均衡。
• 主流调度框架对比：Quartz 是 Java 领域经典的单机调度框架，支持丰富的 Cron 表达式，但原生不支持分布式；Elastic-Job（当当开源）基于 ZooKeeper 实现去中心化调度，支持分片和弹性扩容；XXL-Job（许雪里开源）采用中心化架构，提供可视化管理界面，轻量易用，适合中小规模场景。