由于AI编程工具及Vibe Coding的流行，系统设计的重要性不言而喻，本文参照s09g大佬有关系统设计的视频，做出来的对应博文，用来巩固及学习实现合理的系统设计架构

这当中还不乏一些使用Gemini来进行水平扩展的其他系统设计
嗯抚子哥也觉得其实这玩意AI也不比senior要差
还有不要担心，我命硬的很

顺便吐槽一句你们老就喜欢养边牧了，以后有条件我也想养一只

传统Website

---

📚 系统设计面试资料：Web开发基础与简单社交系统设计 (Video 1)

1. 核心主题 (Core Topic)

• 题目： Web Application Basics & Design a Simple Social Network (Timeline/Feed).
• 本质： 理解从浏览器请求到服务器响应的全过程，以及如何设计一个最基础的“发帖-关注-看帖”系统。

2. 需求分析 (Requirements Clarification)

• 功能性需求 (Functional):
  • 用户注册/登录 (Register/Login)。
  • 发布帖子 (Post content)。
  • 关注其他用户 (Follow users)。
  • 核心功能： 刷时间线 (Timeline) —— 看到自己关注的人发的帖子，按时间倒序排列。

3. 高层架构设计 (High-Level Design)

• 基础链路 (Request-Response Cycle):
  1. Browser (Client): 发起 HTTP Request (GET/POST)。
  2. Web Server: 监听端口 (通常是80)，接收请求。
  3. Router (URL Mapping): 根据 URL (如 /profile/123) 找到对应的 View Function (视图函数)。
  4. Service/Controller Layer: 处理业务逻辑 (Business Logic)。
  5. Database/ORM: 存取数据。
  6. Response: 服务器返回 HTML 文档或 JSON 数据。

4. 核心技术难点与解决方案 (Deep Dives)

4.1. 数据库设计 (Schema Design) - 重点

为了实现社交网络功能，需要设计三张表来处理实体与关系：

• User Table (用户表):
• id (Primary Key)
• username / email
• Post Table (帖子表):
• id
• content
• author_id (Foreign Key -> User.id)
• Follows Table (关注关系表) - 处理多对多关系 (Many-to-Many):
• follower_id (Foreign Key -> User.id): 谁关注了。
• followed_id (Foreign Key -> User.id): 被关注的是谁。

4.2. 时间线查询 (Timeline Query Logic)

• SQL 逻辑:
  1. 从 Follows 表中找出当前用户关注了哪些 followed_id。
  2. 从 Post 表中查找 author_id 在上述列表中的所有帖子。
  3. 排序 (Ordering): 按时间倒序 (DESC)。
  4. 分页 (Pagination): 使用 LIMIT 10 和 OFFSET，避免一次性加载过多数据。

4.3. 数据库交互层 (SQL vs ORM)

• Raw SQL: 直接在代码中拼接 SQL 语句。灵活但易错，且容易导致注入风险。
• ORM (Object Relational Mapping):
  • 在业务逻辑和数据库之间加一层抽象。
  • 操作: 使用对象操作代替 SQL (e.g., db.session.add(user))。
  • 优点: 隐藏底层细节，代码易读，方便维护。

5. 技术选型与权衡 (Trade-offs)

5.1. 表现层逻辑 (Presentation Logic): SSR vs. REST API

• 方案 A: Server-Side Rendering (模板渲染)
  • 做法: 使用 Template (如 HTML 模板)，服务器查询数据后，用真实数据替换占位符 (Placeholders)，生成完整的 HTML 返回给浏览器。
  • 缺点: 服务器端负载重；业务逻辑与表现逻辑耦合 (Frontend/Backend 混杂)；难以支持移动端 App (因为返回的是 HTML)。
• 方案 B: RESTful API (前后端分离) - 推荐
  • 做法:
    • GET /api/timeline: 返回 JSON/XML 数据 (Resource)。
    • POST /api/post: 提交数据 (需带 Authentication Token Header)。
  • 优点:
    • Decoupling: 彻底分离表现层和业务层。
    • Scalability: 同一套 API 可以同时支持 Web、iOS、Android。
    • 客户端拿到 JSON 后自行渲染页面。

6. 面试金句/总结 (Key Takeaways)

• “Separate business logic from presentation logic.” (一定要将业务逻辑和表现逻辑分离，即采用前后端分离架构。)
• “RESTful APIs are resource-oriented and allow for multi-client support (Web & Mobile).” (REST API 面向资源，能更好地支持多端应用。)
• “For social graphs, we need a junction table to handle many-to-many relationships.” (在关系型数据库中处理社交关系，需要中间表来处理多对多关系。)

ChatGPT API

---

📚 Design ChatGPT (LLM Inference Engine)

1. 核心主题 (Core Topic)

• 题目： Design ChatGPT / Design LLM Inference Service (大模型推理服务)。
• 本质： 设计一个高吞吐、低延迟的在线推理系统，重点在于如何最大限度榨干GPU资源，解决显存瓶颈和计算瓶颈。

2. 需求分析 (Requirements Clarification)

• 关键指标 (Goal Metrics):
  • Throughput (吞吐量): 单位时间内处理的Token数量，系统必须能承载高并发。
  • Latency (延迟): 在线链路实时性要求高。
    • TTFT (Time To First Token): 首字延迟（用户发出请求到看到第一个字的时间）。
    • TBT (Time Between Tokens): 字间延迟（生成流式输出的流畅度）。

3. 高层架构设计 (High-Level Design)

• 整体链路：
  1. Client: 用户发送Prompt。
  2. API Gateway: 负责限流 (Rate Limiter) 和鉴权。
  3. Session Manager: 管理会话状态，处理在线链路。
  4. Redis: 存储对话上下文 (Context/History)。
  5. DB (Write-Ahead-Log): 异步落盘对话记录，保证持久化。
  6. Message Queue: Session Manager 将上下文打包成 Task 放入 MQ。
  7. Inference Service (核心): 后端推理服务，从 MQ 取任务，调用 GPU 进行推理，将生成的 Token 流式返回。

4. 核心技术难点与解决方案 (Deep Dives)

这是面试中最核心的部分，视频详细讲解了 LLM 推理的原理及优化。

4.1. LLM 推理原理与 KV Cache (最关键的基础)

• Transformer 特性:

  • Token-by-Token: 逐个生成，预测下一个 Token。
  • Auto-regression (自回归): 每次生成的 Token 会追加到输入序列末尾，作为下一次预测的输入。

• 性能瓶颈: Self-Attention 计算中的矩阵乘法 (Q × K × V)。

  T

• KV Cache 优化:

  • 问题: 每次生成新 Token 时，旧 Token 的 K (Key) 和 V (Value) 矩阵会被重复计算。
  • 解决: 将前 N − 1 个 Token 计算好的 K 和 V 缓存在显存中，每次只计算最新 Token 的 Q, K, V，然后将新的 K, V 追加到 Cache 中。
  • 效果: 将计算复杂度从平方级降低，但代价是大量消耗显存。

4.2. 显存容量与并发计算 (The Math)

• 面试加分项：现场估算并发量 (以 A100 80GB 显卡为例)。
• 场景 1: Llama-2 7B (FP16)
  • 模型权重: 7B 参数 × 2 Bytes = 14GB。
  • KV Cache (4K Context): 约 2GB / Session。
  • 剩余显存: 80GB - 14GB = 66GB。
  • 最大并发: 66GB / 2GB ≈ 33 Sessions。
• 场景 2: Llama-3 8B (引入 GQA 优化)
  • GQA (Grouped Query Attention): 共享 KV Head，减少了存储需求。
  • KV Cache (8K Context): 优化后仅约 1GB / Session (虽然上下文变长，但通过 GQA 压缩了体积)。
  • 最大并发: (80GB - 16GB) / 1GB ≈ 64 Sessions。
  • 结论: 显存大小直接决定了系统的最大并发数。

4.3. 批处理策略 (Batching Strategies)

• Naive Batching (朴素批处理): 等一批请求全部到齐再计算，必须等最慢的请求结束。延迟高，显存利用率低。
• Continuous Batching (持续批处理 / Orca):
  • 原理: 一旦某个请求生成结束 (EOS) 释放了显存，立即从队列中取下一个任务填补空位，无需等待整批结束。
  • 优点: 消除 GPU 空闲，大幅提升吞吐。
• Chunked Prefill (分块预填充):
  • 背景: 推理分为 Prefill (一次性计算Prompt，计算密集型) 和 Decode (逐个生成，内存密集型)。
  • 问题: 一个超长的 Prefill 任务会阻塞其他正在 Decode 的任务（卡顿）。
  • 解决: 将长 Prefill 任务切分成多个 Chunk，允许在 Chunk 之间插入其他 Decode 任务。类似操作系统的时间片抢占。

4.4. 进阶架构：PD 分离 (Prefill-Decode Disaggregation)

• 架构: 将 Prefill 阶段和 Decode 阶段拆分到不同的节点/GPU 上。
• 优势:
  • Prefill 节点优化计算 (Compute-bound)。
  • Decode 节点优化显存带宽 (Memory-bound)，可使用 CUDA Graph 减少 CPU Launch Kernel 的开销。
