🚗 Uber 系统设计学习平台

第1章:系统设计的本质

在开始设计 Uber 之前,我们需要先理解一件事:系统设计到底在考什么?

很多人以为系统设计就是"画画图,说说技术栈",这是错的。

🎯 本章学习目标

• 理解系统设计面试的真实意图
• 学会从业务问题到技术问题的转化
• 掌握系统设计的基本思维框架

1.1 为什么选 Uber 作为案例?

Uber 是一个经典的分布式系统设计案例,因为它几乎覆盖了所有核心考点:

1.2 这不是编程题

系统设计面试和算法题最大的区别是:没有标准答案。

面试官不是在找"正确的架构图",而是在看你的思考过程。

📊 系统设计的评分维度

第2章:从需求到设计边界

现在正式开始设计 Uber。第一步不是画图,而是明确需求。

很多人觉得这一步简单,其实这是最容易拉开差距的地方。

🎯 本章学习目标

• 学会如何拆解功能需求
• 理解非功能需求的优先级
• 掌握"什么该做,什么不做"的边界判断

2.1 功能需求拆解

Uber 是一个连接乘客和司机，提供按需乘车服务的全球平台，支持移动端请求乘车、匹配司机、实时跟踪及支付。本文档以结构化方法设计一个高可扩展、高并发的乘车系统，涵盖需求分析、容量估算、数据模型、架构组件及优化策略。设计重点包括一致性、可扩展性和优化用户体验。

• 更新司机位置: 司机定期发送当前位置（每 4 秒）。系统更新位置信息，并用于匹配乘客。
• 查找附近的司机: 乘客按位置搜索附近可用司机。返回列表，包含司机基本信息（ID、姓名、车辆类型、评分）。
• 请求乘车: 匹配：乘客输入下车地点后，系统匹配附近司机。确认：司机接受后，行程开始，乘客看到预计到达时间（ETA）。
• 扩展功能（可选，暂不讨论）: 查看行程历史、评价司机/乘客、提前预约行程。

2.2 非功能需求的权衡

• 可扩展性: 支持高峰流量，如特殊活动期间的百万级并发请求。
• 可用性: 匹配和跟踪功能保持 99.99% 正常运行。
• 性能: 响应时间 <1 秒，匹配响应 <500 ms。
• 可靠性: 数据不丢失，故障恢复时间 <1 分钟。
• 安全性（可选，暂不讨论）: 防止刷单（速率限制、CAPTCHA）。遵守数据保护规范（加密、用户同意）。
• 优先级: Availability-first at system level, with CP guarantees for critical paths (matching & payment)。

第3章：容量估算

目标：量化记录规模、存储量、分片数和缓存需求，为后续设计提供依据。

3.1 为什么要算容量?

容量估算是系统设计的基础，它帮助我们理解系统的规模、潜在瓶颈，并指导硬件和架构选择。没有容量估算，设计容易脱离实际，导致过度或不足优化。

3.2 从 DAU 到服务器

容量估算的目的是量化系统的规模需求，为技术选型提供依据。我们从 DAU（日活跃用户）开始，逐步推导出 QPS、存储、分片数和硬件需求。

📊 第一步：基础假设

📈 第二步：计算峰值 QPS

计算公式：

峰值 QPS = DAU × 每用户每秒请求数

具体计算：

1. 乘客请求 QPS
   • 乘客 DAU：2000 万
   • 每乘客每秒请求数：0.02
   • 计算：2000 万 × 0.02 = 400k QPS
2. 司机位置更新 QPS
   • 司机 DAU：300 万
   • 每司机每秒更新数：0.25（每 4 秒更新一次）
   • 计算：300 万 × 0.25 = 75k QPS
3. 其他操作（支付、历史查询等）
   • 估计：275k QPS
4. 总峰值 QPS
   • 计算：400k + 75k + 275k = 750k QPS
   • 加上缓冲（50%）：750k × 1.5 = ~1M QPS

读写比例分析：

• 读操作（查询附近司机、查历史）：约 50k QPS
• 写操作（位置更新、匹配、支付）：约 750k QPS
• 读写比 = 1:15（写操作为主）

