📅 2026-08-31

Monday, August 31, 2026

4 sections ~15 min read 🌏 Bilingual 中/EN
🏗️ System Design 💻 Algorithms 🗣️ Soft Skills 🤖 AI
← 2026-08-30 📂 All Days 2026-09-01 →

🏗️ 系统设计 / System Design — Day 122 (Synthesis)

一致性模型大对比：从缓存到数据库到共识算法

Consistency Models Compared: From Cache to DB to Consensus

想象你是 Staff Engineer，需要在这三个方案中选择

你们的系统需要在多个节点间保证数据正确性。你面前有三类工具：

  • Redis Cluster（你在 Day 6 设计的缓存）
  • Cassandra（Day 9 的分布式数据库方案之一）
  • Raft 共识（Day 47 深入讲过）

它们的一致性保证根本不同。选错了，生产事故就等着你。

一致性模型速查表

强一致性 (Strong Consistency) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 读总能看到最新写 → 用户看到的数据永远正确 代价：高延迟，可用性↓ 最终一致性 (Eventual Consistency) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 写入最终会同步，但读可能暂时落后 代价：业务逻辑复杂，需要幂等处理 可调一致性 (Tunable Consistency) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 按请求指定强度：R + W > N → 强一致 代价：需要理解 quorum 数学

三个系统的对比

系统默认一致性强一致怎么实现适合场景
Redis (单主)强一致默认就是计数、Session、排行榜
Redis Cluster最终一致WAIT 命令（代价高）分布式 KV，允许短暂脏读
Cassandra最终一致QUORUM 读写写多读少，地理分布
PostgreSQL 主从最终（异步复制）synchronous_commit=on金融数据，不能丢
etcd / Raft强一致内置，无法关闭配置、分布式锁、服务发现

为什么这样设计？— CAP 定理的实际应用

Day 12 讲过 CAP：P（分区容忍）在分布式系统中是必选项。

所以真正的选择是 CP vs AP：

CP（一致性 > 可用性）：Raft/etcd, Zookeeper, PostgreSQL 同步复制 → 用于：支付、库存、选主、配置中心 AP（可用性 > 一致性）：Cassandra(ONE), Redis Cluster, DynamoDB(最终) → 用于：社交 Feed、日志收集、购物车、DNS

别踩这个坑 ⚠️

坑 1：以为 Redis 都是强一致

Redis Sentinel / Cluster 有异步复制 → 主故障时最多丢几毫秒的写入。

银行扣款不能用 Redis 做最终来源，只能做缓存层。

坑 2：Cassandra QUORUM 不等于强一致

如果你的集群是 N=3，R=2，W=2，看起来满足 R+W>N。

但如果有节点在 hinted handoff 状态，读可能绕过 quorum。

必须配合 read repair 和 nodetool repair。

坑 3：用 Raft 存大数据

Raft 的 log 需要所有节点同步 → 吞吐量被 leader 限制。

etcd 官方建议数据 < 8GB。别把它当数据库用。

实际架构：把三者组合起来

[Client] │ ├─► Redis (Cache, CP per key) ──► hit: return │ │ miss ▼ [PostgreSQL Primary] ──sync replica──► [PG Replica] (read) │ └─► [etcd] (分布式锁，防止并发超卖)

这是 Day 37 Ticketmaster 和 Day 38 Payment System 里用到的真实模式：

  • etcd 做选主和分布式锁（强一致，CP）
  • PostgreSQL 同步复制做持久化（CP）
  • Redis 做缓存加速（可接受最终一致）

📚 References

🧒 ELI5

把数据库想成黑板。强一致 = 所有人看同一块黑板；最终一致 = 每人有自己的小本子，但每隔一段时间对一次答案。选哪个取决于你是在做考试题（必须精确）还是记购物清单（差一点没关系）。

💻 算法 / Algorithms — Day 96

#332 Reconstruct Itinerary (Hard) — Advanced Graphs (4/6)

🧩 高级图算法模式 (4/6) — building on the template from Days 118–121