• 代价: 需要在节点间传输 KV Cache，对网络带宽要求极高。

4.5. 显存与传输优化

• 压缩 KV Cache:
  • 量化 (Quantization): FP16 -> FP8 (H100支持) -> FP4 (B100支持)。
  • PagedAttention (vLLM): 仿照操作系统分页机制，解决显存碎片化问题。
  • 去重 (Prefix Sharing): 多个请求如果有相同的 System Prompt，共享这部分 KV Cache。
• 网络加速 (针对 PD 分离或分布式推理):
  • InfiniBand: 性能好但贵，需专用交换机。
  • RoCEv2: 基于以太网的 RDMA，性价比高，需要精细的网络调优。

4.6. 大模型并行策略 (Parallelism)

当模型太大（如 Llama 70B, DeepSeek 671B）单卡放不下时使用：

1. 张量并行 (Tensor Parallelism, TP): 将矩阵切分到多张卡计算，再聚合。适用于单机多卡，通信频繁 (All-Reduce)。
2. 专家并行 (Expert Parallelism, EP): 针对 MoE 模型 (如 DeepSeek R1)，不同 GPU 负责不同的“专家”。问题是可能存在“热点专家”导致负载不均。
3. 上下文/序列并行 (Context/Sequence Parallelism, SP): 针对超长上下文 (如 1M Tokens)，利用 Ring Attention 在多卡间分摊序列长度。

5. 技术选型与权衡 (Trade-offs)

• 显存 vs. 精度: 使用 FP8/FP4 量化可以倍增并发量和减少传输量，但会损失模型精度。
• 单机 vs. 分布式: 单机部署简单，但显存受限；分布式 (TP/PP) 能跑大模型，但引入了复杂的通信开销 (Communication Overhead)。
• Prefill/Decode 分离: 提升了资源利用率和吞吐，但引入了 KV Cache 传输的网络延迟挑战，需要权衡带宽成本。
• GQA vs MQA: GQA (Grouped Query Attention) 是性能和效果的折中；MQA (Multi-Query Attention) 共享一份 KV 速度最快，但模型表达能力下降较多。

6. 面试金句/总结 (Key Takeaways)

• “In LLM inference, memory bandwidth is the bottleneck for Decoding, while compute is the bottleneck for Prefilling.” (推理中，Decode 是显存带宽瓶颈，Prefill 是计算瓶颈。)
• “KV Cache size dictates the maximum concurrency of the system.” (KV Cache 的大小直接决定了系统的最大并发数。)
• “Continuous batching is essential for high throughput.” (持续批处理是提升吞吐量的必要手段。)
• 优化思路总结： 算不动就加卡 (Parallelism)，存不下就压缩 (Quantization/GQA)，卡顿就切分 (Chunked Prefill)，利用率低就分离 (PD Separation)。

Tiktok

---

📚 系统设计面试资料：Design a Video Sharing Platform (TikTok / YouTube) (Video 2)

1. 核心主题 (Core Topic)

• 题目： Design a Video Sharing Platform (e.g., YouTube, TikTok, Netflix).
• 本质： 设计一个能处理大规模 Blob 数据（视频文件）上传、存储、转码和全球分发的系统。核心在于 Data Flow In (上传) 和 Data Flow Out (观看)。

2. 需求分析 (Requirements Clarification)

• 功能性需求 (Functional):
  • Upload Video: 用户可以上传视频。
  • View Video: 用户可以流畅观看视频。
  • (附加功能): 推荐系统 (Feed/Recommendation)、点赞评论等（视时间而定）。
• 非功能性需求 (Non-Functional):
  • Scalability: 支持海量用户（假设 10亿日活）。
  • High Availability: 系统不能宕机。
  • Low Latency: 视频秒开，无缓冲。
  • Fault Tolerance: 在网络不稳定（移动端 WiFi/4G）的情况下依然能可靠上传和播放。
• 容量估算 (Back-of-the-envelope Calculation):
  • 假设 10亿日活，平均每人每天看100个短视频，1%用户每天上传1个视频。
  • 上传带宽: 视频源文件较大，需考虑压缩。
  • 存储: 原视频 + 转码后的多版本视频，存储需求巨大。

3. 高层架构设计 (High-Level Design)

将系统拆分为两个核心子系统：

1. Upload Service (写路径): 处理视频上传、转码、存储。
2. View Service (读路径): 处理视频拉取、CDN 分发、流媒体播放。

• 架构解耦 (Decoupling): Upload 和 View Service 独立扩展，互不影响。

4. 核心技术难点与解决方案 (Deep Dives)

4.1. 视频上传与转码流程 (The Upload Path)

• 问题: 直接上传大文件容易失败（网络不稳定），且无法直接播放（格式不兼容）。
• 解决方案:
  1. 分片上传 (Chunked Upload):
     • 将视频切分为小的 Chunks/Segments 并行上传。
     • 支持 断点续传 (Resumable Upload)：如果某个 Chunk 失败，只需重传该 Chunk。
  2. 预签名 URL (Presigned URL) - 面试常考优化:
     • Upload Service 不直接接收视频流，而是返回一个云存储（如 S3）的 Presigned URL，客户端直接将视频上传到云存储的 Raw Bucket（临时存储区）。
  3. 异步转码 (Asynchronous Processing):
     • 视频上传完成后，发送消息到 Message Queue (MQ)。
     • Worker Pool 从 MQ 领取任务，进行转码 (Transcoding)。
     • 转码 (Transcoding): 将原视频转换为不同分辨率 (360p, 720p, 1080p) 和不同格式 (H.264, VP9)，以适配不同设备和网速。
  4. 状态机 (State Machine): 在 Metadata DB 中维护视频状态：Uploading -> Processing -> Ready (或 Retry).

4.2. 视频存储 (Storage)

• Metadata DB (元数据):
  • 存储视频标题、描述、点赞数、URL 等。
  • 选型:
    • RDBMS (MySQL/Postgres): 适合处理关系（User 关注 User，Video 属于 User）。
    • NoSQL (Cassandra/DynamoDB): 适合海量读写，自动分片，扩展性好。TikTok/YouTube 这种体量通常会选 NoSQL 或 NewSQL。
• Blob Storage (视频文件):
  • 选型: Object Storage (AWS S3 / GCS)。
  • 原因: 相比 HDFS，对象存储更适合存储海量小文件（短视频），更便宜且易于通过 HTTP 访问。

4.3. 视频分发与观看 (The View Path)

• CDN (Content Delivery Network):
  • 核心策略: 将视频缓存到离用户最近的边缘节点 (Edge Server)。
  • 成本优化:
    • CDN 很贵。只将 热门视频 (Popular Videos) 推送到 CDN。
    • 长尾视频 (Long-tail Videos): 冷门视频直接从 Blob Storage 或源站拉取。
    • 引入 Extractor Service: 分析观看趋势，动态调整哪些视频进 CDN。
• 流媒体协议 (Streaming Protocols):
  • HLS (HTTP Live Streaming) / DASH:
    • 将视频切片 (Segments, e.g., .ts files)。
    • 客户端下载 Manifest File (e.g., .m3u8)，根据当前网速动态请求不同码率的切片 (Adaptive Bitrate Streaming)。
    • 效果: 网速好播高清，网速差播标清，过程无缝切换。

5. 进阶话题 (Advanced Topics - Show off points)

• 推荐系统 (Recommendation System):
  • 不再是简单的 Timeline (按时间倒序)，而是基于兴趣的 Feed。
  • 双塔模型 (Two-Tower Model): 用户塔 (User Features) 和 视频塔 (Video Features) 分别 Embedding，计算相似度。
• 数据合规与多数据中心 (Data Governance):
  • 不同国家（如 US, EU, China）对数据存储位置有法律要求。
  • 需部署多个 Data Centers，保证 User Data 留在特定区域。

6. 技术选型与权衡 (Trade-offs)

• Block Storage vs. Object Storage: 选 Object Storage (S3)，因为更便宜、接口友好、适合非结构化数据。
• CDN 全量 vs. 热点缓存: 权衡 Latency (延迟) 和 Cost (成本)。全量 CDN 体验最好但破产；热点缓存性价比最高。
• Upload Service 直接上传 vs. Presigned URL: 选 Presigned URL，减轻 Application Server 的带宽压力。

7. 面试金句/总结 (Key Takeaways)

• “Decouple Upload and View services to scale them independently.” (读写分离，独立扩展。)
• “Use Adaptive Bitrate Streaming (HLS/DASH) to handle varying network conditions.” (使用自适应码率流媒体技术解决网络抖动问题。)
• “Optimize CDN costs by caching only popular content (Pareto Principle / 80-20 Rule).” (利用二八定律，只缓存头部热门内容以节省 CDN 成本。)

CICD / Github Action

---

📚 系统设计面试资料：Design CI/CD System (Video 3)

1. 核心主题 (Core Topic)

• 题目： Design a CI/CD Platform (e.g., GitHub Actions, Jenkins).
• 本质： 设计一个高并发、低延迟的分布式任务调度系统，核心在于控制平面 (Control Plane) 与 数据/执行平面 (Data Plane) 的分离。

2. 需求分析 (Requirements Clarification)

