算法分析与设计

Appearance

9.9 综合练习 ​

本章综合应用：分布式方案设计、审查LLM方案、Agent设计

练习设计理念 ​

知识卡片：分布式算法核心概念 ​

📌 核心概念速查表 ​

概念定义关键要点
通信复杂度节点间交换的信息量通信成本往往比计算成本更重要
同步轮数通信轮数轮数影响延迟
预聚合本地计算后传输小结果指数级减少通信
共识问题多节点达成一致Paxos、Raft
一致性模型读写顺序承诺强一致→最终一致
分片策略数据分配到节点哈希/范围/一致性哈希
热点负载不均的节点分裂/复制/盐化

📌 设计原则速记 ​

分布式设计四原则：
1. 数据不动，代码移动 → 减少传输
2. 预聚合优先 → 本地计算优先
3. 避免中心瓶颈 → 负载均衡
4. 容忍异步 → 最终一致性

📌 LLM审查清单速查 ​

审查LLM分布式方案时必问：
□ 通信量是多少？是否可预聚合？
□ 是否有中心瓶颈？
□ 节点失败如何处理？
□ 是否有热点风险？
□ 一致性级别是否合理？

📌 常见错误速查 ​

LLM常见错误正确方案
"传所有数据到中心"预聚合后传输
"用精确哈希表存储"用摘要结构
"忽略热点风险"监控热点，设计处理机制
"忽略容错"设计重试、幂等机制

📌 分布式 vs 单机对比 ​

维度单机分布式
成本关注计算时间通信量、同步轮数
数据存储内存分片到多节点
容错无需考虑节点失败必须处理
一致性天然一致需要共识机制
热点无需要负载均衡

本章练习采用三层结构：

  • 层次一：基础理解 - 掌握核心概念
  • 层次二：方案设计 - 综合应用知识
  • 层次三：LLM协同与Agent设计 - 人机协作能力

层次一：基础理解（3题） ​

1. 计算MapReduce的通信量 ​

场景：统计1亿篇文章的词频，文章分布在100台机器。每篇文章平均1000词，词汇表共50万词。

方案A：传所有文章到中心机器统计

  • 通信量 = ?
  • 时间（假设1Gbps带宽）= ?

方案B：MapReduce

  • Map输出：每篇文章的(word, 1)列表
  • 使用Combiner本地预聚合
  • Shuffle传输量 = ?

要求：计算两种方案的通信量，对比分析。

参考答案要点：

方案A：
- 通信量 = 1亿篇 × 1000词 × 平均词长(5字节) ≈ 500TB
- 时间 = 500TB / 1Gbps ≈ 46天

方案B：
- Map输出：1亿篇 × 1000条(word,1) × 约20字节 ≈ 2TB
- Combiner后：50万词 × 8字节(count) × 100台 ≈ 400MB
- Shuffle传输：约400MB（假设均匀分布）
- 时间 = 400MB / 1Gbps ≈ 3秒

结论：方案B通信量减少99.999%，时间从46天降到秒级

2. 识别分片热点 ​

场景：社交网络系统，用户数据用哈希分片。

用户分布：100万用户，均匀分片到100台机器
访问分布：某名人有100万粉丝，平均每分钟1万次访问
哈希函数：user_id % 100

要求：

  1. 名人节点在哪个shard？（假设名人user_id = 12345）
  2. 该shard的访问频率是多少？
  3. 如果单shard最大承受1000次/秒，是否会产生热点？
  4. 设计解决方案。

参考答案要点：

1. 名人节点位置：
   12345 % 100 = 45 → 机器45

2. 访问频率：
   每分钟1万次访问 → 每秒约167次
   但这只是一台机器的访问，假设均匀分布...
   
   实际上：名人的粉丝访问时，会读取名人数据
   名人数据在机器45，所以机器45承受所有名人相关的读请求
   假设80%的粉丝访问频率，每秒约133次

3. 热点判断：
   机器45承受：名人访问(133/秒) + 其他用户访问
   如果其他用户也有热点，可能超过1000次/秒
   
4. 解决方案：
   - 热点分裂：将名人数据复制到多台机器
   - 读写分离：读请求分发到副本
   - 缓存层：在缓存中存储热点数据

3. 选择一致性级别 ​

场景：电商系统，分析以下操作的一致性需求。

操作推荐一致性理由
库存扣减??
订单创建??
订单查询??
统计面板??
用户评价??