Block so far: Min Cost to Connect All Points (Prim's) → Network Delay Time (Dijkstra) → Cheapest Flights Within K Stops (Bellman-Ford) → 今天：Reconstruct Itinerary (Eulerian Path)

关键变化 / What's Different Today:

前三题都是"最优路径"问题，用 Dijkstra 或 Bellman-Ford。今天这题是遍历每条边恰好一次——这是欧拉路径（Eulerian Path），需要 Hierholzer 算法，不是 Dijkstra！这是 Advanced Graphs 块里最大的模式转变。

🔗 LeetCode #332 🔴 Hard

📹 NeetCode Video

现实类比 → 问题

类比： 你有一堆机票，每张都必须用上。必须从 JFK 出发，构造字母序最小的行程。机票是有向边，机场是节点。

问题： 给定 tickets = [["MUC","LHR"],["JFK","MUC"],["SFO","SJC"],["LHR","SFO"]]，返回 ["JFK","MUC","LHR","SFO","SJC"]。

关键约束：

  1. 必须用完所有机票（每条边恰好走一次）→ Eulerian Path
  2. 多解时取字母序最小 → 邻居排序

从模式模板到这题的映射

Dijkstra 模板中的 dist[] → 这里不需要（不求最短路） Dijkstra 的 heapq → 变成排序的 deque/list（按字母序弹出） "找最优" → 变成 "后序 DFS + 结果反转"

Hierholzer 算法核心：

  • DFS 深入，直到走投无路
  • 走投无路时，把当前节点加入结果尾部（post-order）
  • 最后反转结果 → 欧拉路径

Python 解法 + 逐步 Trace

from collections import defaultdict

def findItinerary(tickets):
    # Build adjacency list (sorted for lexical order)
    graph = defaultdict(list)
    for src, dst in sorted(tickets, reverse=True):  # reverse sort so we can pop() from end
        graph[src].append(dst)
    
    result = []
    
    def dfs(airport):
        while graph[airport]:
            next_dst = graph[airport].pop()  # smallest lexical (we added in reverse)
            dfs(next_dst)
        result.append(airport)  # post-order: add when no more outgoing edges
    
    dfs("JFK")
    return result[::-1]  # reverse to get correct order

# Trace: tickets = [["JFK","SFO"],["JFK","ATL"],["SFO","ATL"],["ATL","JFK"],["ATL","SFO"]]
# graph: JFK→[SFO,ATL], SFO→[ATL], ATL→[SFO,JFK]  (sorted desc, pop gives smallest)
# 
# dfs(JFK) → pop ATL → dfs(ATL)
#   dfs(ATL) → pop JFK → dfs(JFK)
#     dfs(JFK) → pop SFO → dfs(SFO)
#       dfs(SFO) → pop ATL → dfs(ATL)
#         dfs(ATL) → pop SFO → dfs(SFO)
#           dfs(SFO) → no neighbors → result.append(SFO)
#         result.append(ATL)
#       result.append(SFO)  ← wait, SFO already returned
#     result.append(JFK)
#   result.append(ATL)
# result.append(JFK)
# result (reversed) = ["JFK","ATL","JFK","SFO","ATL","SFO"] ✓

时间复杂度： O(E log E) — 排序边

空间复杂度： O(V + E)

为什么后序 + 反转？

直觉：如果你遇到"死路"（dead end），那个节点只能是路径的最后一站。后序遍历保证了死路节点先入 result，反转后它们在末尾。

有死路的图： JFK → A → B（死路） JFK → C → A 正序 DFS 先进死路 B → post-order: B, A, ... 反转后 A 在 B 前面 ✓

举一反三：与同块其他题的关系

题目核心算法关键问题
Min Cost All PointsPrim's/Kruskal最小生成树，无向
Network Delay TimeDijkstra单源最短路，有向
Cheapest Flights K StopsBellman-Ford限制步数的最短路
Reconstruct ItineraryHierholzer DFS每条边走一次
Swim in Rising Water (next)Dijkstra/Binary Search最小化最大值

Quiz

{"question":"Reconstruct Itinerary 中，为什么把节点加入 result 要用 post-order（后序）？","options":["A: 字母序小的先处理","B: 走投无路的节点必须放路径末尾，后序+反转保证正确顺序","C: DFS 天然就是后序","D: 避免重复访问节点"],"correct_index":1}

📚 References

🧒 ELI5

想象你要用完所有路线卡，每张用一次，从家出发。如果你遇到走投无路了，那个地方一定是终点。把所有"走投无路"的地方按顺序记下来，倒过来读，就是你的完整行程！

🗣️ 软技能 / Soft Skills — Day 122 (Synthesis)

场景题：你发现你们的 On-Call 文化正在把团队压垮

Scenario: You Discover Your On-Call Culture is Breaking the Team

为什么这个场景重要

Day 43 讲过 on-call 基础，Day 62 讲过事故处理。但 Staff 工程师面对的更难的问题是：系统性问题——不是某次事故，而是一整个文化在慢慢侵蚀团队。这类题测的是你能不能从执行者变成系统改造者。

场景设定

你是一位 Staff Engineer。过去三个月，团队的 on-call 每周平均被叫醒 4 次（凌晨 1-5 点），离职率上升了 30%，最近一个季度有两个高级工程师辞职，理由都是"精力耗尽"。你的 EM 知道有问题，但觉得"这就是创业公司的代价"。

面试官问： "你会怎么处理这件事？"

STAR 拆解

Situation（背景）：

系统告警频繁，但大部分是低优先级或误报（alert fatigue）。团队没有 on-call rotation 的明确 SLA，也没有事后的 postmortem 改进闭环。

Task（你的角色）：

作为 Staff Engineer，你不直接管人，但你对技术方向和系统健康负有责任。你需要在没有直接汇报关系的情况下推动变化。

Action（行动）：

  1. 先用数据说话，不讲感受

```

拉 PagerDuty 数据 → 3 个月 on-call 事件日志

分类：P0 真实事故 vs P1/P2 可以白天处理的告警

结论：73% 的告警是误报或低优先级

```

  1. 构建"关注它的商业理由"

不是"团队很累"（EM 可以无视）→ 而是"以现在的离职率，3 个月后我们没有人能 on-call"

  1. 提出具体方案，不只是投诉

- 告警分级：重新定义什么是 P0（必须立即响应）

- 告警降噪：关掉 6 个月内从未升级的告警

- 轮班 SLA：每人每季度不超过 X 次夜间叫醒

- Postmortem 闭环：每次 on-call 后必须有 action item

  1. 处理 EM 的阻力

先单独聊，给 EM 一个"赢"的方式：把这个改善作为他的 Q4 OKR。不是对抗，是合作。

Result（结果）：

6 周后，夜间告警减少 60%，工程师满意度提升，季度末没有新的离职。

❌ Bad vs ✅ Good

❌ 差的回答：

"我会和 EM 说团队很累，建议我们减少 on-call 频率。"

→ 没有数据，没有方案，被动等待。

✅ 好的回答（Staff 级别）：

"我收集了 3 个月的 PagerDuty 数据，发现 73% 的告警不需要凌晨响应。我建立了一个告警分级框架，并向 EM 展示了如果这个趋势继续下去，6 个月后团队的 bus factor 会降到 2。我们在 6 周内落地了改善，减少了 60% 的夜间告警。"

Senior / Staff 差异点

Level关注点
Senior解决眼前的事故，做好自己的 on-call
Staff发现系统性问题，推动组织层面的改进
Principal影响跨团队的工程文化，建立标准

关键 Takeaways

  1. 数据 > 感受 — "我们很累"被忽视，"离职率+30%" 不能被忽视
  2. 带着方案去，不只是问题 — Staff 级别不是投诉者，是提案者
  3. 给利益相关者一个"赢"的方式 — 让 EM 的 OKR 受益于你的改善

📚 References

🧒 ELI5

想象值夜班的保安每晚被假警报叫醒 4 次。聪明的做法不是"保安要多点休息"，而是：找出哪些警报是假的，把它们关掉。用数字证明问题，给出解法，让老板觉得这是他的好主意。

🤖 AI — Day 122 (Synthesis + News)

AI 新闻速递 / AI News Roundup — August 2026

📡 以下内容来自 2026 年 8 月网络搜索结果。
Sources: local-ai-zone.github.io | asya.ai | medium.com

📰 Story 1：模型发布速度创历史纪录

据 llmgateway.io 追踪，8 月仅前 20 天就有超过 11 个主要模型发布，整个月共追踪到 16 个新模型。包括 Qwen3.8-Max（据报道参数量达 2.4T）、Meta 的 Muse Spark 1.2、以及 Google 在 Gemini 3.6 发布后仅三周就推出的 Gemini 3.7 Flash。

对你的意义： 几个月前还是 SOTA 的模型，现在已经是中等水平。选型时不要锁死单一提供商。

📰 Story 2：AI 开始改进 AI 本身

Medium 分析 指出，AI agents 已开始自动化文献综述、实验设计、代码生成和结果评估等研究工作，形成加速循环。

这与 Day 74 讲的 AI Agents 主题直接相关：ReAct + Tool Use 已经从演示阶段进入实际 AI research pipeline。

📰 Story 3：EU AI Act 系统性风险条款开始执法

欧盟委员会于 8 月正式开始对具有"系统性风险"的通用 AI 模型执行 EU AI Act 相关义务，包括：要求提供信息、模型评估、强制缓解措施，以及重大罚款。

实际影响： 面向欧洲用户的 AI 产品需要关注合规成本。与 Day 66 的 AI in Production 主题（Guardrails）形成呼应。

📰 Story 4：开源模型追赶闭源，成本每智能单位下降约 50%

据 llm-stats.com 报道，激烈竞争导致 AI "每智能单位成本"据报道下降约 50%，Alibaba Qwen、Google Gemma、Meta Muse Glimmer 等开源/开放权重模型持续缩小与闭源模型的差距。

深度联系：本月新闻 ↔ 你已学过的概念

新闻关联 Day
Agentic AI 大爆发Day 26 (AI Agents), Day 74 (Future of AI)
开源模型崛起Day 68 (Open Source vs Closed LLMs)
EU AI Act 执法Day 48 (AI Safety & Alignment)
模型自动评估Day 52 (Evaluation)

📚 Sources

🧒 ELI5

AI 这个月像一场大爆炸：新模型像雨点一样往外冒，AI 还开始帮科学家做研究，而且欧洲开始给 AI 公司发罚单了。最有趣的是：AI 正在让自己变得更聪明，这个循环一旦转起来，就很难踩刹车。