• 功能性需求 (Functional):
  • Trigger Workflow: 用户提交代码 (Git Push) 触发工作流。
  • Execute Jobs: 系统接收 Workflow，将其拆解为多个 Job 并执行。
  • Real-time Status: 用户可以实时查看 Workflow 和 Job 的执行状态及日志。
• 非功能性需求 (Non-Functional):
  • Scalability: 支持海量并发构建 (假设 1B workflows/day)。
  • Low Latency: 接近实时的任务调度和状态反馈。
  • Reliability: 任务不丢失，支持重试。
  • Isolation: 多租户 (Multi-tenant) 隔离，保证安全性。
  • Decoupling: 控制层与执行层必须解耦。

3. 高层架构设计 (High-Level Design)

• 核心思想： Control Plane (大脑) 负责编排，Data Plane (手脚) 负责干活。
• 架构分层：
  1. Trigger/Ingress: Webhook / Event Listener 接收代码提交事件。
  2. Control Plane (控制平面):
     • Event Bus (Kafka): 缓冲海量请求，支持重放。
     • Workflow Orchestrator: 解析 Workflow YAML，生成 DAG (有向无环图)，管理任务依赖。
     • Database: 存储 Workflow/Job 状态。
  3. Runner Gateway: 暴露给 Runner 的统一入口，屏蔽内部细节。
  4. Data Plane (数据/执行平面):
     • Runners: 实际执行 Job 的机器 (VM/Container)。
     • Object Storage (S3): 存储构建产物 (Artifacts) 和海量日志。

4. 核心技术难点与解决方案 (Deep Dives)

4.1. 控制平面设计 (Control Plane)

• 触发机制:
  • Webhook -> Event Bus: 推荐使用 Kafka。虽然 QPS (估算约 10K-50K) 可以用 NoSQL + Change Feed 扛住，但 Kafka 对多租户隔离、优先级队列、重放支持更好。
• 数据模型 (Schema Design):
  • Tables:
    • Workflow_Run: 记录一次运行 (Run ID, Tenant ID, Commit SHA, Status)。
    • Job: 记录单个任务 (Job ID, Run ID, Status, Assigned Runner)。
    • Dependency: 记录 DAG 依赖边 (From Job -> To Job)。
  • 存储选型:
    • Sharded RDBMS (Postgres/MySQL): 使用 Tenant_ID 分片。
    • NewSQL (Spanner/CockroachDB): 高级选项，支持分布式事务和强一致性，无需分库分表，但成本高。
• 任务分发 (Dispatching):
  • CDC (Change Data Capture) 模式: 数据库写入 Job -> CDC 捕获变更 -> 写入 Outbox 表 -> 投递到 Queue -> 通知 Runner。保证了事务一致性。

4.2. 执行平面设计 (Data Plane) - Runner 通信

• Push vs. Pull (核心考点):
  • Push: 控制层主动推给 Runner。缺点: 无法穿透用户防火墙 (NAT)，需要 Runner 暴露端口，不安全。
  • Pull (推荐): Runner 主动向 Gateway 拉取任务。优点: 安全，只需出站流量。
• Pull 优化:
  • Long Polling (长轮询): Runner 发起请求挂起 60s，有任务立即返回。
  • Lease (租约) 机制: Runner 获取任务时获得 Lease，需定期续约 (Heartbeat)，否则 Controller 认为 Runner 死掉，重新分发任务。
  • WebSocket: 建立长连接，低延迟通知 Runner 唤醒。

4.3. Runner 隔离性 (Isolation)

• Container (Docker/K8s): 启动快，轻量，但共享内核，隔离性较弱（适合受信任环境）。
• Virtual Machine (VM): 隔离性好，安全，但启动慢。
• MicroVM (Firecracker / AWS Lambda): 裁剪版 VM，内存占用极低 (5MB)，启动极快 (125ms)，结合了 VM 的安全和容器的速度。这是云厂商的首选方案。

4.4. 日志与产物处理 (Logs & Artifacts)

• 状态流 (Small Data): Runner -> Gateway -> Control Plane (实时更新 UI)。
• 日志流 (Big Data): Runner -> Presigned URL -> Object Storage (S3)。不要经过 Control Plane，避免打爆带宽。
• 产物共享: Job A 产生的 Artifact 上传 S3，Job B 下载使用。

5. 技术选型与权衡 (Trade-offs)

• RDBMS vs. NewSQL: RDBMS 便宜但需要手动 Sharding；NewSQL 扩展性好但贵。
• Database-as-Queue vs. Kafka: 规模小用 DB 简单；规模大必须用 Kafka 解耦和削峰。
• WebSocket vs. Long Polling: WebSocket 实时性高但维护长连接消耗资源；Long Polling 实现简单，对于 CI/CD 这种秒级延迟容忍度也够用。

6. 面试金句/总结 (Key Takeaways)

• “Decouple Control Plane and Data Plane.” (控制面负责编排，数据面负责执行，两者必须解耦。)
• “Use Pull model for Runners to handle NAT/Firewalls securely.” (Runner 应采用拉取模式，以解决防火墙穿透和安全问题。)
• “Offload large logs and artifacts directly to Object Storage via Presigned URLs.” (大文件日志和产物直接传 S3，不要经过应用服务器。)
• “MicroVMs (like Firecracker) offer the speed of containers with the security of VMs.” (MicroVM 兼具容器的速度和虚拟机的安全性。)

支付系统

---

📚 系统设计面试资料：Design Payment System (Merchant Side) (Video 4)

1. 核心主题 (Core Topic)

• 题目： Design a Payment System (作为商家集成支付功能，而非设计银行/PSP本身)。
• 本质： 设计一个对接第三方支付平台 (PSP, e.g., Stripe, PayPal, Alipay) 的系统，核心是记账 (Ledgering)、状态管理和对账 (Reconciliation)。

2. 需求分析 (Requirements Clarification)

• 功能性需求 (Functional):
  • Pay: 用户发起支付。
  • Integration: 对接外部 PSP (Payment Service Provider)。
  • Status Check: 商家和用户能查看订单支付状态。
• 非功能性需求 (Non-Functional) - 与常规题目不同:
  • Correctness (正确性): 账目必须由分毫不错 (Zero error tolerance)。
  • Consistency (一致性): 绝不能重复扣款 (No Double Charge)。
  • Security (安全性): 符合 PCI DSS 合规要求，保护用户敏感信息。
  • Reliability: 处理外部 PSP 的宕机或网络抖动。
  • 注意：Scalability 在此通常不是首要瓶颈，因为瓶颈通常在外部 PSP。

3. 高层架构设计 (High-Level Design)

• 核心组件：
  1. Frontend (Client): 集成 PSP 的 SDK (Web/Mobile)。
  2. Merchant Payment Service: 管理订单状态、幂等性校验、调用 PSP 接口。
  3. PSP (External): 实际处理资金流转 (Stripe/PayPal)。
  4. Database: 存储交易记录 (Payment) 和账本 (Ledger)。

4. 核心技术难点与解决方案 (Deep Dives)

4.1. 支付集成方式与安全性 (Integration & Security)

• 方案演进：
  1. Server-to-Server: 商家直接收集卡号传给 PSP。缺点: 商家需要过 PCI 审计，合规成本极高，风险大。
  2. Javascript SDK (Client-Side): 前端直接发卡号给 PSP 换 Token。缺点: 容易遭受 XSS 或供应链攻击 (MageCart)，泄露卡号。
  3. Hosted Redirect / Iframe (推荐):
     • Hosted: 跳转到 PayPal 页面支付，再跳回。最安全，但转化率低。
     • Iframe + Hosted Fields: 在商家页面嵌入 PSP 的 Iframe，卡号输入框由 PSP 托管。商家只拿到 Token/Nonce。既保证体验，又规避 PCI 风险。

4.2. 避免重复扣款：幂等性 (Idempotency) - 核心考点

• 问题: 用户手抖点两次，或网络超时导致重试。
• 解决: Idempotency Key (幂等键)。
  1. 用户进入 Checkout 页面时，服务器生成一个 UUID 作为 Idempotency Key。
  2. 前端发起请求必须带上这个 Key。
  3. Payment Service 收到请求，先查库：
     • Key 不存在 -> 创建记录，执行扣款。
     • Key 已存在 -> 直接返回之前的状态，不执行扣款。
  4. 关键点: 这个 Key 也要透传给外部 PSP，让 PSP 也做幂等去重。

4.3. 数据模型设计 (Data Modeling)

• 不要用一张大表: 状态混杂极其危险。
• 表结构拆分:
  • Order Table: 业务订单信息 (商品、用户)。
  • Payment Table (交易表): 记录支付过程的状态流转 (Status: Started -> Processing -> Success)。
  • Ledger Table (账本表): Append-only (只追加)，记录资金变动，用于审计。

4.4. 异步处理与状态机 (Async Processing & State Machine)

• PSP 交互流程:
  1. Merchant 调用 PSP -> PSP 返回 200 OK (Processing) (并未最终成功)。
  2. Webhook: PSP 处理完后回调 Merchant URL 通知结果。
  3. Polling (兜底): 如果 Webhook 丢包，Merchant 需主动轮询 PSP 查询状态。