要求：分析每个操作的业务语义，选择合适的一致性级别。

参考答案要点：

操作推荐一致性理由
库存扣减强一致/顺序一致防止超卖，需要原子性
订单创建强一致订单不能丢失或重复
订单查询最终一致用户可接受短暂延迟
统计面板最终一致统计数据可接受延迟
用户评价因果一致回复必须在原评价后显示

层次二：方案设计（3题） ​

4. MapReduce方案设计 ​

场景：分析Web服务器日志，统计每小时每个错误类型的数量。

日志格式：

[2024-01-15 10:23:45] ERROR Database connection failed
[2024-01-15 10:24:01] WARN Timeout exceeded
[2024-01-15 10:25:30] ERROR Authentication failed

要求：

  1. 设计Map函数（输入日志行，输出什么？）
  2. 设计Reduce函数（输入是什么，输出什么？）
  3. 设计键（Key）应该是什么？为什么？
  4. 分析Shuffle成本
  5. 是否需要Combiner？如果需要，怎么设计？

参考答案要点：

python
# 1. Map函数
def mapper(log_line):
    """提取(小时, 错误类型)作为键"""
    timestamp = parse_timestamp(log_line)
    hour = timestamp.hour
    error_type = parse_error_type(log_line)
    return ((hour, error_type), 1)

# 2. Reduce函数
def reducer(key, counts):
    """汇总每个(小时, 错误类型)的出现次数"""
    hour, error_type = key
    return (hour, error_type, sum(counts))

# 3. 键设计
# 键 = (hour, error_type)
# 精确到需要聚合的维度
# 避免过度细分（如用时间戳）导致Reduce数过多

# 4. Shuffle成本
# Map输出：日志行数 × 约20字节
# 假设1亿条日志 → 约2GB

# 5. Combiner
def combiner(key, counts):
    """本地预聚合"""
    return (key, sum(counts))
# 效果：每个Map节点只发每小时×错误类型条记录
# 假设24小时 × 10种错误类型 = 240条/节点
# 100节点 → Shuffle传输约24KB

5. 分片策略设计 ​

场景：社交网络关系图存储，100万用户，每用户平均100朋友。

要求：

  1. 选择分片策略（哈希/范围/图分片），并说明理由
  2. 分析跨节点边比例
  3. 分析热点风险
  4. 设计热点处理机制

参考答案要点：

1. 分片策略选择：
   推荐：图分片（点切割）
   理由：
   - 社交网络存在高度节点（名人）
   - 点切割可将高度节点分散存储
   - 避免单节点热点

2. 跨节点边比例：
   哈希分片：约90%边跨节点（100台机器）
   图分片（METIS）：约10-20%边跨节点
   点切割：节点可能跨分区，但边不跨分区

3. 热点风险：
   哈希分片：
   - 名人节点在某台机器 → 读热点
   - 某社区紧密连接 → 该机器负载高
   图分片：
   - 社区内聚性好
   - 高度节点分散存储

4. 热点处理：
   - 监控：记录每节点访问频率
   - 识别：频率超过阈值 × 平均 → 热点
   - 分裂：热点节点复制到多台机器
   - 路由：读请求分发到副本

6. 一致性方案选择 ​

场景：设计分布式课程报名系统。

需求：

  • 每门课程有名额限制
  • 学生可以同时抢多个课程
  • 需要防止超额报名
  • 需要防止重复报名

要求：

  1. 分析每个操作的一致性需求
  2. 设计一致性方案
  3. 分析性能与正确性的权衡
  4. 设计容错机制

参考答案要点：

1. 一致性需求分析：
   - 名额检查：强一致（需要实时准确）
   - 名额扣减：强一致（原子操作）
   - 报名记录：强一致（不能丢失）
   - 报名查询：最终一致（可接受延迟）

2. 一致性方案：
   方案A：分布式锁
   - 每门课程一个锁
   - 先获取锁，再检查名额，最后扣减
   - 问题：锁成为瓶颈

   方案B：乐观锁 + 版本号
   - 读取时记录版本号
   - 写入时检查版本号
   - 版本号不匹配则重试
   - 优点：无锁，高性能
   - 缺点：高并发时重试多

   方案C：预扣减 + 补偿
   - 预扣减名额，设置超时
   - 报名成功则确认
   - 超时未确认则回滚
   - 优点：快速响应
   - 缺点：实现复杂

