🏗️ 系统设计综合 / System Design Synthesis — Day 111

分布式一致性协议全景对比

Distributed Consensus: Raft vs ZAB vs Paxos — When to Pick What

你已经学了 Raft (etcd)、ZooKeeper (ZAB)、以及多个依赖一致性的系统。今天来综合对比。

You've studied Raft (etcd), ZooKeeper (ZAB), and systems built on them. Today: a synthesis.

问题的本质 / The Core Problem

多节点如何就一个值达成一致，即使有节点宕机？

How do multiple nodes agree on a single value even when some crash?

所有共识算法都解决这个问题，但设计权衡各不相同。

All consensus algorithms solve this — with very different tradeoffs.

三协议对比 / Protocol Comparison

                Raft             ZAB (ZooKeeper)    Paxos
Leader?         Strong leader    Primary            Varies
Reads on        Leader only      Any follower       Any
  followers?    (linearizable)   (may be stale)     
Writes          Leader only      Primary only       Leader only
Use case        etcd, Consul     ZooKeeper          Spanner, Chubby
Complexity      Simpler ✅       Moderate           Very complex ❌

关键洞察 / Key Insights

Raft vs ZAB 最大区别：

• Raft: follower 不直接服务读取 → 强一致性，每次读都走 leader
• ZAB: follower 可服务读取，但可能读到旧数据（eventual reads）→ 高吞吐

何时选哪个？

你学过的系统用了什么共识？ / Systems You've Studied

别踩这个坑 / Common Pitfalls

❌ 把 etcd 当数据库用 → etcd 只存小 key-value 元数据，建议总数据 < 8 GB

❌ ZooKeeper 节点数设偶数 → 必须奇数（需要 majority quorum = N/2+1）

❌ 忽略 leader 切换窗口的 stale read → 用 linearizable reads 或 watch 机制解决

❌ 把共识协议当成性能优化 → 共识本质是牺牲性能换安全性

📚 参考 / References

• https://raft.github.io/
• https://zookeeper.apache.org/doc/current/zookeeperInternals.html
• https://www.cs.cornell.edu/courses/cs6452/2012sp/papers/paxos-simple-web.pdf

🧒 ELI5

想象班级选班长：Raft 要求每次投票全班 >50% 同意才算数（严格但慢）；ZAB 让班长先宣布决定然后大家记下来（快但可能同学还没更新）；Paxos 是数学最严格的版本，但最难理解，Google 才用得起。

💻 算法 / Algorithms — Day 87: #207 Course Schedule (Medium) — Graphs

🧩 图遍历模式 (8/13) — building on the template from Day 101 (Number of Islands)

今天是图遍历第 8 题，这是一个拓扑排序的经典应用。

Today is Graph block problem 8/13 — classic topological sort application.

问题 / Problem

🔗 LeetCode #207 🟡 Medium

📹 NeetCode Solution

给你 n 门课程，prerequisites[i] = [a, b] 表示学 a 前必须先学 b。问能否完成所有课程？

Given n courses and prerequisites[i] = [a, b] meaning you must take b before a. Can you finish all courses?

现实类比 / Real-World Analogy

想象你在设计一个 CI/CD pipeline：

Imagine designing a CI/CD pipeline:

• deploy 依赖 test，test 依赖 build
• 如果 build 又依赖 deploy → 循环依赖！pipeline 无法执行
• 同理，课程的循环依赖（课程 A 需要 B，B 需要 A）= 无法完成

本质：检测有向图中是否有环 / Detect cycle in directed graph

这道题如何套用模板 / Mapping to Pattern

标准 BFS 模板处理的是"找到什么"，这道题用 BFS + 入度（Kahn's Algorithm）：

Python 解法 / Solution

from collections import deque, defaultdict