• Retry 机制 (当网络抖动时):
  • Timeout: 设置最大等待时间。
  • Exponential Backoff: 指数退避 (1s, 2s, 4s…)。
  • Jitter: 增加随机抖动 (±15%)，防止“惊群效应”打挂 PSP。
  • Dead Letter Queue (DLQ): 重试 N 次失败后，由人工介入或自动回滚。
• 状态跳变问题 (State Jump): 轮询查到“失败” -> 写入 Fail -> Webhook 迟到且显示“成功”。
  • 解决: 使用单调状态机 (Monotonic State Machine)，状态只能从 Processing -> Success/Fail，不能反向。或者使用数据库版本号 (Optimistic Locking)。

4.5. 复式记账 (Double-Entry Bookkeeping)

• 概念: 每笔交易必须涉及两个账户，一借一贷，总额平衡。
• 应用: 在 Ledger 表中，同时记录 User Account (Debit) 和 Merchant Account (Credit)。
• 优势: 财务核算的行业标准，保证资金流向可追溯，便于排查错误。

4.6. 对账 (Reconciliation)

• 任何在线系统都会出错。必须有一个 T+1 的定时任务 (Cron Job)。
• 下载 PSP 的 Settlement File (结算单)，与本地数据库逐笔比对。发现不一致，触发自动补偿或报警人工处理。

5. 进阶话题 (Advanced - Show off points)

• Event Sourcing (Turning the DB inside-out): 使用 Kafka/Pulsar 存储所有状态变更事件，Ledger 只是事件的一个 View。保证了绝对的审计追踪 (Audit Trail)。
• Risk Engine (风控引擎): 在调用 PSP 前插入风控层。
  • 简单：规则引擎 (黑名单)。
  • 复杂：机器学习 / 图神经网络 (GNN) 检测欺诈网络。

6. 技术选型与权衡 (Trade-offs)

• Relational DB (MySQL/Postgres) vs. NoSQL: 支付必须强一致性 (ACID)，首选 RDBMS。如果是超大规模，可以考虑 NewSQL (Spanner/CockroachDB) 或专门的 Ledger DB (如 Amazon QLDB)。
• Sync vs. Async: 支付本质是异步的，必须接受最终一致性，但 UI 上要给用户“正在处理”的反馈。

7. 面试金句/总结 (Key Takeaways)

• “Payment systems are about correctness, not just availability.” (支付系统首要目标是正确性，而非仅仅是可用性。)
• “Idempotency keys are mandatory to prevent double spending.” (幂等键是防止双重扣款的必要手段。)
• “Use Double-Entry Bookkeeping for the ledger to ensure auditability.” (使用复式记账法来保证账目可审计。)
• “Reconciliation is the safety net for distributed systems.” (对账是分布式系统的最后一道防线。)

任务调度系统

---

📚 系统设计面试资料：Design Distributed Job Scheduler (Video 5)

1. 核心主题 (Core Topic)

• 题目： Design a Distributed Job Scheduler (e.g., Cron as a Service, Kubernetes Scheduler, Airflow).
• 本质： 设计一个高可用、可扩展的系统，用于接收、调度和执行各种类型的任务（定时任务、一次性任务、长运行服务）。

2. 需求分析 (Requirements Clarification)

• 场景假设: 设计一个内部使用的系统 (Internal System)，用户量约 10k。
• 功能性需求 (Functional):
  • Submit Job: 用户可以提交任务 (Scripts, Binary, Long-running services)。
  • Execute Job: 系统在后台异步执行任务。
  • Status/Result: 用户可以在 Dashboard 查看任务状态和结果。
  • (Advanced): Cron Job (定时任务) 和 Dependency/DAG (任务依赖)。
• 非功能性需求 (Non-Functional):
  • Latency: 提交后 10s 内开始执行。
  • Scalability: 支持海量任务并发。
  • Reliability: 任务不丢失，支持重试，Worker 挂了能自动恢复。
  • Observability: 状态在 60s 内同步到 Dashboard。

3. 数据模型与状态机 (Data Model & State Machine)

• Job Model:
  • job_id
  • owner_id
  • binary_url (代码/脚本存储位置，如 S3)
  • type (One-off, Cron, Service)
  • status
  • retry_count
• State Machine (核心):
  • Ready (初始) -> Waiting (入队) -> Running (执行中) -> Success / Failed.
  • Failed -> Retry (次数 < Threshold) -> Waiting.
  • Failed -> Final Failure (次数 >= Threshold).

4. 高层架构设计 (High-Level Design)

• 组件拆分:
  1. Submission Service: 接收用户请求，上传二进制文件到 S3，写入 DB。
  2. Data Store (DB): 存储任务元数据和状态。
  3. Scheduler/Informer: 扫描 DB 中待执行的任务，分发给 Worker。
  4. Worker Pool: 实际执行任务的节点集群。
  5. Dashboard: 读取 DB 展示状态。

5. 核心技术难点与解决方案 (Deep Dives)

5.1. 任务分发模型 (Push vs Pull vs Hybrid) - 核心考点

• Pull Model (Worker 主动拉取):
  • Worker 轮询 (Polling) Scheduler 或 DB。
  • 优点: 简单，Worker 不会过载 (Backpressure)。
  • 缺点: 频繁轮询导致空转 (Busy Spinning)，数据库压力大；Worker 需要较大权限。
• Push Model (Scheduler 主动推送):
  • Scheduler 维护 Worker 状态，主动发 RPC 给空闲 Worker。
  • 优点: 延迟低，调度逻辑集中。
  • 缺点: Scheduler 需维护复杂的 Worker 状态映射；需处理 Worker 宕机重发。
• Hybrid Model (Sidecar 模式):
  • Sidecar 部署在 Worker 上，负责向 Scheduler 汇报心跳 (Heartbeat) 和接收任务。
  • 优点: 结合了 Push 的低延迟和 Pull 的状态管理优势。Sidecar 负责资源监控和健康检查。

5.2. 数据库选型与队列 (DB as Queue?)

• Message Queue (Kafka/RabbitMQ):
  • 优点: 解耦，削峰填谷。
  • 缺点: 引入了双写一致性问题 (DB 和 Queue 数据不一致)。需要分布式事务或 CDC。
• Database as Queue (推荐方案):
  • 利用 DB (MySQL/Postgres) 的 SELECT FOR UPDATE 或状态字段来实现队列逻辑。
  • SQL: SELECT * FROM jobs WHERE status='WAITING' ORDER BY created_at LIMIT N.
  • 优点: 单一数据源 (Source of Truth)，架构简单，适合中等规模 (10k QPS 以下)。
  • 进阶: 使用支持 Queue 语义的 NewSQL (如 Google Spanner Queue)。

5.3. 资源隔离与执行环境 (Isolation)

• Docker Containers: 轻量，启动快，适合受信任任务。
• MicroVM (Firecracker): 安全性高，隔离性好，启动速度接近容器。适合多租户不可信代码。
• 资源回收 (Reclamation):
  • 用户申请资源往往过大 (Over-provisioning)。
  • 系统可以监控实际使用量，回收未使用的资源 (Preemption) 给低优先级任务，实现混合部署 (Hybrid Deployment)，提高利用率。

5.4. 故障恢复 (Fault Tolerance)

• Heartbeat: Worker/Sidecar 每 60s 发送心跳。
• Timeout: Scheduler 检查 last_heartbeat，如果超时 (e.g., > 180s)，判定 Worker 死亡，将任务状态重置为 Waiting，重新调度给其他 Worker。

6. 进阶功能 (Advanced Features)

• Cron Service: 外部封装一个服务，维护 Priority Queue (按下次执行时间排序)，到点触发任务提交。
• DAG/Dependency: 外部封装 DAG Scheduler，进行拓扑排序 (Topological Sort)，按依赖顺序提交任务。

7. 面试金句/总结 (Key Takeaways)

• “Start with Database-as-Queue for simplicity, migrate to dedicated MQ only when scalability demands it.” (对于任务调度，起步阶段 DB 当队列用最简单，解决了分布式一致性问题。)
• “Use Sidecar pattern to decouple worker logic from communication logic.” (使用 Sidecar 模式管理 Worker 的心跳和任务接收。)
• “Isolation vs. Efficiency trade-off:” (MicroVM 提供了虚拟机的隔离性和容器的效率，是执行不可信代码的最佳选择。)

聊天系统

云盘系统

实时事件聚合

大众点评

智能驾驶

车企智能驾驶（Autonomous Driving, AD）的设计核心就是 “端云协同 + 边缘实时计算”。

智能驾驶是一个极其复杂的软硬结合系统，它更像是一个长在轮子上的机器人。

主流车企智能驾驶系统设计架构：

---

🚗 Design Autonomous Driving System (AD Stack)

1. 核心主题 (Core Topic)

• 题目： Design an L2+/L4 Autonomous Driving System (如 Tesla FSD, 华为 ADS, 小鹏 XNGP)。
• 本质：
  • 车端 (Edge): 极致的实时性（低延迟）和安全性。在算力受限（Orin芯片）和功耗受限的条件下，处理海量传感器数据并做出驾驶决策。
  • 云端 (Cloud): 极致的数据闭环。利用海量回传数据训练更大的模型，再通过 OTA (Over-the-Air) 部署回车端。