💾 第三步：计算存储需求

计算公式：

3 年总行程数 = 每天行程数 × 365 天 × 3 年

具体计算：

1. 3 年总行程数
   • 计算：2000 万 × 365 × 3 = 21.9 亿次
2. 每条行程记录大小
   • tripID (UUID)：16 B
   • riderID、driverID：32 B
   • 坐标、时间戳、状态等：100 B
   • 总计：约 150 B/条
3. Trips 表原始数据大小
   • 计算：21.9 亿 × 150 B ÷ 1024³ = 2.2 TB
4. 加上索引（约 30%）
   • 计算：2.2 TB × 0.3 = 0.66 TB
5. 加上副本（2 份备份）
   • 计算：(2.2 + 0.66) × 2 = 5.72 TB
6. 其他表（Riders、Drivers、DriverLocations）
   • 估计：3 TB
7. 总存储需求
   • 计算：5.72 + 3 = 8.72 TB
   • 加上 20% 增长缓冲：8.72 × 1.2 = ~10.5 TB

🔀 第四步：计算分片数

核心问题：为什么要分片？

单台数据库无法处理 750k 写 QPS。通过分片，我们将数据分散到多台机器，每台机器只处理一部分数据和请求。

计算公式：

分片数 = 峰值写 QPS ÷ 单分片承载 QPS

具体计算：

1. 单分片承载能力
   • 假设单台 Cassandra 节点可承载：1k QPS
2. 需要的分片数
   • 计算：750k ÷ 1k = 750 个分片
   • 加上 50% 冗余和高可用：750 × 1.5 = ~1000 个分片
3. 每分片的数据量
   • 计算：8.72 TB ÷ 1000 = 8.72 GB/分片

🖥️ 第五步：计算硬件需求

计算公式：

服务器数 = 峰值 QPS ÷ 单服务器承载 QPS

具体计算：

1. 单服务器承载能力
   • 假设单台服务器可承载：1k QPS（在 p99 < 200ms 的延迟下）
2. 高峰期服务器需求
   • 计算：800k ÷ 1k = 800 台服务器
   • 加上 50% 冗余（故障转移、维护）：800 × 1.5 = ~1200 台
3. 平时服务器需求
   • 假设平时 QPS：5k
   • 计算：5k ÷ 1k = 5 台服务器
   • 加上冗余：5 × 1.5 = ~8 台

💰 第六步：缓存需求

热点数据分析：

• 热门位置（如机场、火车站）占查询的 80%
• 这些热点数据可以缓存在 Redis 中

缓存数据量计算：

1. 热门司机位置
   • 热门司机数：300 万 × 20% = 60 万
   • 每条记录大小：50 B
   • 计算：60 万 × 50 B = 30 MB
2. 热门查询结果
   • 热门查询数：100 万条
   • 每条结果大小：100 B
   • 计算：100 万 × 100 B = 100 MB
3. 总热点数据量
   • 计算：30 + 100 = 130 MB
4. Redis 内存规划
   • 考虑 HA（主从复制）、内存碎片、写放大
   • 规划：16-32 GB

📋 总结表

第4章：数据模型设计

核心实体与 API 设计。

4.1 核心实体关系

1. Riders（乘客）: RiderID (PK, UUID)、name、email、phone、photo
2. Drivers（司机）: DriverID (PK, UUID)、name、email、phone、vehicleType、rating
3. Trips（行程）: TripID (PK, UUID)、riderID (FK, UUID)、driverID (FK, UUID)、pickupLat、pickupLong、dropoffLat、dropoffLong、status (pending/accepted/inprogress/completed)、eta、version (乐观锁)
4. DriverLocations（司机位置）: DriverID (PK, UUID)、lat、long、timestamp

数据模型与分片策略：采用 查询驱动设计 (Query-Driven Design)，通过数据冗余满足不同维度的查询需求：

