🏗️ 系统设计 / System Design — Expert Synthesis Day 143

高可用三角：限流 + 缓存 + 一致性 — 综合实战

The HA Triangle: Rate Limiting + Caching + Consistency — Expert Synthesis

想象你是首席架构师 / Imagine You're the Principal Architect

你的 VP 说："我们 Black Friday 要扛 50x 流量，不能挂。"

你脑海里立刻出现三个武器：限流、缓存、一致性策略。但真正的挑战不是每个独立用，而是三者如何协同，又如何相互冲突。

Your VP says: "We can't go down on Black Friday — expect 50x traffic." Your three weapons: rate limiting, caching, and consistency. The real challenge is how they interact — and when they fight each other.

ASCII 架构图

三者协同：理想与现实 / The Ideal vs Reality

限流（Rate Limiting）→ 保护后端

• Token Bucket：允许短时 burst，适合 API
• Sliding Window：更公平，适合 per-user 限流
• ⚠️ 陷阱：分布式限流需要用 Redis Lua 脚本做原子操作，否则多实例会超限

缓存（Caching）→ 降低延迟和 DB 压力

• Cache-aside（Lazy Load）：cache miss 才查 DB，简单但首次慢
• Write-through：写 DB 同时更新缓存，一致性好但写慢
• ⚠️ 陷阱：Cache stampede — 热点 key 过期时几千请求同时穿透 → 用 mutex lock + 概率过期（jitter TTL）

一致性（Consistency）→ 正确性保证

• 读己所写（Read Your Writes）：90% 业务只需要这个，不需要全局强一致
• 最终一致（Eventual）：评论、点赞、浏览量 — 脏读无所谓
• 线性一致（Linearizable）：库存扣减、支付 — 必须用分布式锁或 CAS

真实冲突案例 / Real Conflicts

案例：商品秒杀

常见错误 / Common Mistakes

❌ 缓存 key 粒度太粗，一个 key 更新就让所有用户缓存失效（惊群）

❌ 限流在 LB 上做，而不是在每个服务实例上做，导致实例间不均衡

✅ Senior 答法：先问"这个数据的一致性要求是什么？"再决定缓存策略

关键洞察 / Key Insight

限流 = 系统的免疫系统；缓存 = 系统的记忆；一致性 = 系统的诚信。三者失衡，系统必出问题。

Rate limiting is your immune system; caching is your memory; consistency is your integrity. Imbalance any one of them and the system breaks.

📚 References

• AWS Architecture: Cache Strategies
• Cloudflare: How we handle Black Friday traffic
• Martin Fowler: Patterns of Distributed Systems — Two-Phase Locking

🧒 ELI5

超市收银台（限流）控制人流，仓库有备货（缓存）不用每次去总仓拿，账本（一致性）确保每笔买卖都记对。三件事都做好，超市才不会在促销日崩掉。

💻 算法 / Algorithms — Day 143 | #62 Unique Paths [Medium] — 2-D Dynamic Programming

🧩 新模式 / New Pattern: 二维动态规划模式 (2-D Dynamic Programming)

📍 This block: 11 problems

什么时候用 / When to use: 网格路径、字符串匹配、背包问题 — 当两个维度的子问题都影响当前结果时

识别信号 / Signals: grid paths, edit distance, longest common subsequence, knapsack, matrix, "how many ways", "min cost across grid"

通用模版 / Template:

dp = [[0] * (m+1) for _ in range(n+1)]
for i in range(1, n+1):
    for j in range(1, m+1):
        dp[i][j] = TRANSITION(dp[i-1][j], dp[i][j-1], dp[i-1][j-1])
return dp[n][m]

核心洞察 / Key Insight: 二维表格填充 — 画出表格手动填几格就能发现转移规律。先推导几个小例子，转移方程自然浮现。

题目 / Problem

🔗 LeetCode #62 - Unique Paths 🟡 Medium

📹 NeetCode Solution

真实类比 / Real-world analogy:

想象你在 Google Maps 里从左上角走到右下角，只能向右或向下走。有多少条不同路线？这不只是数学游戏 — 机器人路径规划、包裹配送路由优化都用到同样的思路。

Imagine you're in Google Maps, moving from top-left to bottom-right, only right or down. How many routes exist? This models robot path planning and delivery route optimization.

映射到模版 / Map to Template

dp[i][j] = "到达 (i,j) 的路径数"

转移：dp[i][j] = dp[i-1][j] + dp[i][j-1]
     (从上面来) + (从左边来)

Base case: dp[i][1] = 1, dp[1][j] = 1  (第一行/列只有一条路)

手动填 3×3 表格:

    c1  c2  c3