2. 需求分析 (Requirements)

• 关键指标 (Goal Metrics):
  • Latency (延迟): 生命线。摄像头拍到行人 -> 刹车启动，整个链路通常要在 100ms - 200ms 内完成。
  • Safety (安全): ASIL-D 标准（汽车行业最高安全等级），系统必须有冗余（Redundancy）。
  • Power/Compute Constraints: 车载芯片（如 NVIDIA Orin-X）算力通常在 254 TOPS 左右，远低于云端 H100，且受散热和电池限制。

3. 高层架构设计 (High-Level Design): The “Pipeline”

目前的智驾系统主要分为两种架构：传统的模块化架构 (Modular) 和 前沿的端到端架构 (End-to-End)。目前绝大多数车企处于从前者向后者过渡的阶段。

经典模块化架构 (Sense-Plan-Act):

1. Sensing (感知层): 眼睛和耳朵。
   • Sensors: 摄像头 (Camera), 激光雷达 (LiDAR), 毫米波雷达 (Radar), 超声波, IMU/GPS。
   • ISP/Pre-processing: 图像信号处理，去噪、同步时间戳。
2. Perception (认知层 - AI 重地): 理解环境。
   • Object Detection: 识别车、人、红绿灯。
   • Lane/Map: 识别车道线、路沿。
   • Fusion (融合): 将视觉和雷达数据结合（前融合 vs 后融合）。
3. Localization (定位): 我在哪里？
   • 结合高精地图 (HD Map) 和实时感知，确定车辆在厘米级的位置。
4. Prediction (预测): 别人要去哪？
   • 预测周围行人、车辆未来 3-5 秒的轨迹 (Trajectory)。
5. Planning (规划): 我该怎么走？
   • Route Planning: 全局导航（从 A 到 B）。
   • Behavior Planning: 决策（变道、超车、避让）。
   • Motion Planning: 生成平滑的具体路径曲线（速度、加速度、曲率）。
6. Control (控制): 手脚。
   • 将路径转化为方向盘转角、油门力度、刹车压力 (PID, MPC 控制算法)。

4. 核心技术难点与 Deep Dives

4.1. 感知算法：BEV + Transformer (目前的标配)

• 痛点： 以前是 2D 感知（在图像平面识别），无法直接用于 3D 物理世界的规划。
• 解决方案：BEV (Bird’s Eye View 鸟瞰图)。
  • Transformer: 利用 Transformer 的 Attention 机制，将多个摄像头（前、后、左、右）的 2D 图像特征，通过相机内外参映射到统一的 3D 向量空间 (BEV Space)。
  • OccNet (占用网络): 特斯拉引入的概念。不识别具体的“这是什么物体”，而是将世界划分为一个个体素 (Voxel)，判断“这里有没有东西占坑”。这解决了异形障碍物（如侧翻的卡车、落石）无法识别的问题。

4.2. “去高精地图” (Map-less / Light-Map)

• 背景： 高精地图维护成本极高，且鲜度（更新速度）不够。
• 趋势： 重感知，轻地图。
• 技术： 实时建图 (Real-time Mapping)。车辆一边开，模型一边实时生成局部的“地图”（车道拓扑结构）。这让智驾能覆盖到没有高精地图的农村道路或复杂城区。

4.3. 端到端 (End-to-End / One Model) —— 类似于 LLM

• 传统架构问题： 累积误差。感知错了 -> 预测就错了 -> 规划就乱了。且代码主要由 C++ 规则 (Rule-based) 堆砌，很难处理 Corner Case。
• 新架构 (Tesla FSD V12, Wayve): Video In, Control Out.
  • 整个系统就是一个巨大的神经网络。
  • 输入： 原始传感器视频流 + 导航指令。
  • 输出： 直接输出方向盘和踏板信号。
  • 原理： 类似于 GPT 预测下一个 Token，端到端模型预测的是“下一帧的车辆轨迹”。这极度依赖海量的优质人类驾驶视频进行训练。

4.4. 云端数据闭环 (Data Loop) —— 智驾的“加油站”

车卖出去后，系统设计才刚刚开始。

1. Shadow Mode (影子模式): 即使人正在驾驶，后台的 AI 也在“假装”驾驶。如果 AI 的决策和人的操作不一致（例如 AI 想直行，人却猛打方向避让），这段数据会被标记为 Corner Case 并上传。
2. Auto Labeling (自动标注): 既然人标数据太慢，就在云端用一个超大模型（Teacher Model，算力无限制）去标注回传的数据，生成真值 (Ground Truth)。
3. Training: 用这些高质量数据训练车端的小模型 (Student Model)。
4. OTA: 更新模型推送到车上。

5. 硬件与计算 (Compute)

• SoC (System on Chip): 主要是 NVIDIA Orin-X (主流高端) 或 Horizon Journey (地平线-国产)。
  • 包含了 CPU (逻辑控制), GPU/NPU (AI 推理), ISP (图像处理)。
• 异构计算:
  • FPGA: 处理激光雷达点云（极快）。
  • MCU: 安全控制（ASIL-D 级，负责最后的刹车保底，万一 AI 死机了，MCU 还能把车刹停）。

6. 总结与对比 (LLM vs AD)

如果面试问到区别，这几点是绝杀：

特性	ChatGPT (LLM)	智能驾驶 (AD System)
核心瓶颈	显存带宽 (Memory Bandwidth)	延迟 (Latency) & 功耗/散热
容错率	高 (说错话重来即可)	零 (出错可能导致事故)
计算位置	100% 云端集群	99% 边缘计算 (车端) + 1% 云端训练
数据源	互联网文本 (Static)	物理世界传感器流 (Dynamic)
模型更新	离线训练，数月一次	数据闭环，影子模式，快速迭代
技术趋势	Mixture of Experts (MoE)	End-to-End (E2E) Network

面试金句 (Key Takeaways)

• “Data is the fuel, but the Data Loop is the engine.” (数据是燃料，但数据闭环体系才是引擎。)
• “The industry is shifting from rule-based modular stacks to data-driven end-to-end networks.” (行业正从基于规则的模块化架构向数据驱动的端到端网络转变。)
• “Perception is moving to BEV space to unify multi-modal sensors.” (感知正在转向 BEV 空间以统一多模态传感器。)

High-Performance DeFi (CLOB DEX)

📚 系统设计面试资料：Design a Low-Latency CLOB DEX (Central Limit Order Book)

1. 核心主题 (Core Topic)

• 题目： Design a High-Frequency Decentralized Exchange (e.g., dYdX v4, Hyperliquid).
• 本质： 在去中心化的前提下，实现媲美中心化交易所 (Binance/Nasdaq) 的性能。核心在于解决 Blockchain Consensus (共识慢) 与 Trading Matching (撮合快) 之间的矛盾。
• 区别： 不同于 Uniswap (AMM 模型)，这里讨论的是 CLOB (中央限价订单簿)，需要极高的 TPS 和毫秒级延迟。

2. 需求分析 (Requirements Clarification)

• 功能性需求 (Functional):
  • Order Placement: 支持限价单 (Limit)、市价单 (Market)、止损单 (Stop-loss)。
  • Matching: 撮合引擎需严格按照“价格优先、时间优先”原则。
  • Settlement: 资金结算必须上链，保证非托管 (Non-custodial) 安全。
  • Market Data: 实时推送 Orderbook 和 K线数据。
• 非功能性需求 (Non-Functional):
  • Ultra-Low Latency: 端到端延迟 < 500ms，内部撮合延迟 < 1ms。
  • High Throughput: 10k+ TPS (Transactions Per Second)。
  • MEV Protection: 防止矿工/验证者通过重排交易获利 (Front-running)。
  • Correctness: 账本绝对不能错 (类似于支付系统要求)。

3. 高层架构设计 (High-Level Design)

为了追求极致速度，不能使用通用的 EVM 链（太慢），需采用 App-Chain (应用链) 或 Hybrid (混合架构)。

• 整体链路：
  1. Client (Wallet): 用户对订单数据签名 (Signing)，而非直接发送交易上链。
  2. Gateway / Sequencer: 接收签名订单，进行初步校验和定序。
  3. In-Memory Matching Engine (核心): 在内存中维护 Order Book，瞬间完成撮合。
  4. Consensus Layer (Validators): 验证者对撮合结果达成共识。
  5. On-Chain Settlement: 批量更新用户资产余额。

4. 核心技术难点与解决方案 (Deep Dives)

4.1. 撮合引擎：内存数据结构 (The Matching Engine)

• 问题: 数据库 (SQL/NoSQL) 读写太慢，无法支撑高频撮合。
• 解决方案: 全内存运行 (In-Memory)。
• 数据结构:
  • Double Linked List + HashMap:
    • HashMap<Price, LinkedList<Order>>: 快速定位某个价格档位。
    • LinkedList: 同一价格下的订单按时间排序，方便 O(1) 插入和删除。
  • Red-Black Tree (红黑树) / Skip List (跳表): 用于维护价格的有序性，方便快速查找最佳买卖价 (Best Bid/Ask)。