3. 性能与正确性权衡：
   - 强一致 → 性能较低，正确性高
   - 最终一致 → 性能高，可能短暂超额
   - 推荐：名额扣减强一致，查询最终一致

4. 容错机制：
   - 重试：网络失败自动重试
   - 幂等：报名ID作为幂等键
   - 补偿：超时自动回滚名额

层次三：LLM协同与Agent设计（7题） ​

7. 审查LLM分布式方案 ​

任务：让LLM设计"分布式日志分析系统"，审查其方案。

步骤：

  1. 用LLM生成方案（记录prompt和输出）
  2. 用审查框架审查：
    • 通信成本：数据传输量是多少？
    • 容错机制：节点失败怎么办？
    • 热点风险：是否有热点？
    • 一致性选择：是否合理？
  3. 识别问题并给出改进建议
  4. 让LLM根据改进建议修改方案
  5. 对比前后方案

提交：

  • 原始LLM方案
  • 审查报告
  • 改进建议
  • 改进后方案
  • 对比分析

审查框架：

markdown
## 分布式方案审查清单

### 1. 通信成本
- [ ] 是否有中心瓶颈？
- [ ] 数据传输量是多少？
- [ ] 是否有Shuffle成本分析？
- [ ] 是否有Combiner优化？

### 2. 容错机制
- [ ] 节点失败如何处理？
- [ ] 是否有重试机制？
- [ ] 是否有幂等设计？

### 3. 热点风险
- [ ] 是否有热点识别？
- [ ] 是否有热点处理方案？
- [ ] 负载是否均匀？

### 4. 一致性选择
- [ ] 一致性级别是否合理？
- [ ] 是否有并发控制？
- [ ] 是否有冲突处理？

8. 对比最佳实践 ​

任务：对比LLM解释和经典论文对"MapReduce"的解释。

步骤：

  1. 查询LLM关于MapReduce的解释
  2. 阅读Google MapReduce论文摘要
  3. 对比两者的准确性、完整性
  4. 识别LLM的误解或遗漏

提交分析报告，包含：

  • LLM解释的准确性评估
  • LLM解释的完整性评估
  • 发现的误解或遗漏
  • 改进建议

9. 人机协作设计要点 ​

任务：总结人机协作设计分布式系统的要点。

基于练习7、8的经验，总结：

  1. LLM在分布式设计中的优势
  2. LLM在分布式设计中的局限
  3. 人类审查的关键点
  4. 高效人机协作的流程

提交：人机协作设计指南（500字）

10. 设计分布式审查Agent ​

任务：设计一个Agent，自动审查分布式方案。

要求：

  1. 定义审查要点清单（转化为代码）
  2. 设计Agent决策流程
  3. 设计输出格式（审查报告）

Agent框架：

python
class DistributedReviewAgent:
    def __init__(self):
        """初始化审查规则"""
        self.review_checklist = {
            "communication": [
                "是否有中心瓶颈？",
                "数据传输量分析？",
                "Shuffle成本分析？",
                "是否有优化方案？"
            ],
            "fault_tolerance": [
                "节点失败如何处理？",
                "是否有重试机制？",
                "是否有幂等设计？"
            ],
            "hotspot": [
                "是否有热点识别？",
                "是否有热点处理？",
                "负载是否均匀？"
            ],
            "consistency": [
                "一致性级别是否合理？",
                "是否有并发控制？",
                "是否有冲突处理？"
            ]
        }
    
    def review(self, design_description):
        """
        审查分布式设计方案
        
        参数：
        - design_description: 方案描述文本
        
        返回：
        - 审查报告（包含各维度评估和建议）
        """
        report = {
            "communication": self.check_communication(design_description),
            "fault_tolerance": self.check_fault_tolerance(design_description),
            "hotspot": self.check_hotspot(design_description),
            "consistency": self.check_consistency(design_description),
            "overall_score": 0,
            "recommendations": []
        }
        # 计算总分和生成建议
        return report
    
    def check_communication(self, design):
        """审查通信成本"""
        # 实现审查逻辑
        pass
    
    def check_fault_tolerance(self, design):
        """审查容错机制"""
        # 实现审查逻辑
        pass
    
    def check_hotspot(self, design):
        """审查热点风险"""
        # 实现审查逻辑
        pass
    
    def check_consistency(self, design):
        """审查一致性选择"""
        # 实现审查逻辑
        pass