1. Trips 表: Partition Key: tripID。用途：根据 ID 查询行程详情、状态流转。
2. TripsByRider 表 (或物化视图): Partition Key: riderID。Clustering Key: timestamp (DESC)。用途：乘客查看“我的行程历史”。
3. TripsByDriver 表 (或物化视图): Partition Key: driverID。Clustering Key: timestamp (DESC)。用途：司机查看“接单记录”。

Driver State Machine：IDLE → OFFERED → ACCEPTED → IN_TRIP → IDLE ↘ timeout / reject ↗ ACCEPTED → CANCELLED_BY_RIDER → IDLE (with penalty cooling) IN_TRIP → INCIDENT → SUPPORT_HANDLING → IDLE IN_TRIP → timeout (2 hrs) → FORCE_COMPLETE → REVIEW

实体关系：Riders 一对多 Trips（requests）。Drivers 一对多 Trips（accepts）。Drivers 一对一 DriverLocations（has）。

4.2 查询驱动设计

关键概念：查询驱动设计

在传统关系型数据库中，我们追求范式化（消除冗余）。但在 NoSQL 中，我们追求反范式化（接受冗余），以满足不同的查询模式。

为什么需要多个表

场景 1：根据 tripID 查询行程详情

• 如果只有一个 Trips 表，按 tripID 查询很快（O(1)）

场景 2：乘客查看"我的行程历史"

• 如果只有一个 Trips 表（按 tripID 分片），查询某个乘客的所有行程需要全表扫描（O(n)），导致延迟爆炸

解决方案：创建多个表

• Trips：按 tripID 分片，用于根据 ID 查询
• TripsByRider：按 riderID 分片，用于乘客查历史
• TripsByDriver：按 driverID 分片，用于司机查历史

这样做的代价是数据冗余，但收益是查询性能的提升。

数据模型详解

表 1：Trips（主表）

用途：根据 tripID 快速查询行程详情

分片键：tripID

{
  "tripID": "uuid-123",
  "riderID": "rider-456",
  "driverID": "driver-789",
  "pickupLat": 37.7749,
  "pickupLong": -122.4194,
  "dropoffLat": 37.8044,
  "dropoffLong": -122.2712,
  "status": "completed",
  "eta": 1200,
  "fare": 25.50,
  "rating": 4.8,
  "timestamp": "2024-01-01T10:30:00Z",
  "version": 3
}
                

表 2：TripsByRider（查询表）

用途：乘客查看自己的行程历史

分片键：riderID

排序键：timestamp（降序，最新的行程在前）

{
  "riderID": "rider-456",
  "timestamp": "2024-01-01T10:30:00Z",
  "tripID": "uuid-123",
  "driverID": "driver-789",
  "pickupLocation": "Airport Terminal 1",
  "dropoffLocation": "Downtown Hotel",
  "fare": 25.50,
  "status": "completed"
}
                

表 3：TripsByDriver（查询表）

用途：司机查看自己的行程历史

分片键：driverID

排序键：timestamp（降序）

{
  "driverID": "driver-789",
  "timestamp": "2024-01-01T10:30:00Z",
  "tripID": "uuid-123",
  "riderID": "rider-456",
  "pickupLocation": "Airport Terminal 1",
  "dropoffLocation": "Downtown Hotel",
  "fare": 25.50,
  "earnings": 18.00,
  "status": "completed"
}
                

数据同步机制

当一个行程被创建或更新时，需要同时更新三个表。为了保证一致性，我们使用 CDC（Change Data Capture）+ Kafka：

1. 应用写入 Trips 表
2. Cassandra 的 CDC 捕获这个变更
3. 发布事件到 Kafka
4. 后台服务订阅 Kafka，更新 TripsByRider 和 TripsByDriver

权衡分析

我们的选择：多表设计，因为查询性能对用户体验至关重要。

第5章：关键流程

整体采用分层微服务架构，支持水平扩展、高可用性和低延迟。客户端请求通过负载均衡器分发到独立微服务，缓存优化读性能，数据库保证一致性，消息队列处理异步任务。微服务间使用 gRPC 通信，外部 API 保持 RESTful。

5.1 位置更新与搜索