• 持久化: 使用 WAL (Write-Ahead Log) 技术，类似于 Redis 的 AOF，确保机器重启后能重建内存状态。

4.2. 解决区块链速度瓶颈：乐观执行 (Optimistic Execution)

• 传统区块链: 接收交易 -> 共识/打包 -> 执行 -> 确认。延迟极高。
• 低延迟 DeFi 策略: 执行 -> 共识 -> 确认。
  • 原理: 用户请求到达 Validator 后，先在内存中撮合，立即返回给用户“成交”信号 (Soft Finality)，然后再异步提交给共识层去落盘。
  • 类比: 类似于支付系统中的 “Pending” 状态，UI 上先显示成功，底层再做最终一致性。

4.3. 市场数据推送 (Market Data Propagation)

• 问题: JSON 序列化太慢，且体积大。
• 解决方案:
  • 协议: 彻底抛弃 HTTP 轮询，使用 WebSocket 或 gRPC Stream。
  • 序列化: 使用 Protobuf 或 SBE (Simple Binary Encoding)，也就是金融业标准的二进制格式。
  • 网络: 考虑使用 QUIC (基于 UDP) 替代 TCP，减少握手延迟和队头阻塞 (Head-of-line blocking)。

4.4. MEV 防护与公平性 (MEV & Fairness)

• 核心痛点: 验证者 (Validator) 可以看到内存池 (Mempool) 的订单，通过“三明治攻击” (Sandwich Attack) 抢跑。
• 解决方案: FBA (Frequent Batch Auctions - 频繁批量拍卖)。
  • 原理: 不再是“即时”处理每一笔订单，而是将极短时间窗口（例如 50ms）内的所有订单收集起来。
  • 机制: 在这个 Batch 内，所有重叠的买卖单以统一清算价 (Uniform Clearing Price) 成交。
  • 效果: 既然是同价成交，抢跑就没有意义了，从机制上消除了 Front-running 的动力。

4.5. 编程语言与并发模型 (Runtime)

• 语言: 必须是 Rust 或 C++ (无 GC 暂停)。Java/Go 的 GC (垃圾回收) 造成的几毫秒停顿在高频交易中是致命的。
• 并发模型: LMAX Disruptor (Ring Buffer) 模式。
  • Single Writer Principle: 撮合引擎核心通常是单线程的。
  • 原因: 多线程加锁 (Locking) 带来的 Context Switch 开销远大于单线程顺序执行的开销。单线程无锁设计是高性能金融系统的标配。

5. 进阶话题 (Advanced Topics)

• 衍生品设计 (Perpetuals/Futures):
  • 涉及 Funding Rate (资金费率) 计算和 Liquidation (清算) 引擎。
  • 清算设计: 需要一个高优先级的清算队列。当用户保证金率低于阈值，系统自动接管仓位并抛售，这部分逻辑必须在撮合循环中享有最高优先级 (Preemption)。
• Oracle (预言机) 延迟:
  • 链上预言机 (Chainlink) 太慢。低延迟 DeFi 通常需要 Signed Price Feeds (如 Pyth Network)，由做市商直接把价格签名推送到链上，延迟降至 400ms 级。

6. 技术选型与权衡 (Trade-offs)

• On-chain Orderbook (Solana) vs. Off-chain Matching (dYdX):
  • Solana: 纯链上，完全去中心化，但受限于全网 TPS，可能会因为发 Memecoin 导致交易所卡顿。
  • Off-chain (AppChain): 独立的验证者节点跑内存撮合，速度最快，但需要信任验证者节点不作恶 (虽有欺诈证明，但有信任假设)。
• CLOB vs. AMM:
  • AMM (Uniswap) 适合长尾资产，无需做市商，但滑点高。
  • CLOB (Orderbook) 适合主流资产 (BTC/ETH)，滑点低，适合机构，但需要流动性做市商 (Market Makers) 接入。

7. 面试金句/总结 (Key Takeaways)

• “In high-frequency DeFi, the matching engine must be kept in-memory to avoid disk I/O bottlenecks.” (高频 DeFi 中，撮合引擎必须常驻内存以避免磁盘 I/O 瓶颈。)
• “Use FBA (Frequent Batch Auctions) to mitigate MEV and front-running at the protocol level.” (利用频繁批量拍卖机制从协议层消除 MEV 和抢跑。)
• “Single-threaded execution with a Ring Buffer pattern is often faster than multi-threaded locking for matching logic.” (在撮合逻辑中，基于 Ring Buffer 的单线程执行往往比多线程加锁更快。)
• “Optimistic Execution allows Web2-like user experience with Web3 settlement.” (乐观执行机制能带来 Web2 般的流畅体验，同时保持 Web3 的结算安全。)

Fusion Trading System

在交易系统领域，“Fusion System”（融合系统）通常指的是 CeDeFi（Centralized + Decentralized Finance）混合架构，或者是 多源数据融合（Multi-Source Data Fusion） 交易引擎。

它试图解决交易领域的“不可能三角”：极致的性能（CEX的延迟） + 资产的自我主权（DEX的安全） + 统一的流动性（Global Liquidity）。

这是目前交易所架构设计的最前沿（如 Binance Connect, Fireblocks Off-Exchange, dYdX v4, Layer 2 Rollups）。

以下是参照你的笔记风格设计的 Fusion Trading System 架构方案：

---

🌐 Design a Fusion Trading System (Hybrid CeDeFi Architecture)

1. 核心主题 (Core Topic)

• 题目： Design a Hybrid Exchange / Fusion Trading System (CeDeFi).
• 本质： “Web2 的速度 + Web3 的信任”。
  • 将 计算（撮合/定序） 放在链下（Off-chain）以获得微秒级延迟。
  • 将 清算/托管（Settlement/Custody） 放在链上（On-chain）或通过 MPC 技术保障资金安全，防止 FTX 暴雷事件重演。

2. 需求分析 (Requirements)

• 功能性需求 (Functional):
  • Unified Account: 用户使用一个钱包连接，既能交易 CEX 的深度，也能交易 DEX 的资产。
  • Non-Custodial (or Semi-Custodial): 交易所倒闭了，用户的钱还在（资产隔离）。
  • Best Execution: 自动在 CEX 和 DEX 之间寻找最优价格（Smart Routing）。
• 非功能性需求 (Non-Functional):
  • Latency: 撮合延迟 < 1ms (Web2 级别)。
  • Throughput: 10k+ TPS。
  • Transparency: 必须提供 PoR (Proof of Reserves) 或 ZK-Proof 证明撮合逻辑没有作弊。

3. 高层架构设计 (High-Level Design)

系统被撕裂为两个平行的世界，通过 “Fusion Bridge” 连接：

2. Fast Lane (Off-chain Control Plane): 负责处理高频数据、撮合、风控。类似于传统的高频交易系统。
3. Slow Lane (On-chain Data Plane): 负责资产托管、最终结算、存取款。
4. Fusion Layer (Trustless Bridge): 使用 MPC (多方计算) 或 ZK (零知识证明) 同步状态。

4. 核心技术难点与解决方案 (Deep Dives)

这是 Fusion 系统的核心。如何做到“钱在交易所里方便交易，但交易所又卷不走钱”？

• 传统方案: 多重签名 (Multi-Sig)。缺点是链上 Gas 贵，且暴露签名策略。
• Fusion 方案: MPC-CMP (Multi-Party Computation)。
  • 私钥分片 (Key Sharding): 用户的私钥被切分为 3 个分片 (Key Shares)。
    • Shard 1: 用户手机本地保存。
    • Shard 2: 交易所服务器保存。
    • Shard 3: 第三方审计机构 (Oracle) 保存。
  • 交易流程:
    • 正常交易时，Shard 1 + Shard 2 参与计算生成签名（不需要拼凑完整私钥，直接生成签名）。
    • 交易所宕机/作恶时，用户联系第三方，使用 Shard 1 + Shard 3 恢复资产。
  • 优势: 链上看着就是一个普通地址，但链下实现了“相互制衡”的资产安全。

系统需要同时看到 CEX (Binance/OKX) 和 DEX (Uniswap/Curve) 的价格。

• 架构:
  • Ingestion:
    • CEX: WebSocket (Tick-level data).
    • DEX: 监听 Mempool (内存池) 和 RPC 节点事件。
  • Fusion Engine (加权融合):
    • 不能简单取平均值。需要计算 VWAP (成交量加权平均价)。
    • 置信度衰减: 链上数据通常滞后，需要给 CEX 数据更高的权重，但需通过 DEX 的 TWAP (时间加权价格) 进行异常值过滤（防插针）。
  • Smart Router:
    • 用户下单 -> 引擎拆单 -> 80% 走 CEX 撮合（深度好），20% 走 DEX（套利或滑点更低） -> 最后给用户一个混合均价。

如何证明链下的撮合引擎（Fusion Engine）没有作弊（比如没有在前置交易）？

• 技术栈: StarkEx 或 zkSync 架构。
• 流程:
  1. Batching: 交易所将 10,000 笔撮合结果打包。
  2. Proving: 生成一个 ZK-SNARK/STARK Proof。这个数学证明向链上合约保证：“这 10,000 笔交易后的余额变动，严格遵守了订单簿逻辑，且每个人都有足够余额”。
  3. Verifying: 链上智能合约验证 Proof。验证通过，一次性更新 Merkle Root（状态根）。
