Content
29 Lessons • 0 Quizzes • 0 Challenges
序言
- 1
案例研究：站在巨人的肩膀上
文件系统
- 1
分布式文件系统简介
Google 文件系统（GFS）
- 1
GFS 系统设计深度解析
- 2
GFS 文件操作
- 3
GFS的详细设计
- 4
GFS中创建和读取文件操作的流程
- 5
GFS中写操作的流程
- 6
GFS中删除和快照操作的工作流程
- 7
宽松的数据一致性模型
- 8
处理GFS中的数据不一致问题
- 9
GFS的元数据一致性模型
- 10
GFS的评估
- 11
GFS测验
Google Colossus 文件系统
- 1
巨像系统设计深度解析
- 2
Colossus 的设计与评估
- 3
Colossus 测验
Facebook 的 Tectonic 文件系统
- 1
系统设计中的Tectonic深入解析
- 2
ZippyDB 设计
- 3
Tectonic 设计详解（concept）
- 4
Tectonic 中的多租户架构
- 5
租户特定优化在 Tectonic 中
- 6
Tectonic功能需求的实证评估
- 7
Tectonic 评估（concept）
- 8
Tectonic 测验（checkpoint）
数据库
- 1
分布式数据库简介
Google Bigtable
- 1
Bigtable 系统设计深度解析
- 2
Bigtable 的数据模型
- 3
Bigtable的详细设计：第一部分
- 4
Bigtable的详细设计：第二部分
- 5
Bigtable 中的设计优化
- 6
Bigtable 的评估
- 7
Bigtable 测验
Google Megastore
- 1
Megastore 系统设计概览
- 2
高可用性与可扩展性的高层次设计
- 3
Megastore 的数据模型
- 4
Megastore 中的复制
- 5
Megastore 的评估
- 6
关于大型商店的测验
Google Spanner
- 1
Spanner 深入解析：系统设计
- 2
Spanner 的详细设计
- 3
数据库桶与 Spanner 的数据模型
- 4
Spanner 中的 TrueTime API
- 5
Spanner、TrueTime 与 CAP 定理
- 6
Spanner 中的并发控制
- 7
Spanner 中的数据库操作
- 8
Spanner 的评估
- 9
Spanner 测验
键值存储
- 1
键值存储简介
多核键值存储
- 1
多核键值存储系统设计深度解析
- 2
多核系统的估算与局限性
- 3
多核系统的详细设计
- 4
多核系统的评估
- 5
多核系统测验
扩展 Memcache
- 1
Memcache 扩展深入解析
- 2
单服务器级别的 Memcache
- 3
Memcache 的集群级别
- 4
Memcache 的区域级别
- 5
跨区域Memcache层级
- 6
Memcache 的评估
- 7
Memcache 测验
SILT
- 1
SILT 系统设计深度解析
- 2
SILT的高层设计
- 3
SILT的写入友好型存储：第一部分
- 4
SILT的写入友好型存储：第二部分
- 5
SILT的写入友好型存储：第三部分
- 6
SILT 中的中间存储库
- 7
SILT 的高效内存存储：第一部分
- 8
SILT 的高效内存存储：第二部分
- 9
SILT 的高效内存存储：第三部分
- 10
SILT 中的请求流程
- 11
评估与扩展SILT的设计
- 12
SILT测验
Amazon DynamoDB
- 1
DynamoDB 系统设计深度解析
- 2
DynamoDB 的高层设计 DynamoDB 是一种完全托管的分布式 NoSQL 数据库服务，专为高可用性、高性能和可扩展性而设计。其核心架构基于 Amazon 的 Dynamo 论文思想，并结合了现代云基础设施的优势。 1. 分布式架构 DynamoDB 将数据分布在多个区域（Region）和可用区（Availability Zone）中，确保跨地域的高可用性和容错能力。每个表的数据被自动分片（Sharding），并均匀分布到多个存储节点上，以实现负载均衡和水平扩展。 2. 无模式设计 DynamoDB 采用灵活的无模式（Schema-less）数据模型，允许每条记录具有不同的属性结构。用户无需预先定义表结构，可以动态添加或删除字段，非常适合快速迭代的应用场景。 3. 主键与索引 - **主键**：每张表必须定义一个主键，包括分区键（Partition Key）和可选的排序键（Sort Key）。分区键决定数据在物理存储上的分布，排序键用于在同一分区内的数据排序。 - **全局二级索引（GSI）**：支持基于非主键字段的查询，提升灵活性。每个 GSI 可以独立配置读写容量。 - **局部二级索引（LSI）**：仅在同一个分区键下的数据上创建，适用于需要按特定条件查询同一分区数据的场景。 4. 自动扩展与性能控制 DynamoDB 支持自动扩展读写容量。用户可以选择： - **按需容量模式**：根据实际流量自动调整吞吐量，无需预置容量。 - **预留容量模式**：提前分配固定读写容量，适合工作负载稳定的场景。 5. 数据持久性与一致性 - 所有写入操作均通过多副本复制机制保证持久性，数据在多个可用区中冗余存储。 - 提供强一致读取（Strongly Consistent Read）和最终一致读取（Eventually Consistent Read）两种选项，用户可根据需求选择一致性级别。 6. 高可用与容灾 DynamoDB 在单个区域内部自动跨可用区复制数据，同时支持跨区域备份和恢复，确保灾难恢复能力。 7. 安全与访问控制 提供细粒度的访问控制，支持 IAM 策略、加密（静态和传输中）、VPC 终端节点等安全功能，保障数据安全。 8. 与 AWS 生态集成 DynamoDB 与 AWS 其他服务无缝集成，如 Lambda（事件驱动处理）、S3（对象存储）、CloudWatch（监控）、Kinesis（流处理）等，便于构建完整应用系统。 总结： DynamoDB 通过分布式架构、灵活的数据模型、自动扩展能力以及强大的可靠性机制，为大规模、高并发应用提供了高效、可靠的底层数据支持。
- 3
DynamoDB 中没有固定模式
- 4
DynamoDB 中的分区与复制
- 5
在DynamoDB中适应流量模式
- 6
DynamoDB 中的持久性和正确性
- 7
在DynamoDB中确保高可用性
- 8
DynamoDB 测验
并发管理
- 1
并发管理入门
两阶段锁（2PL）
- 1
两阶段锁（2PL）系统设计深度解析
- 2
两阶段锁（2PL）的分析与评估
- 3
2PL测验
Google Chubby 锁服务
- 1
Chubby锁机制在系统设计中的深入探讨
- 2
Chubby详细设计：第一部分
- 3
Chubby详细设计：第二部分
- 4
Chubby详细设计：第三部分
- 5
Chubby详细设计：第四部分
- 6
Chubby设计背后的原理
- 7
Chubby的评估
- 8
关于 Chubby 的测验
ZooKeeper
- 1
ZooKeeper 系统设计深度解析
- 2
ZooKeeper 的详细设计 ZooKeeper 是一个分布式协调服务，用于管理分布式系统中的配置信息、命名服务、分布式锁和集群管理。其核心目标是提供高可用性、一致性和顺序一致性。以下是 ZooKeeper 的详细设计。 1. 架构设计 ZooKeeper 采用主从架构（Leader-Follower），由一组服务器组成，称为 ZK 集群。集群中包含以下角色： - Leader：负责处理所有写请求，并将变更广播给 Follower。 - Follower：接收来自 Leader 的变更消息，并参与投票过程。 - Observer（可选）：不参与投票，仅复制数据，用于提升读性能。 所有节点共享相同的配置和状态，通过 Paxos 算法的变种（ZAB 协议）实现一致性。 2. 数据模型 ZooKeeper 使用类似文件系统的树形结构来组织数据，称为 ZNode（ZooKeeper Node）。每个 ZNode 可以存储少量数据（最大 1MB），并具有以下特性： - 持久性（Persistent）：即使客户端断开连接，数据仍保留。 - 临时性（Ephemeral）：当客户端会话结束时，节点自动删除。 - 有序性（Sequential）：在创建节点时，系统自动为其添加递增编号。 ZNode 支持版本控制，每次更新都会增加版本号，用于乐观锁机制。 3. 通信协议 ZooKeeper 使用自定义的二进制协议进行客户端与服务器之间的通信。主要特点包括： - 基于 TCP 的长连接。 - 请求/响应模式，支持异步操作。 - 消息包含类型（如 CREATE、DELETE、SET_DATA）、路径、数据和元数据。 4. 一致性协议（ZAB） ZooKeeper 使用 ZAB（ZooKeeper Atomic Broadcast）协议保证数据一致性。该协议分为两个阶段： - 选举阶段（Leader Election）：当集群启动或 Leader 失效时，通过投票选出新的 Leader。 - 消息广播阶段（Broadcasting）：Leader 将事务（Proposal）发送给 Follower，Follower 执行后返回确认（ACK），当多数节点确认后，事务被提交。 ZAB 保证了原子性、顺序性和容错能力。 5. 会话管理 客户端通过建立会话（Session）与 ZooKeeper 交互。会话具有超时机制（默认 30 秒），若客户端在超时时间内未发送心跳，则会话失效，临时节点被删除。 会话状态包括： - CONNECTING - CONNECTED - CLOSED - EXPIRED 6. Watch 机制 ZooKeeper 提供轻量级的监听机制（Watch），允许客户端注册对 ZNode 的事件监听。当节点发生变更（如数据变化、子节点增减、节点删除）时，客户端会收到通知。 Watch 机制具有以下特点： - 一次性触发：触发后即失效，需重新注册。 - 异步通知：通过事件队列传递。 - 本地缓存：客户端维护本地副本，减少网络开销。 7. 安全机制 ZooKeeper 支持基于 ACL（Access Control List）的权限控制，可以为每个 ZNode 设置访问策略，例如： - READ：允许读取数据。 - WRITE：允许修改数据。 - CREATE：允许创建子节点。 - DELETE：允许删除节点。 - ADMIN：允许设置 ACL。 此外，支持 SASL 认证和 TLS 加密传输，保障通信安全。 8. 高可用性与容错 ZooKeeper 集群通常部署奇数个节点（如 3、5、7），以确保多数派决策。只要超过半数节点可用，系统即可正常运行。 故障恢复流程： - 当 Leader 故障时，Follower 会发起新一轮选举。 - 新 Leader 启动后，同步缺失的数据至其他节点。 - 客户端自动重连到新 Leader。 9. 性能优化 - 读操作直接由本地节点处理，无需同步。 - 写操作需要多数节点确认，但可通过 Observer 分担读负载。 - 使用内存数据库（In-Memory Data Store）提高访问速度。 - 日志和快照定期持久化，保证数据可靠性。 10. 应用场景 ZooKeeper 常用于以下场景： - 分布式锁（Distributed Lock） - 配置中心（Configuration Management） - 服务发现（Service Discovery） - 集群协调（Leader Election） - 分布式队列（Distributed Queue） 总结 ZooKeeper 通过简洁的 API 和强大的一致性保障，成为构建可靠分布式系统的基石。其设计兼顾性能、可用性和易用性，适用于大规模分布式环境。
- 3
ZooKeeper 的基本概念
- 4
ZooKeeper 评估
- 5
ZooKeeper 测验
大数据处理：批处理到流处理
- 1
大数据处理系统简介
MapReduce
- 1
MapReduce 系统设计深度解析
- 2
MapReduce 的高层设计
- 3
MapReduce：详细设计
- 4
MapReduce中的设计优化：第一部分
- 5
MapReduce中的设计优化：第二部分
- 6
MapReduce：评估
- 7
总结MapReduce
- 8
MapReduce 测验
Spark
- 1
Spark 系统设计深度解析
- 2
Spark 的要求
- 3
Spark 的高层设计
- 4
Spark中的弹性分布式数据集
- 5
Spark中的并行操作
- 6
Spark中的共享变量
- 7
Spark 的详细设计
- 8
Spark 的优化改进
- 9
Spark的评估
- 10
Spark 测验
Kafka
- 1
Kafka 深入解析：系统设计
- 2
Kafka 的高层次设计
- 3
Kafka 的详细设计 Kafka 是一个分布式流处理平台，广泛用于构建实时数据管道和流应用。其核心设计目标是高吞吐量、低延迟、持久性和可扩展性。以下是 Kafka 的详细设计要点： 1. 分布式架构 Kafka 采用分布式架构，由多个 Broker（服务器节点）组成集群。每个 Broker 可以独立处理消息的存储与传输。集群中的所有 Broker 共同维护数据，实现负载均衡和故障容错。 2. 主题（Topic）与分区（Partition） - 消息按主题（Topic）组织，每个主题可以划分为多个分区（Partition）。 - 分区是 Kafka 中并行处理的基本单位，支持水平扩展。 - 每个分区是一个有序的、不可变的消息序列，通过偏移量（Offset）进行唯一标识。 - 分区可以分布在不同的 Broker 上，实现数据分片和负载均衡。 3. 消息持久化与日志结构 - Kafka 将消息以日志文件的形式持久化存储在磁盘上。 - 每个分区对应一个日志文件，日志按时间顺序追加写入，支持高效读写。 - 使用预分配磁盘空间和顺序 I/O 提升性能，避免随机写入开销。 - 支持基于时间或大小的保留策略（如保留最近 7 天的数据或最多 10GB），自动清理过期数据。 4. 生产者（Producer）与消费者（Consumer） - 生产者将消息发布到指定的主题分区。 - 生产者可选择同步或异步发送，并支持批量发送以提升吞吐量。 - 消费者从特定分区拉取消息，消费进度由消费者自身维护（通过提交偏移量）。 - 支持消费者组（Consumer Group）机制，允许多个消费者协同消费同一主题的不同分区，实现负载均衡和容错。 5. 副本机制与高可用性 - 每个分区有多个副本（Replica），包括一个 Leader 副本和多个 Follower 副本。 - 所有写操作由 Leader 处理，Follower 从 Leader 同步数据。 - 当 Leader 故障时，系统会从 Follower 中选举新的 Leader，保证服务连续性。 - 可配置副本同步策略（如 ISR - In-Sync Replicas），确保数据一致性。 6. 分区再平衡（Rebalance） - 当消费者组中成员发生变化（如新增或退出），Kafka 会触发分区再平衡过程。 - 再平衡重新分配分区给消费者，确保负载均衡。 - 为避免频繁再平衡影响性能，可通过配置控制再平衡行为。 7. 事务与精确一次语义 - Kafka 支持事务性生产者，允许跨多个分区原子性地发送消息。 - 通过事务协调器（Transaction Coordinator）管理事务状态，确保消息要么全部成功，要么全部失败。 - 结合幂等生产者和事务机制，可实现“精确一次”（Exactly-Once Semantics）语义。 8. 高吞吐与低延迟优化 - 采用零拷贝技术（Zero-Copy），减少数据在内核与用户空间之间的复制次数。 - 使用内存映射文件（Memory-Mapped Files）加速磁盘读取。 - 批量处理请求与消息，减少网络往返次数。 - 通过压缩（如 Snappy、LZ4、Zstd）减小网络传输和存储开销。 9. 监控与管理 - 提供丰富的指标（Metrics）用于监控集群健康状态、消息吞吐量、延迟、副本同步情况等。 - 支持通过命令行工具（如 kafka-topics.sh）、API 或第三方工具（如 Prometheus + Grafana）进行管理与监控。 10. 安全机制 - 支持 SSL/TLS 加密通信，保障数据传输安全。 - 提供 SASL/PLAIN、SASL/SCRAM、SASL/GSSAPI 等认证方式，防止未授权访问。 - 支持 ACL（Access Control Lists）控制资源访问权限。 总结： Kafka 的设计围绕“日志即数据”的理念展开，通过分区、副本、持久化日志和高效的 I/O 机制，实现了高吞吐、低延迟和高可用。其灵活的架构支持大规模数据流处理，适用于日志收集、事件溯源、实时分析、微服务通信等多种场景。
- 4
Kafka 的效率
- 5
Kafka中的分布式协调
- 6
Kafka 的消息传递保障机制
- 7
Kafka 的评估
- 8
Kafka 测验
共识
- 1
分布式系统中的共识简介
理解共识：两将军问题、FLP 不可能定理与拜占庭将军问题
- 1
两将军问题
- 2
FLP 不可能性
- 3
拜占庭将军问题
- 4
让AI评估你对共识基础概念的理解
两阶段提交
- 1
两阶段提交概览
- 2
两阶段提交协议的工作原理
- 3
两阶段提交协议中的失败情况
- 4
两阶段提交测验
状态机复制
- 1
状态机复制深入解析：系统设计
- 2
状态机
- 3
状态机的复制与协调
- 4
请求排序：第一部分
- 5
请求排序：第二部分
- 6
输出与客户端的容错处理
- 7
保持容错性的协议：第一部分
- 8
保持容错性的协议：第二部分
- 9
实践中的SMR：通过日志实现
- 10
状态机复制测验
Paxos
- 1
Paxos 深入解析
- 2
基本Paxos协议设计
- 3
基本Paxos算法的实际应用
- 4
Paxos设计选择背后的原理
- 5
多Paxos
- 6
Paxos 问答题
Raft
- 1
Raft 算法深入解析：系统设计
- 2
Raft 的基本原理与高层次工作流程
- 3
Raft 的领导者选举协议
- 4
Raft 日志复制协议
- 5
Raft 的安全性、容错性和可用性协议
- 6
Raft 的集群成员变更
- 7
日志压缩与Raft中的客户端交互
- 8
Raft 协议测验
尾声
- 1
结论
Certificate of Completion
Showcase your accomplishment by sharing your certificate of completion.
Course Author:Anonymous User