r1 [ 1,  1,  1]
r2 [ 1,  2,  3]
r3 [ 1,  3,  6]

规律立刻显现：每格 = 上面 + 左边。

Python 解法 / Solution

def uniquePaths(m: int, n: int) -> int:
    # dp[i][j] = number of paths to reach cell (i, j)
    dp = [[1] * n for _ in range(m)]
    
    # First row and first col are all 1s (only one way to reach them)
    for i in range(1, m):
        for j in range(1, n):
            dp[i][j] = dp[i-1][j] + dp[i][j-1]
    
    return dp[m-1][n-1]

# Trace: m=3, n=3
# Initial: [[1,1,1],[1,0,0],[1,0,0]]
# i=1,j=1: dp[1][1] = dp[0][1]+dp[1][0] = 1+1 = 2
# i=1,j=2: dp[1][2] = dp[0][2]+dp[1][1] = 1+2 = 3
# i=2,j=1: dp[2][1] = dp[1][1]+dp[2][0] = 2+1 = 3
# i=2,j=2: dp[2][2] = dp[1][2]+dp[2][1] = 3+3 = 6
# Output: 6 ✓

空间优化 / Space Optimization (O(n)):

def uniquePaths(m: int, n: int) -> int:
    # Only need the previous row — rolling array trick
    row = [1] * n
    for i in range(1, m):
        for j in range(1, n):
            row[j] += row[j-1]  # row[j] = old row[j] + row[j-1]
    return row[-1]

复杂度 / Complexity:

• Time: O(m × n)
• Space: O(m × n) → O(n) with rolling array

举一反三 / Connect the Pattern

本 block 11 题都是 2-D DP 的变体，转移方程会越来越复杂：

• 明天 #1143 LCS: dp[i][j] = dp[i-1][j-1]+1 if match, else max(dp[i-1][j], dp[i][j-1])
• #72 Edit Distance: 三向转移 min(dp[i-1][j]+1, dp[i][j-1]+1, dp[i-1][j-1]+replace)
• #312 Burst Balloons: 区间 DP，枚举最后一个戳破的气球

每道题的突破口：先手绘一个小 case 的 dp 表格。

📚 References

• LeetCode #62 Official
• NeetCode: Unique Paths Video
• CP-Algorithms: DP on Grids

🧒 ELI5

你在方格纸左上角，要走到右下角，只能往右或往下。每格的走法数 = 上面那格 + 左边那格的走法加起来。就像数叉路口有几条路汇进来。

🗣️ 软技能 / Soft Skills — Day 143 | Expert Synthesis

高级场景：你要重构一个核心系统，但没人给你时间

Senior Scenario: You need to refactor a critical system but nobody will give you time

为什么这道题难 / Why This Question Is Hard

这不是一道普通的"怎么处理冲突"题。它考查的是：在没有授权的情况下，如何推动技术必要性与业务优先级之间的博弈。Staff+ 工程师每周都面对这个。

This isn't a standard conflict question. It tests: how do you drive technical necessity against business priority without top-down authority? Staff+ engineers face this weekly.

场景 / Scenario

"你发现核心支付服务有严重的技术债，任何新功能都要花 3x 时间。但 PM 说 Q3 有 5 个 feature 要上，没有时间重构。你怎么做？"

STAR Framework

Situation（背景）:

在某次 sprint，我意识到我们的 checkout service 已经积累了 4 年的 spaghetti code — 没有单元测试，所有状态都耦合在一个 God Object 里，每次改动都要同时改 8 个文件。

Task（任务）:

我需要在不阻塞 Q3 roadmap 的情况下，让团队和 PM 认识到这个问题的代价，并争取到合理的重构时间。

Action（行动）:

1. 量化技术债成本：我统计了过去 3 个月的 bug rate 和开发速度 — 每个新 feature 平均多花 40% 时间，有 60% 的 hotfix 来自这个模块。
2. 翻译成业务语言：不说"代码烂"，说"这模块每季度让我们少交付 2 个 feature"。
3. 提出"嵌入式重构"方案：不要求独立 sprint，而是在每个 feature 旁边带着做 — Strangler Fig Pattern，逐步替换而不是大爆炸。
4. 找到盟友：先说服 TL 和 EM，再一起去 PM 谈。
5. 设置检查点：每两周 demo 一次进展，确保重构和 feature 同步推进。

Result（结果）:

PM 同意每个 sprint 留出 20% 的时间做"连续改进"。3 个月后，bug rate 降低了 45%，新 feature 交付速度提高了 30%。

❌ Bad Answer vs ✅ Good Answer

❌ "我告诉 PM 技术债很严重，但他们不听，所以我只能继续做 feature。"