• 效果: 只有状态根上链，数据不上链（Validium 模式），既便宜又快，同时数学上保证了交易所无法篡改用户余额。
• 为了融合 Web2 和 Web3，需要一个 Sequencer。
• Soft Finality (软确认): 用户下单，Sequencer 收到并排序，立即返回“成功”。用户体验是实时的。
• Hard Finality (硬确认): Sequencer 异步将 Batch 提交到 L1 区块链。
• 灾难恢复 (Escape Hatch): 如果 Sequencer 宕机或审查用户，系统必须允许用户直接在 L1 链上通过“强制提款 (Forced Exit)”操作取回资金。

5. 进阶场景：RWA Fusion (现实资产融合)

• 场景: 在系统里交易美股 (Apple/Tesla) 但使用 USDT 结算。
• 设计:
  • Tokenization: 合作的信托公司持有真实股票。
  • Mapping: 链上生成对应的 Token (Back-backed Token)。
  • Fusion Oracle: 即使美股休市，Fusion 系统也可以基于盘后交易数据或衍生品价格提供 24/7 的流动性报价。

6. 技术选型与权衡 (Trade-offs)

• MPC vs. Smart Contract Custody:
  • MPC: 兼容所有链（包括 Bitcoin），隐蔽性高，离线签名更快。 (选这个做 Fusion 更好)。
  • Smart Contract: 透明，但只能在 EVM 链上跑，容易被黑客攻击合约漏洞。
• ZK-Rollup vs. Optimistic Rollup:
  • ZK: 提现快（数分钟），数学安全性。但生成证明需要昂贵的算力。
  • Op: 提现慢（7天挑战期），开发简单。对于高频交易系统，必须选 ZK 以保证资金流转效率。

7. 面试金句/总结 (Key Takeaways)

• “Fusion systems decouple execution from settlement.” (融合系统将“交易执行”与“资金结算”解耦：执行在 Web2 跑，结算在 Web3 跑。)
• “MPC provides an institutional-grade security layer without sacrificing usability.” (MPC 提供了机构级的安全性，同时不牺牲用户体验，是连接 CeFi 和 DeFi 的桥梁。)
• “Use ZK-proofs for integrity, not just scaling.” (在这里使用零知识证明不仅仅是为了扩容，更是为了证明交易所的清白/偿付能力。)
• “The Escape Hatch is the ultimate trustless guarantee.” (逃生舱机制是去中心化系统最后的信任底线。)

Design AR Navigation System

手机 AR（Video See-Through, VST）可以容忍一定的延迟和抖动，因为你是在看屏幕。但 AR 眼镜（Optical See-Through, OST）是将虚拟图像直接投射到视网膜或镜片上，如果虚拟箭头无法紧紧“贴”在物理路面上（漂移），或者有延迟（拖影），用户会立刻产生严重的眩晕感（Motion Sickness），甚至导致安全事故。

我为你设计了一套针对 AR 硬件端的导航组件系统架构。

---

** Design AR Navigation System (for AR Glasses/HUD)**

1. 核心主题 (Core Topic)

• 题目： Design an AR Navigation SDK / Component for Optical See-Through Devices.
• 本质： “将比特锚定在原子上” (Anchoring Bits to Atoms)。
  • 核心不是“画地图”，而是高精度姿态追踪 (6DoF Tracking) 与 坐标系转换 (Coordinate Transformation)。
  • 需要解决 GPS 精度不够（5米误差在 AR 里就是穿墙）和 渲染延迟（导致“晕车”）的问题。

2. 需求分析 (Requirements)

• 功能性需求 (Functional):
  • Wayfinding: 在真实路面上渲染 3D 箭头/地毯 (Virtual Carpet)。
  • POI Pinning: 识别建筑物并在其物理位置上方悬浮信息卡片。
  • Context Awareness: 识别红绿灯、斑马线、障碍物（结合 ADAS）。
• 非功能性需求 (Non-Functional) —— 硬件端的生死线:
  • Motion-to-Photon Latency (MTP): < 20ms。从头动一下，到光子打入眼睛，必须在 20ms 内完成，否则世界会“晃动”。
  • Registration Accuracy: < 10cm / 0.5度。虚拟物体必须像钉子一样钉在现实里，不能随头转动而漂移。
  • Power & Thermal: 功耗极低（眼镜电池小，且不能发烫烧脸）。

3. 高层架构设计 (High-Level Design)

采用 “端云协同，端侧重型” (Edge-Heavy, Cloud-Supported) 的架构。

1. Sensing Layer (硬件层): IMU (1000Hz), 摄像头 (Gray/RGB), GPS, 深度雷达 (LiDAR/ToF)。
2. Tracking Layer (定位层 - 核心): VIO (视觉惯性里程计) + VPS (视觉定位服务)。
3. World Model (理解层): 实时网格化 (Meshing)、遮挡处理 (Occlusion)。
4. Rendering Layer (表现层): 坐标转换与 3D 渲染 (Unity/Unreal/Custom Engine)。

4. 核心技术难点与解决方案 (Deep Dives)

4.1. 解决“漂移”：VPS + VIO 融合定位

仅靠 GPS (GNSS) 在 AR 导航中是不可用的，因为 GPS 误差 3-5 米，会导致导航箭头插到隔壁楼里。

• VIO (Visual Inertial Odometry):
  • 本地快速响应： 使用 IMU (高频 1000Hz) 积分计算短时间内的位移和旋转，再用 Camera (低频 30/60Hz) 的特征点匹配来消除 IMU 的积分漂移。
  • 算法： 扩展卡尔曼滤波 (EKF) 或非线性优化 (Factor Graph)。
• VPS (Visual Positioning Service) - “重定位” (Relocalization):
  • 云端校准： VIO 跑久了也会飘。系统需每隔几秒上传一张当前环境的“关键帧”到云端。
  • 特征匹配： 云端将图片与预先扫描的 3D 点云地图 (如 Google Geospatial API, Immersal, 百度 VPS) 进行比对。
  • PnP 解算: 云端返回设备在地球上的绝对坐标 (Lat, Lon, Alt) 和精确朝向，以此修正本地 VIO 坐标系。

4.2. 坐标系转换管线 (The Coordinate Pipeline)

这是 Map 组件开发最容易晕的地方，涉及三个坐标系的实时转换：

1. Geodetic (地理坐标系): 经纬度 (GPS 数据)。
2. ECEF (地心地固坐标系): X, Y, Z (笛卡尔坐标，方便计算距离)。
3. Local Tangent / Unity World (本地渲染坐标系): 此时此刻，眼镜开机点为 (0,0,0)。

• 设计模式:
  • 创建一个 AnchorManager。
  • 当收到导航路径点 (GPS) 时，先转为 ECEF，再根据当前 VIO 的原点位置，转为 Local 坐标。
  • Floating Origin (浮动原点): AR 场景很大，坐标数值过大会导致浮点数精度丢失 (Z-fighting, 抖动)。技巧： 每走 100米，将世界坐标原点 (0,0,0) 重置到用户脚下，所有虚拟物体反向移动。

4.3. 极致低延迟：Late Latching (晚期锁存) & Time Warp

为了达到 <20ms MTP 延迟，仅仅代码写得快是不够的，需要图形学技巧。

• 问题: 渲染一帧需要时间 (e.g., 16ms)。在 GPU 渲染这 16ms 里，用户的头可能又转了 2 度。如果直接显示渲染好的图，画面就滞后了。
• 解决方案: Asynchronous Time Warp (ATW) / Late Latching。
  • Late Latching: CPU 提交渲染命令给 GPU 前的最后一微秒，再次读取最新的 IMU 数据，修改 View Matrix (视图矩阵)。
  • ATW: 甚至在 GPU 渲染完图像，准备发给显示屏 (Display Scanner) 的瞬间，由硬件对 2D 图像进行一次基于最新旋转的“扭曲/平移”修正。这通常由底层 SDK (如 Qualcomm Snapdragon Spaces, Apple ARKit) 处理，但应用层需要提供分离的 Depth Buffer。

4.4. 虚实遮挡 (Occlusion)

• 现象: 导航箭头浮在真实世界的树或墙的前面，大脑会觉得极度怪异。
• 方案: 深度缓冲 (Depth Buffer) 融合。
  • 利用硬件的 ToF 或双目摄像头生成实时的 Depth Map。
  • 在 Shader 中比较：如果 (虚拟像素.Z > 真实像素深度.Z) -> discard (不渲染)。
  • 透明蒙版: 也可以将真实世界的墙体渲染为“透明材质”但写入深度信息，从而挡住后面的虚拟箭头。

5. 组件接口设计 (SDK Interface Design)

如果这不仅是一个 App，而是一个给其他开发者用的 Map 组件：

interface ARNavigationSession {
  // 配置：透视模式（视频透视 VST / 光学透视 OST）
  mode: 'VST' | 'OST';

  // 启动定位与SLAM
  start(): void;

  // 输入：传统的经纬度路径
  setRoute(coordinates: GeoPoint[]): void;