1. 负载均衡器：AWS ELB，分发流量，支持自动扩缩和故障转移，基于路径的 L 7 路由。
2. 微服务: 位置服务：更新并存储司机位置，使用 cell-based spatial index (e.g. S 2 / H 3) 支持地理搜索。匹配服务：POST /ride/request 和 /ride/confirm，使用 Redis 锁 + Cassandra 轻量级事务处理。行程服务：GET /ride/{tripID}，优先从 Redis 缓存读取，未命中则访问 Cassandra。ETA 服务：计算实际路网行驶时间。
3. 缓存：Redis，存储热门位置和搜索结果，TTL 4~10 秒，命中率预期 95%。
4. 数据库: Cassandra：主存储，按 tripID 或 (riderID, timestamp) 分片（Trips），driverID 分片（Drivers），支持轻量级事务和主从复制。Cell-based spatial index：位置索引，动态分区，结合 Redis 哈希表处理高频更新。
5. 消息队列：Kafka，用于异步任务（支付确认、通知推送），128 分区，保留 7 天。
6. CDN：CloudFront，缓存静态资源（如地图数据），全球分布，延迟 <100 ms。
7. 监控：Prometheus + Grafana，跟踪 QPS、延迟和错误率，触发 Auto Scaling。

We treat driver location as ephemeral data: real-time reads go to memory, persistence is asynchronous and lossy by design. 实时位置 → Redis / in-memory geo store，Kafka 作为 buffer + async archive，Cassandra 只存 sampled / trip-scoped trajectory。Real-time search paths never depend on database replication or CDC pipelines. Persistence is asynchronous and does not block matching。

存储热门位置结果（key=SHA 256 (lat+long+radius)），TTL 4 秒。命中率 95%，80% 查询来自 20% 热门位置。扩展性：Cell-based spatial index 动态分区，每分区 2 k QPS。Prometheus 监控延迟 >500 ms，触发扩容或分区优化。GDPR 合规：位置日志匿名化，用户敏感信息加密。

5.2 匹配与确认

问题：高峰热门位置 QPS 过载。现象：特殊活动时，QPS >800 k，数据库过载，匹配延迟，用户重复请求导致流失。原因：Trips 表 21.9 亿行，读延迟 >1 秒。位置状态频繁变化，传统 API 返回静态数据，用户手动刷新造成 30% 无效请求。

1. 虚拟等待队列：Redis ZSET 管理 queue:location:{lat_long}，会员优先、随机防刷，POST /queue/join 加入，定时出队（每秒 100 用户）。
2. 实时更新：SSE 推送队列进度和匹配状态（Kafka 广播）。
3. 扩展性：ELB + Kubernetes Auto Scaling（CPU>80%），Cassandra 按 tripID 或 (riderID, timestamp) 分片（Trips），driverID 分片（Drivers），每分片 44 GB，1 k QPS，2 从扩展读负载。
4. 监控：Prometheus 跟踪 QPS、延迟、错误率，动态调整出队速率。
5. CDN 缓存：CloudFront 缓存地图数据（TTL 1 min），延迟 <100 ms。

权衡：虚拟队列 vs 速率限制：队列公平、实时反馈，降低用户焦虑；速率限制简单但不透明，易增加 QPS。SSE vs 长轮询 vs WebSocket：SSE 单向、低开销，适合实时位置更新；WebSocket 内存消耗大；长轮询延迟高。选择：队列 + SSE，优先用户体验和可扩展性。

第6章：架构权衡

选择：S 2/H 3 + Redis，优先性能和可扩展性，接受运维复杂性。

原因：简单查询 O (n) 随司机增长线性上升，高峰 QPS 50,000 导致 CPU >90%，用户体验差。Cell-based spatial index 分区降低至 O (log n)，Redis 缓存热门查询（80% 流量）提速 10 倍，总体延迟 <200 ms。实例：Uber 使用 cell-based spatial index 支撑百万 QPS，崩溃率降 90%。

6.1 CAP 与一致性