def canFinish(numCourses: int, prerequisites: list[list[int]]) -> bool:
    # Build adjacency list + in-degree count
    graph = defaultdict(list)
    in_degree = [0] * numCourses
    
    for course, prereq in prerequisites:
        graph[prereq].append(course)  # prereq → course
        in_degree[course] += 1
    
    # Start with all courses that have no prerequisites
    queue = deque([i for i in range(numCourses) if in_degree[i] == 0])
    completed = 0
    
    while queue:
        node = queue.popleft()
        completed += 1                  # "取完"这门课
        
        for neighbor in graph[node]:
            in_degree[neighbor] -= 1   # 先决条件满足，入度 -1
            if in_degree[neighbor] == 0:
                queue.append(neighbor)
    
    return completed == numCourses      # 全部完成 = 无环

执行轨迹 / Trace (3 courses: [[1,0],[2,1]]):

复杂度 / Complexity: Time O(V+E), Space O(V+E)

举一反三 / Connect to Pattern Block

关键区别：

• 无向图 BFS → 用 visited 防重复
• 有向图拓扑 → 用 in_degree 决定入队顺序

📝 Quiz

{"question":"Course Schedule 中，如果最终 completed < numCourses，说明什么？","options":["所有课程都可以完成","图中存在环（循环依赖）","图的边数不够","起始节点选错了"],"correct_index":1}

📚 References

• https://leetcode.com/problems/course-schedule/
• https://neetcode.io/problems/course-schedule
• https://cp-algorithms.com/graph/topological-sort.html

🧒 ELI5

像玩积木：先找没有放在其他积木上面的（入度 0），把它拿走，再找下一个自由的。如果最后还有积木拿不到（因为相互压着），就说明有循环，游戏无法完成。

🗣️ 软技能综合 / Soft Skills Synthesis — Day 111

场景：你的团队刚完成一次重大架构迁移，但上线后发现性能比预期差 30%。CEO 问你怎么回事。

Scenario: Your team just completed a major architecture migration, but post-launch performance is 30% worse than expected. The CEO asks what happened.

为什么这个场景难 / Why This Is Hard

这不是普通的"tell me about a failure"——这需要你同时展示：

This isn't a standard "tell me about a failure" — you need to demonstrate:

1. 技术判断力 (technical judgment)
2. 透明度 + 不甩锅 (transparency without blame-shifting)
3. 向上沟通的能力 (executive communication under pressure)
4. 从数据出发的问题定位 (data-driven diagnosis)

STAR 分解 / STAR Framework

Situation (情境)

我们迁移了核心订单服务从单体到微服务架构，上线后 P99 延迟从 200ms 升到 320ms。

Task (任务)

需要立刻向 CEO 解释，同时启动诊断并给出恢复计划。

Action (行动)

1. 先承认，不辩解： "我们发现了一个预期外的性能问题，这是我们的责任。"

2. 提供数据，不猜测： "我们看到的具体指标是...原因初步定位为网络跳数增加和 serialization overhead。"

3. 给出时间表： "48小时内我们会有根因分析，72小时内会有修复方案。"

4. 回溯决策链： 复盘我们的 load testing 在哪个阶段漏了这个场景

Result (结果)

3天内通过连接池复用和 gRPC 替换 REST 将延迟降至 190ms，比迁移前还快 5%。

❌ 别这样说 / What NOT to Say

• ❌ "这是因为 DevOps 没有配置好 k8s 参数" → 甩锅
• ❌ "当时我们时间不够，没法做更好的测试" → 找借口
• ❌ "这个性能问题不是很严重" → 淡化问题

✅ 这样更好 / What Works

• ✅ 用具体数字说话："P99 从 200ms 涨到 320ms，QPS 高峰期影响约 8% 的用户"
• ✅ 区分"已知/已做"和"漏掉了什么"："我们做了单服务压测，但漏了跨服务串联场景"
• ✅ 展示后续改进："我们在 post-mortem 中新增了跨服务集成压测环节"

Staff+ 视角 / Senior/Staff Level Tips