提交：Agent设计文档和伪代码实现。

11. 设计热点检测Agent ​

任务：设计一个Agent，监控系统热点并自动处理。

要求：

  1. 定义热点识别算法
  2. 定义热点处理策略
  3. 设计Agent决策流程

Agent框架：

python
class HotspotDetectionAgent:
    def __init__(self, threshold=3.0):
        """
        初始化热点检测Agent
        
        参数：
        - threshold: 热点阈值（标准差倍数）
        """
        self.threshold = threshold
        self.history = []  # 历史监控数据
    
    def monitor(self, metrics):
        """
        监控系统指标，识别热点
        
        参数：
        - metrics: 各shard的请求频率、响应时间等
        
        返回：
        - 热点列表
        """
        hotspots = []
        
        # 计算平均值和标准差
        avg = sum(m["request_rate"] for m in metrics) / len(metrics)
        std = (sum((m["request_rate"] - avg)**2 for m in metrics) / len(metrics))**0.5
        
        # 识别热点
        for m in metrics:
            if m["request_rate"] > avg + self.threshold * std:
                hotspots.append({
                    "shard": m["shard_id"],
                    "rate": m["request_rate"],
                    "severity": (m["request_rate"] - avg) / std
                })
        
        return hotspots
    
    def handle(self, hotspots):
        """
        处理热点
        
        策略：
        - 热点分裂：将热点节点复制到多台机器
        - 读写分离：读请求分发到副本
        - 动态扩容：增加热点节点副本
        """
        actions = []
        for h in hotspots:
            if h["severity"] > 5.0:
                actions.append({
                    "action": "split",
                    "shard": h["shard"],
                    "detail": "分裂到多台机器"
                })
            elif h["severity"] > 3.0:
                actions.append({
                    "action": "replicate",
                    "shard": h["shard"],
                    "detail": "增加读副本"
                })
        return actions

提交：Agent设计文档和伪代码实现。

12. 完整系统设计 ​

场景：设计分布式社交媒体系统。

需求：

  • 用户数据：100万用户
  • 关系数据：每用户平均100朋友
  • 帖子数据：每用户平均发帖100条
  • 功能：发帖、点赞、评论、关注

要求：

1. 数据分片方案：

  • 用户数据如何分片？
  • 关系数据如何分片？
  • 帖子数据如何分片？

2. 一致性策略：

  • 发帖需要什么一致性？
  • 点赞需要什么一致性？
  • 评论需要什么一致性？

3. 容错机制：

  • 节点失败如何处理？
  • 是否有重试机制？
  • 是否有幂等设计？

4. 热点处理：

  • 识别可能的热点
  • 设计热点处理机制

5. LLM审查：

  • 让LLM审查你的方案
  • 记录审查结果
  • 根据审查改进方案

提交：完整设计文档（至少2000字）。

13. 分布式算法实现 ​

7. 审查LLM分布式方案（参考答案要点） ​

审查框架应用示例：

假设LLM给出方案：
"设计分布式日志分析系统：
  1. 收集所有日志到中心服务器
  2. 在中心服务器分析
  3. 生成报告"

审查分析：

1. 通信成本：
   - [ ] 是否有中心瓶颈？ ✗ 有中心服务器
   - [ ] 数据传输量分析？ ✗ 未分析传输量
   - [ ] Shuffle成本分析？ ✗ 无Shuffle设计
   - [ ] 是否有优化方案？ ✗ 无预聚合

   估算：假设日志10TB → 传输10TB到中心 → 不可行

2. 容错机制：
   - [ ] 节点失败如何处理？ ✗ 未提及
   - [ ] 是否有重试机制？ ✗ 无
   - [ ] 是否有幂等设计？ ✗ 无

3. 热点风险：
   - [ ] 是否有热点识别？ ✗ 无
   - [ ] 是否有热点处理？ ✗ 无
   - [ ] 负载是否均匀？ ✗ 中心节点过载

4. 一致性选择：
   - [ ] 一致性级别是否合理？ - 分析场景不需要强一致
   - [ ] 是否有并发控制？ ✗ 无
   - [ ] 是否有冲突处理？ ✗ 无

改进建议：
1. 使用MapReduce架构替代中心处理
2. 添加节点失败重试机制
3. 使用Combiner减少Shuffle传输
4. 监控热点并动态扩容