问题：数据一致性保证。问题：数据库（Cassandra）与位置索引（cell-based spatial index）、缓存（Redis）之间存在数据同步延迟或不一致风险。高峰期用户查询和匹配操作可能看到过期数据，导致匹配错误或搜索结果不准确。

原因：Cassandra → cell-based spatial index 使用 CDC（Debezium）同步，存在 ~1 秒延迟。双写模式若处理不当，会出现写入失败或事务异常导致数据不同步。缓存更新策略不当（过期/主动失效）会产生脏数据或缓存雪崩。

1. 数据库与位置同步: 使用 CDC 捕获变更，Kafka 保证事件顺序，延迟 <1 秒。双写模式：仅在原子事务成功后写入 cell-based spatial index，保证最终一致性。版本号机制：在行程或位置记录中维护 version，每次更新递增，消费者通过 version 校验更新，防止旧数据覆盖新数据。
2. 缓存一致性策略: Cache Aside（推荐）：应用更新数据库后主动删除缓存，下次访问重建。Write Through / Write Behind：适用于写入集中且对延迟容忍高的场景。雪崩防护：热门数据加随机 TTL、限流更新，避免大量缓存同时过期。
3. 监控指标设计: 数据延迟监控：Cassandra → cell-based spatial index 延迟、Redis 缓存命中率。一致性校验：定期对比主库和位置索引数据，发现差异报警。告警阈值设置：延迟 >2 秒或一致性错误 >0.1% 触发通知。

权衡：CDC vs 双写：CDC 延迟可接受（<1 秒），系统解耦；双写强一致性，但实现复杂、易出错。缓存策略：Cache Aside 灵活、可控；Write Through 写入延迟低，但数据库压力高。选择：CDC + Cache Aside + 版本号机制，兼顾性能、可扩展性和一致性。

原因：高峰期用户查询和匹配并发高，若数据不同步或缓存过期，会导致匹配错误、搜索结果不准确和用户体验下降。通过 CDC + 版本号 + Cache Aside，可确保最终一致性，延迟 <1 秒，缓存命中率 >95%，整体系统稳定性和用户体验提升。

6.2 缓存策略

缓存的三个关键问题

1. 缓存穿透：查询不存在的数据，每次都穿透到数据库
2. 缓存雪崩：大量缓存同时失效，请求全部打到数据库
3. 缓存一致性：缓存和数据库的数据不一致

Uber 的缓存架构

缓存层次：

• L1 缓存：应用本地缓存（Guava Cache）- 延迟 <1ms
• L2 缓存：Redis 分布式缓存 - 延迟 <10ms
• L3 缓存：Cassandra 数据库 - 延迟 <100ms

缓存策略对比

Uber 的选择：Cache Aside + 版本号机制

Cache Aside 详解

读流程

1. GET cache:trip:{tripID}
   ├─ 命中 → 返回数据（延迟 <10ms）
   └─ 未命中 → 继续
   
2. SELECT * FROM Trips WHERE tripID = X
   ├─ 查询成功 → 继续
   └─ 查询失败 → 返回错误
   
3. SET cache:trip:{tripID} data EX 300
   └─ 设置 TTL 5 分钟
   
4. 返回数据给应用
                

写流程

1. UPDATE Trips SET status = 'completed', version = version + 1 WHERE tripID = X
   └─ 更新成功 → 继续
   
2. DEL cache:trip:{tripID}
   └─ 删除缓存（强制下次查询从数据库读取）
   
3. 发布 CDC 事件到 Kafka
   └─ 其他服务订阅并更新自己的缓存
                

缓存穿透解决方案

问题：查询一个不存在的 tripID，每次都穿透到数据库，浪费资源。

解决方案 1：缓存空值

// 查询结果为空时，也缓存一个特殊值
SET cache:trip:{tripID} "NOT_FOUND" EX 60
// TTL 设置较短（60 秒），避免长期占用内存
                

解决方案 2：布隆过滤器

• 在 Redis 中维护一个布隆过滤器，包含所有有效的 tripID
• 查询前先检查布隆过滤器，不存在则直接返回错误
• 优点：节省内存，查询快速

缓存雪崩解决方案

