系统设计面试：设计Uber
「设计Uber」是最常见的系统设计题之一，因为它同时涉及地理空间索引、实时位置流、匹配以及高写入吞吐量。面试官并不是想听到Uber真实的架构——他们想看你如何界定问题范围、做出有依据的选择，并大声推理规模问题。
按照有条理的顺序来做：先明确需求，再估算规模，勾勒核心实体和API，设计数据与匹配路径，最后讨论瓶颈和权衡取舍。下面的讲解遵循这个顺序，让你练习的是结构本身，而不仅仅是答案。
1. 明确需求
在设计之前，把功能性需求和非功能性需求分开，并先定好范围。乘客发起打车请求，实时看到司机接近；司机上线并接收附近的请求；系统将二者匹配，并跟踪行程直至完成。
- 功能性需求：发起打车请求、与附近司机匹配、实时跟踪行程、计费、行程历史。
- 非功能性需求：低延迟匹配（秒级）、高可用性、实时位置更新、一致性——一个司机只能被分配给恰好一个乘客。
- 范围之外（要明确说出来）：支付处理的内部实现、评分系统、动态加价的机器学习模型——提及即可，然后推后处理。
2. 估算规模
粗略的数字能为之后的选择提供依据。假设日活司机约1000万，每4秒发送一次位置心跳——这意味着每秒约250万次位置数据写入，这是一个写密集型负载，立刻排除了把朴素关系型表作为热路径的方案。
3. 核心组件与API
勾勒出服务和请求流程。让匹配路径独立于持久化的行程存储，这样各自可以按照自身特性进行扩展。
- 位置服务：接收司机的位置心跳，将当前位置保存在内存中的地理空间索引里。
- 匹配服务：收到打车请求时，查询附近在线的司机并分配一个。
- 行程服务：持久化记录行程的生命周期（已请求 → 已匹配 → 进行中 → 已完成）。
- 通知/推送：将司机的实时位置推送给乘客（WebSocket/长轮询）。
4. 地理空间匹配——问题的核心
这是面试官最想听到的部分。存储原始经纬度并逐一扫描是O(n)的；你需要一个空间索引。讲解四叉树或地理哈希（geohashing）：把地图划分成网格，让「查找这个点附近的司机」变成查询少数几个网格，而不是全量扫描。
地理哈希将一个区域编码成一个短字符串，共享前缀意味着空间上的相邻，这让「附近」变成了一个前缀查询。司机当前所在的网格保存在内存存储（例如Redis）中，以实现快速读取和频繁更新；网格粒度是精度与查询扇出之间可调节的权衡。
5. 可扩展性与瓶颈
指出压力点以及你会如何缓解它们。每秒250万次位置写入的数据流是最主要的压力点。
- 按地理区域对位置索引进行分片——同一个城市的司机和乘客由同一分片处理，让匹配保持在本地。
- 用内存存储和异步持久化写入来吸收写入高峰；并不需要每一次心跳都写入持久化数据库。
- 用原子化分配（锁或条件更新）来保证一位司机只对应一位乘客，避免重复预订。
- 在位置数据接入和下游消费者之间使用消息队列（Kafka）来解耦突发流量。
6. 需要说出来的权衡取舍
最后点明面试官看重的那些张力：强一致性与最终一致性（司机分配必须是强一致的，位置展示可以是最终一致的）、内存速度与持久性、网格尺寸的精度与查询扇出。明确说出这些权衡，才是及格答案与出色答案的分水岭。
借助实时辅助练习Uber的系统设计
Natively的系统设计面试助手可以在实际面试中帮你保持结构清晰——实时建议接下来该覆盖哪个维度，并呈现权衡取舍，一切都在你自己的设备上完成。