向上沟通的艺术：

• CEO 不需要技术细节，需要：影响面 + 恢复时间 + 根因 + 你是否掌控了局面
• 永远先给结论，再给细节（Pyramid Principle）
• 承认不确定性，但承诺什么时候会有更多信息

技术上的教训：

• 微服务迁移必须做 chaos engineering 和 end-to-end load test，不只是单元/单服务压测
• 建立迁移 checklist：network hops、serialization format、connection pooling

Key Takeaways

1. 危机时刻：先控制局面，给时间表，不找借口
2. 数据说话：永远有具体指标，不说"有点慢"
3. 后续提升比当时完美更重要：展示系统性改进，不是补丁式修复

📚 References

• https://sre.google/sre-book/postmortem-culture/
• https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/

🧒 ELI5

就像你打破了妈妈的花瓶：好的做法是马上说"我打破了，是我不小心，我来扫地，下次我会更注意"，而不是说"是风吹倒的"或者"花瓶本来就很脆"。

🤖 AI 新闻 / AI News — Day 111 (August 10, 2026)

本周 AI 大事 / This Week in AI

1. 🧮 OpenAI Astra 以 $2,000 解出 10 道未解数学难题

OpenAI 的 Astra 模型据报道以极低算力成本（仅约 $2,000）成功解决了 10 道此前未被解决的数学与计算机科学问题，并在 GitHub 上发布了完整的可验证证明。

OpenAI's Astra model reportedly solved ten previously unsolved mathematics and computer science problems at a remarkably low compute cost (~$2,000), publishing fully verified proofs on GitHub.

💡 为什么重要： 这是 AI 从"辅助工具"转向"自主科研主体"的关键信号——不只是加速人类研究，而是独立提出并验证新知识。

📎 来源：https://medium.com/@davidakpovi/ai-news-week-of-august-3-9-2026-8dfa677ffca3

2. 🇪🇺 EU AI Act 正式执法：透明度新规生效

从 8 月 2 日起，欧盟 AI Office 开始正式执法 AI Act，新规包括：

• AI 系统必须向用户声明自己是 AI
• Deepfake 和 AI 生成内容必须打标签
• 通用 AI（GPAI）模型（如 GPT-5、Gemini）受到直接监管

Starting August 2, the EU AI Office began enforcing the AI Act: AI systems must identify themselves, deepfakes must be labeled, and GPAI models face direct enforcement.

💡 对开发者的影响： 如果你的产品在欧洲运营，你的 AI chatbot、图像生成功能都需要合规改造。

📎 来源：https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august

3. 🦠 AI 设计的噬菌体 — 突破 + 担忧并存

科学家首次创造了完全由 AI 设计的病毒（噬菌体），专门针对抗生素无效的细菌感染。

But: 安全专家警告这也打开了 AI 辅助生物武器的大门，治理框架明显滞后。

Scientists created the first AI-designed viruses (bacteriophages) to treat persistent infections resistant to natural phages. But biosecurity experts warn governance is lagging dangerously behind the capability.

💡 双刃剑： AI 能力越来越强，但监管框架还在追赶。AI 安全不只是模型对齐问题，也是物理世界的安全问题。

📎 来源：https://www.theguardian.com/science/2026/aug/06/safety-fears-as-scientists-make-first-viruses-designed-by-ai

📊 数字说话 / By the Numbers

• ChatGPT 活跃用户据报道已超 10 亿
• Gartner 预测 2026 年底 40% 的企业应用将内嵌 AI Agent
• Stanford 2026 AI Index：生成式 AI 在 ChatGPT 发布后 3 年内实现了 53% 的人口级采用率

🧒 ELI5

AI 这周：一个 AI 解了连数学家都解不开的题（很厉害）；欧洲说"AI 要自报家门"（新规定）；科学家用 AI 设计了能杀菌的病毒（有点让人担心）。