问题：大量缓存同时失效（如 Redis 重启），请求全部打到数据库，导致数据库宕机。

解决方案 1：随机 TTL

// 不使用固定 TTL，而是随机 TTL
base_ttl = 300  // 5 分钟
random_ttl = base_ttl + random(0, 100)  // 5-6.67 分钟
SET cache:trip:{tripID} data EX random_ttl
                

解决方案 2：热点数据永不过期

• 对于热点数据（如机场附近的司机），设置 TTL 为无穷大
• 通过后台任务定期刷新这些数据

解决方案 3：缓存预热

• 系统启动时，预先加载热点数据到缓存
• 避免启动后的初期流量全部打到数据库

缓存一致性保证

使用版本号机制：

// 缓存中存储版本号
cache:trip:{tripID} = {
  "data": {...},
  "version": 3
}

// 查询时检查版本号
GET cache:trip:{tripID}
if (cache.version < db.version) {
  // 缓存版本过旧，删除并重新加载
  DEL cache:trip:{tripID}
  // 重新从数据库加载
}
                

性能指标

权衡总结

第7章：高峰场景

问题：高峰热门位置 QPS 过载。问题：支付集成与异步处理。现象：同步支付高峰期延迟秒级，阻塞匹配服务，用户流失。原因：Stripe 等第三方支付响应慢（网络/验证 200 ms–2 s），高峰写 QPS 100，同步模式放大延迟。

7.1 虚拟队列设计

1. 异步支付：POST /confirm 创建 PaymentIntent，立即返回“支付处理中”，Webhook 异步回调处理。
2. 事务更新：Webhook 验证 tripID，Cassandra 执行 UPDATE IF status=..., 成功发布 Kafka 事件。
3. 幂等处理：Webhook 重试，事务检查 status=completed 避免重复。

Payment is async and out-of-critical-path。

权衡：Webhook vs 同步：Webhook 异步、延迟低、解耦服务；同步简单但高峰阻塞。Stripe vs 自建支付：Stripe 高可用、快速集成、合规，费用高；自建灵活但开发复杂。选择：Stripe + Webhook + Kafka，优先可靠性和快速部署。

7.2 并发一致性

问题：并发匹配一致性。现象：高峰期一个司机匹配多次（overmatching），行程错误，用户投诉。原因：分布式高峰 QPS 写请求高，多个请求同时访问同一司机记录。单纯数据库事务在高并发下效率低。

1. Redis 分布式锁：SETNX 锁司机（TTL 3-5 s），快速过滤并发。
2. 轻量级事务：锁成功后，Cassandra 执行 UPDATE IF version=...，失败回滚。
3. 异步通知：Kafka 发布匹配成功事件。
4. 错误处理：锁失败返回 429，事务冲突返回 409，返回司机状态。
5. 监控：锁冲突率 >1%，事务重试率 >5%，可调整 TTL 或分片策略。

权衡：SETNX + 轻量级事务：降低 90% 并发冲突，延迟 <100 ms，需管理锁 TTL。纯轻量级事务：简单，但高并发重试率高，延迟 >500 ms。悲观锁：强一致性，单分片 QPS <1 k，高峰易卡顿。选择：SETNX + 轻量级事务，兼顾一致性和性能。

第8章：面试策略

整体设计围绕 高并发、高可用、良好用户体验 展开。通过 cell-based spatial index 位置优化、Redis 缓存与队列、分布式锁、异步支付 等手段，系统在百万级 QPS 下依然保持稳定。微服务架构和消息队列保证了 扩展性和解耦性，同时监控和自动伸缩机制让系统在高峰期依然可靠。

简而言之，这套方案 既解决性能瓶颈，又确保用户体验和运维可控，适合大规模乘车平台的生产环境。

8.1 如何讲述设计

在面试中，先明确需求边界，然后量化规模，找到瓶颈，最后针对性设计方案。解释每个选择的“为什么”。

8.2 常见追问

• 如何处理高峰流量？
• 一致性如何保证？
• 为什么选择这个数据库/缓存？
• 如果规模翻倍，怎么扩展？