  // 核心：每帧更新，驱动渲染
  // 传入当前的相机矩阵，返回可以在屏幕上画的 3D Mesh 对象
  update(cameraPose: Matrix4x4): ARRenderable[];
}

// AR 渲染对象结构
interface ARRenderable {
  mesh: Geometry;
  transform: Matrix4x4; // 在本地坐标系的位置
  type: 'Arrow' | 'Path' | 'Destination';
  occlusionMode: 'AlwaysVisible' | 'DepthTest'; // 是否被真实物体遮挡
}

6. 技术选型与权衡 (Trade-offs)

• OST (Hololens/Magic Leap) vs. VST (Apple Vision Pro):
  • OST (透明镜片): 无法做到“硬遮挡”（虚拟无法显示黑色，只能变暗），强光下看不清。UI 设计必须用高饱和度、高对比度颜色（如荧光绿导航线）。
  • VST (摄像头透视): 可以完美遮挡，但如果相机延迟高，用户会吐。
• Cloud Anchors (Google/Azure) vs. Private Deployment:
  • 公有云 VPS 覆盖广，但有隐私和数据合规风险（尤其在中国，测绘法限制）。
  • 自建 VPS 成本极高，通常只在特定园区/商场做。
• Battery vs. Performance:
  • 需要在 SLAM 频率上做动态调整。静止时降低 VIO 频率，快速转头时拉满。

7. 面试金句/总结 (Key Takeaways)

• “In AR Navigation, the map is not a 2D canvas, it’s a 3D digital twin alignment problem.” (AR 导航不是在画布上画图，而是数字孪生与物理世界的对齐问题。)
• “Latency is the enemy of presence. Use Late Latching and Timewarp to cheat time.” (延迟是沉浸感的大敌，必须用晚期锁存和时间扭曲技术来“欺骗”时间。)
• “VPS (Visual Positioning) is the new GPS for the spatial computing era.” (在空间计算时代，VPS 才是真正的 GPS。)
• “Don’t just render data; render it ‘in context’ with occlusion.” (不要只渲染数据，要结合遮挡关系在“语境”中渲染。)

---

系统设计面试资料：Design Live Streaming Platform (Twitch/虎牙)

1. 核心主题 (Core Topic)

• 题目： Design a Live Streaming Platform (e.g., Twitch, Huya, Douyu).
• 本质： 设计一个能处理实时视频流摄取 (Ingest)、处理 (Processing) 和分发 (Distribution) 的系统，同时包含高并发的即时通讯 (Chat) 系统。

2. 需求分析 (Requirements Clarification)

• 功能性需求 (Functional):
  • Broadcaster (主播): 推流 (Start Streaming)、录制 (Recording/VOD)。
  • Viewer (观众): 观看直播 (Watch)、发送弹幕/聊天 (Chat)、打赏 (Donation)。
  • System: 实时转码 (Transcoding) 以适配不同网速。
• 非功能性需求 (Non-Functional):
  • Latency (延迟): 核心指标。
    • 互动直播（连麦）：< 1秒。
    • 普通直播（带弹幕）：< 5秒 ~ 10秒 (不能像电视广播那样滞后30秒)。
  • Scalability: 支持单房间百万级并发 (C1M Problem)。
  • High Availability: 直播流不能断。
  • Consistency: 支付/打赏必须强一致，弹幕可以最终一致甚至丢弃。

3. 高层架构设计 (High-Level Design)

直播架构主要分为三条链路：

1. 视频流链路 (Video Streaming Path): 推流 -> 网关 -> 转码 -> 分发 -> 拉流。
2. 即时通讯链路 (Chat/Danmaku Path): WebSocket -> 网关 -> 消息路由 -> 推送。
3. 控制/管理链路 (Control Plane): API Server, Metadata DB, Payment。

• 架构图组件流向：
  1. 主播 (OBS软件): 使用 RTMP 协议推流。
  2. Ingest Server (摄取服务器): 维持与主播的长连接，接收视频流。
  3. Transcoding Service (转码集群): 将原始流转换为不同分辨率 (1080p/720p/480p) 和协议 (HLS/DASH)。
  4. CDN (内容分发网络): 缓存视频切片，边缘分发。
  5. Viewer (客户端): 从 CDN 拉取 HLS/FLV 流播放。

4. 核心技术难点与解决方案 (Deep Dives)

4.1. 协议选择与延迟权衡 (Protocol & Latency) - 核心考点

• 推流 (Upload):
  • RTMP (Real-Time Messaging Protocol): 行业标准。基于 TCP，延迟低，适合推流，但不适合大规模分发（因为需要维持长连接，服务器负载高）。
• 拉流 (Download/Playback):
  • 方案 A: RTMP/HTTP-FLV (低延迟):
    • 延迟 1~3秒。
    • 缺点：需要专用服务器，CDN 成本较高，iOS 浏览器不支持。
  • 方案 B: HLS (HTTP Live Streaming) / DASH (推荐):
    • 原理：将视频切成小文件 (Segments, .ts)，生成索引文件 (.m3u8)。客户端轮询下载。
    • 延迟：默认 10-30秒 (取决于切片大小)。
    • 优点：基于 HTTP，穿透性好，利用现有的 CDN 基础设施，极其廉价且易扩展。
  • 优化方案: LL-HLS (Low Latency HLS) / CMAF:
    • 将 HLS 的切片切得更小（Chunked Transfer Encoding），可将延迟降至 3-5秒，兼顾了成本和体验。

4.2. 视频流处理 (Ingest & Transcoding)

• GOP (Group of Pictures) 对齐:
  • 转码器在输出不同分辨率的流时，必须保证关键帧 (Keyframe) 对齐。否则用户在切换清晰度时会画面花屏或跳跃。
• 分布式转码:
  • 参考你之前提供的 Video 5 (Job Scheduler)。将实时流转码任务分发给 Worker Pool。但直播是实时的，通常采用 流式处理 (Stream Processing) 而非批处理。

4.3. 弹幕系统设计 (Chat/Danmaku) - 高并发难点

• 场景: 李佳琦直播间，100万人同时在线，每秒 10万条弹幕。
• 架构:
  • WebSocket: 客户端与 Chat Gateway 建立长连接。
  • Pub/Sub (发布订阅模式): 使用 Redis Pub/Sub 或 Kafka。
  • 流程: 用户 A 发送 -> Gateway -> Kafka -> 消费者处理 (风控/存储) -> Redis Pub/Sub (Topic=RoomID) -> Gateway -> 推送给房间内其他用户。
• 优化 (Shedding & Sampling):
  • 如果 QPS 太高，客户端渲染不过来，人眼也看不清。
  • 限流与丢弃: 服务端需要进行消息降级。例如：高优先级消息 (礼物/超管) 必达；普通弹幕随机丢弃，或者每秒只推送 50 条给客户端。

4.4. 直播回放 (VOD Recording)

• 参考 Video 2 (Video Sharing)。
• 在 Transcoding 环节，除了生成实时流推给 CDN，同时启动一个 Worker 将视频切片上传到 Object Storage (S3) 归档，作为录播文件。

5. 技术选型与权衡 (Trade-offs)

• TCP vs. UDP:
  • 推流和拉流主要用 TCP (RTMP/HTTP)，保证画质稳定。
  • 如果是 连麦/视频会议 (Zoom/Google Meet)，则必须用 WebRTC (基于 UDP) 以实现 <500ms 的延迟，但画质会因网络抖动而模糊。
• Push vs. Pull (CDN):
  • 直播通常采用 Push 到边缘节点或边缘节点回源 Pull。为了秒开，CDN 边缘节点需要预缓存最新的切片。

6. 结合之前视频知识点的应用 (Cross-Reference)

• From Video 2 (TikTok): 使用 CDN 分发视频内容是相同的，区别在于 TikTok 是静态文件，Twitch 是动态生成的切片。
• From Video 4 (Payment): 直播打赏 (Tipping) 涉及资金，必须使用 Idempotency Key 和 事务，不能因为高并发弹幕系统崩了导致钱扣了没显示。
• From Video 5 (Scheduler): 如果直播间需要转码资源，需要 Scheduler 动态分配高计算能力的 GPU 机器。

7. 面试金句/总结 (Key Takeaways)

• “Hybrid Latency Approach:” (使用 RTMP 进行推流以保证低延迟摄取，使用 HLS/DASH 结合 CDN 进行分发以保证大规模扩展性。)
• “Separate Control Plane and Data Plane:” (视频流数据走 CDN 专用通道，信令/弹幕/支付走 API 网关通道。)
• “Message Shedding is necessary for high-concurrency chat:” (在超大直播间，必须在服务端进行弹幕限流和丢弃，以保护客户端和带宽。)

Google TL系统设计 - CICD / Github Action

系统设计 01 - develop a website

Google TechLead系统设计 - design tiktok

Google TechLead系统设计 - design 大众点评/yelp

Google TechLead系统设计 - 任务调度系统

Google TechLead系统设计 - 设计云盘

Google TL系统设计 - 广告事件聚合系统

Google TL系统设计 - 聊天系统/WhatsApp

Google TL系统设计 - 支付系统

Google TL系统设计 - LLM inference service

Google TL系统设计 - CICD / Github Action

Q.E.D.