→ 被动，无量化，无影响力。

✅ "我把技术债翻译成业务影响，提出嵌入式方案，找到共同利益点，推动渐进式改善。"

→ 主动、数据驱动、展示了跨职能影响力。

Senior/Staff Tips

• 数字是你的武器：开发速度、bug 率、oncall 频率 — 把技术问题量化成时间和金钱
• Strangler Fig > Big Bang：永远不要说"我们要停工 3 个月重写"
• 培养 PM 信任：先按时交付几个 feature，再提技术改进，你的话才有分量
• 写 ADR：把技术决定记录下来（Architecture Decision Records），未来有据可查

Key Takeaways / 核心要点

1. 量化技术债 → 业务语言
2. 嵌入式重构（Strangler Fig），不做大爆炸
3. 先找盟友，再找决策者
4. 用数据证明投资回报

📚 References

• Martin Fowler: Strangler Fig Application
• Google SRE Book: Managing Technical Debt
• Will Larson: Staff Engineer Book (Excerpt)

🧒 ELI5

就像家里下水道堵了，你不能停水一个月大修，但可以每周修一段管道。先告诉大家"不修就越来越慢"，然后边住边修，才是成年人的方法。

🤖 AI — Day 143 | News Roundup — October 27, 2026

本周 AI 大事件 / This Week in AI

🔬 Story 1: OpenAI 宣布 AI 完成三项科学重大突破

OpenAI Claims Three Major Scientific Breakthroughs

10 月 26 日，OpenAI 宣布其 AI 模型在数学、物理和计算机科学领域完成了三项重大发现。

数学 / Math: AI 证明了"局部光滑猜想"（local smoothing conjecture）在所有维度上成立，并由此解决了著名的 Kakeya 猜想和 Stein's restriction 猜想。证明通过了 Lean 形式化验证（10 月 19 日完成）。

物理 / Physics: AI 为四维时空中的某些相互作用量子场论（包括量子色动力学 QCD）给出了数学上严格的存在性证明，据报道这是理论物理数十年未解的难题。诺贝尔物理学奖得主 David Gross 正领衔一个专家组对相关成果进行独立审查。

背景： 在此之前，OpenAI 于 10 月 6 日在 GitHub 上公开了据报道 719 篇 AI 生成的数学论文，涉及黎曼猜想等未解问题的"部分进展"。

来源：OpenAI Blog | AA News

⚡ Story 2: Anthropic 发布 Claude Haiku 5.5 — 90% 降价

Anthropic Releases Claude Haiku 5.5 — Up to 90% Cost Reduction

10 月 7 日，Anthropic 发布了 Claude Haiku 5.5，这是 Claude 5.x 家族中定位高性价比的模型（同月还发布了 Opus 5.5 和 Sonnet 5.5）。

关键特点：

• 据报道 API 价格比前代 Haiku 4.5 低 75-90%
• 据报道速度提升约 30%
• 多模态支持（视觉 + 文本）
• 在 computer-use 基准测试中表现提升
• 可在 AWS、Google Cloud、Azure 上使用

工程视角：Haiku 5.5 主打"高频、低成本"场景，例如文档提取、代码注释、实时聊天回复 — 这类场景用 Opus 级别模型成本不可接受。

来源：Anthropic | MLQ.ai

🤖 Story 3: 智能体 AI 爆发 — Gartner 预测 2030 年 50% 企业 IT 用 AI Agent

Agentic AI Surge — Gartner Predicts 50% of Enterprise IT Operations Use AI Agents by 2030

Gartner 10 月发布报告，预测到 2030 年有 50% 的组织将在 IT 运营中部署能自主完成复杂任务的 AI Agent，而 2026 年这一比例接近于零。

本月值得关注的 Agent 产品：

• Microsoft Copilot：新增 "Cowork"（委派任务）、"Code"（构建应用）、"Autopilot"（后台 Agent）三大功能
• Genspark Claw：持久化 AI 助手，可跨应用完成多步骤工作流
• FTC 介入：美国联邦贸易委员会启动行业调查，审查自主 AI Agent 的潜在消费者风险

工程师需要关注什么： Agentic AI 对 API 设计提出新要求 — 幂等操作、明确的中止条件、审计日志，这些在传统 REST API 里往往是可选的，在 Agent 时代变成必须的。

来源：Gartner Press Release | Emergent.sh roundup

🧒 ELI5

这周 AI 界发生了三件大事：一台 AI 解开了数学家几十年没解出的难题（但大人们还在核实是否真的对）；另一个 AI 变得更便宜更快了（像手机套餐降价）；还有一份报告说，再过几年会有一半的大公司用 AI 来自己管理自己的电脑系统。