改进后方案：
  - Map阶段：每台服务器本地分析日志
  - Shuffle：按分析维度分组
  - Reduce：汇总分析结果
  - 容错：节点失败自动重试

8. 对比最佳实践（参考答案要点） ​

对比分析框架：

LLM解释 vs 论文原文对比维度：

1. 核心概念准确性：
   | 概念 | LLM解释 | 论文原文 | 差异 |
   |------|---------|---------|------|
   | Map | "处理数据" | "应用函数到输入" | 精确度不足 |
   | Shuffle | "传输数据" | "按key分组传输" | 缺少分组概念 |
   | Reduce | "汇总结果" | "合并相同key的值" | 精确度不足 |

2. 完整性评估：
   | 方面 | LLM覆盖 | 论文覆盖 | 遗漏 |
   |------|---------|---------|------|
   | 容错机制 | 基本提及 | 详细描述 | 重试、备份任务 |
   | 数据本地化 | 未提及 | 强调 | 关键优化 |
   | Combiner优化 | 未提及 | 详细 | 重要优化 |

3. LLM常见误解：
   - 认为MapReduce是"批处理系统"（忽略了实时流处理应用）
   - 忽略数据本地化的重要性
   - 未强调Shuffle是瓶颈

4. 改进建议：
   - 阅读原文补充遗漏概念
   - 理解优化策略（Combiner、数据本地化）
   - 关注工程实践细节

9. 人机协作设计要点（参考答案要点） ​

人机协作设计指南：

LLM在分布式设计中的优势：
1. 快速生成方案框架
2. 解释概念原理
3. 提供多角度思路
4. 生成代码示例

LLM在分布式设计中的局限：
1. 忽略系统约束（内存、网络、延迟）
2. 缺少成本分析习惯
3. 不考虑边界情况
4. 方案"功能正确但不可用"

人类审查的关键点：
1. 通信成本：数据传输量是否合理？
2. 容错机制：节点失败如何处理？
3. 热点风险：是否存在负载不均？
4. 一致性选择：级别是否合理？

高效人机协作流程：
1. LLM生成方案 → 快速获得框架
2. 人类审查约束 → 用审查清单检查
3. 人类提出改进 → 补充遗漏分析
4. LLM细化方案 → 生成改进后代码
5. 人类验证 → 测试关键场景

核心原则：LLM生成，人类审查

10. 设计分布式审查Agent（参考答案要点） ​

Agent完整实现示例：

python
class DistributedReviewAgent:
    """分布式方案审查Agent"""
    
    def __init__(self):
        self.review_checklist = {
            "communication": [
                "是否有中心瓶颈？",
                "数据传输量分析？",
                "Shuffle成本分析？",
                "是否有优化方案？"
            ],
            "fault_tolerance": [
                "节点失败如何处理？",
                "是否有重试机制？",
                "是否有幂等设计？"
            ],
            "hotspot": [
                "是否有热点识别？",
                "是否有热点处理？",
                "负载是否均匀？"
            ],
            "consistency": [
                "一致性级别是否合理？",
                "是否有并发控制？",
                "是否有冲突处理？"
            ]
        }
    
    def review(self, design_description):
        """审查分布式方案"""
        report = {
            "communication": self._check_communication(design_description),
            "fault_tolerance": self._check_fault_tolerance(design_description),
            "hotspot": self._check_hotspot(design_description),
            "consistency": self._check_consistency(design_description),
            "overall_score": 0,
            "recommendations": []
        }
        
        # 计算总分
        total_checks = sum(len(v) for v in self.review_checklist.values())
        passed_checks = sum(r["passed"] for r in report.values())
        report["overall_score"] = passed_checks / total_checks
        
        # 生成建议
        for category, result in report.items():
            if result["passed"] < len(self.review_checklist[category]):
                report["recommendations"].append(
                    f"改进{category}: {result['missing']}"
                )
        
        return report
    
    def _check_communication(self, design):
        """检查通信成本"""
        checks = self.review_checklist["communication"]
        passed = 0
        missing = []
        
        # 检查关键词
        keywords = {
            "中心瓶颈": ["分布式", "无中心", "P2P"],
            "传输量": ["传输", "通信", "带宽"],
            "Shuffle": ["shuffle", "分组", "预聚合"],
            "优化": ["优化", "Combiner", "压缩"]
        }
        
        for check in checks:
            for key, words in keywords.items():
                if any(w in design for w in words):
                    passed += 1
                    break
            else:
                missing.append(check)
        
        return {"passed": passed, "missing": missing}
    
    def _check_fault_tolerance(self, design):
        """检查容错机制"""
        # 类似实现...
        return {"passed": 0, "missing": self.review_checklist["fault_tolerance"]}
    
    def _check_hotspot(self, design):
        """检查热点风险"""
        # 类似实现...
        return {"passed": 0, "missing": self.review_checklist["hotspot"]}
    
    def _check_consistency(self, design):
        """检查一致性选择"""
        # 类似实现...
        return {"passed": 0, "missing": self.review_checklist["consistency"]}

11. 设计热点检测Agent（参考答案要点） ​

Agent实现要点：

python
class HotspotDetectionAgent:
    """热点检测Agent"""
    
    def __init__(self, threshold=3.0):
        self.threshold = threshold
        self.history = []
    
    def monitor(self, metrics):
        """监控系统指标"""
        hotspots = []
        
        # 计算统计量
        rates = [m["request_rate"] for m in metrics]
        avg = sum(rates) / len(rates)
        std = (sum((r - avg)**2 for r in rates) / len(rates))**0.5
        
        # 检测热点
        for m in metrics:
            z_score = (m["request_rate"] - avg) / std
            if z_score > self.threshold:
                hotspots.append({
                    "shard": m["shard_id"],
                    "rate": m["request_rate"],
                    "severity": z_score,
                    "action": self._decide_action(z_score)
                })
        
        return hotspots
    
    def _decide_action(self, severity):
        """决策处理动作"""
        if severity > 5.0:
            return "split"  # 分裂到多副本
        elif severity > 3.0:
            return "replicate"  # 增加读副本
        else:
            return "monitor"  # 继续监控
    
    def handle(self, hotspots):
        """执行处理动作"""
        actions = []
        for h in hotspots:
            if h["action"] == "split":
                actions.append({
                    "type": "split",
                    "shard": h["shard"],
                    "replicas": 3
                })
            elif h["action"] == "replicate":
                actions.append({
                    "type": "replicate",
                    "shard": h["shard"],
                    "replicas": 2
                })
        return actions

场景：实现分布式PageRank算法。

数据：Web图，100万页面，平均每页10个出链。

要求：

1. 图分片策略：

  • 选择分片策略
  • 分析跨节点边比例

2. 算法设计：

  • 设计消息传递机制
  • 设计收敛判断

3. 通信分析：

  • 每轮通信量是多少？
  • 预计多少轮收敛？

4. 容错设计：

  • 节点失败如何处理？
  • 中间状态如何保存？

提交：算法设计文档和伪代码实现。

练习提交指南 ​

提交格式 ​

每个练习提交一个Markdown文件，包含：

  1. 问题陈述：练习的原始问题
  2. 解答过程：分析、计算、设计过程
  3. 最终答案：清晰的结论
  4. 反思：学到了什么？有什么疑问？

LLM协同练习特殊要求 ​

对于练习7-9，需要额外提交：

  1. Prompt记录：发给LLM的完整prompt
  2. LLM输出：LLM的完整回答
  3. 交互日志：如果有多轮交互，记录每轮对话
  4. 分析报告：对比分析，识别LLM的优缺点

参考资源 ​

经典论文 ​

  1. Dean & Ghemawat. "MapReduce: Simplified Data Processing on Large Clusters" (2008)
  2. Malewicz et al. "Pregel: A System for Large-Scale Graph Processing" (2010)
  3. Ongaro & Ousterhout. "In Search of an Understandable Consensus Algorithm (Raft)" (2014)

推荐阅读 ​

  1. Kleppmann. "Designing Data-Intensive Applications" (2017)
    • Chapter 5: Replication
    • Chapter 6: Partitioning
    • Chapter 7: Transactions

在线资源 ​

  1. Raft可视化：https://raft.github.io/
  2. 分布式系统课程：MIT 6.824

本章完成 ​

恭喜你完成了第9章的学习！

你已经掌握了：

  • 分布式成本模型（通信复杂度）
  • MapReduce设计
  • 一致性级别选择
  • 分片策略和热点处理
  • 容错机制设计
  • 分布式图计算
  • LLM时代的分布式审查能力

接下来，让我们进入第10章：流式算法。

新时代的算法课程