XX 物流同城快递架构设计文档

背景介绍

XX 是某上市公司全资投资成立的一家物流快递公司，主要进行同城快递业务，公司刚刚成立，主要竞品为https://ishansong.com/。

公司组建了 20 人的技术部门，准备两个月后系统开发完成上线。

功能需求

• 用户通过 app 发起快递下单请求并支付

• 快递员通过自己的 App 上报自己的地理位置，每 30 秒上报一次

• 系统收到快递请求后，向距离用户直线距离 5km 内的所有快递员发送通知

• 快递员需要进行抢单，第一个抢单的快递员得到配单，系统向其发送用户详细地址

• 快递员到用户处收取快递，并记录到系统中：已收件

• 快递员将快递送到目的地，并记录到系统中：已送达

订单量预估：预计上线三个月后，日订单 50 万。

需求分析

需求用例

下单抢单场景的业务活动图

性能指标估算

日订单 50 万，快递员每 30 秒上报一次自己的位置。

存储性能估算

【订单】

日订单 50 万，假设每条订单需要 1K 的存储空间，则每天所需要存储空间为：

50 万 * 500 / 1024 / 1024 / 1024 ≈ 0.48T

【快递员地理位置】

假设每个快递员平均每天可以服务 200 个订单，则需要快递员数量：

50 万 / 200 = 2500

快递员 ID、经度、纬度都为 4 个字节，则位置信息所需要存储空间为：

2500 * 3 * 4 /1024 ≈ 29K

可以忽略不计

计算性能估算

【快递下单】

订单集中在早上 8：00~晚上 20：00，假设时间段内下单总量占比为 80%，则下单 TPS 为：

50 万 * 80% / (10 * 3600) = 11/秒

【抢单】

时间段同快递下单，5 公里半径面积为 78.5 平方公里，假设市区面积 3000 平方公里，则参与抢单的快递员数量为：

2500 / (3000 / 78.5) ≈ 32

最极端情况，32 个快递员同一秒一起抢单，则抢单 TPS 为：

32/秒

【快递员地理位置】

每 30 秒上报一次，则 TPS 为：

2500 / 30 秒 ≈ 83 / 秒

概要设计

部署模型

详细设计

下单抢单场景的服务器时序模型

下单：订单服务收到请求后，保存订单到数据库，保存抢单信息到分布式缓存，推送抢单消息给消息队列。

抢单：消息消费者订阅到新的抢单消息后，获取 5km 内有效的快递员，推送抢单通知。快递员收到抢单通知开始抢单，抢到后配单更新订单状态，返回用户详细信息给快递员。

订单状态图模型

新快递单：用户下单后付款失败，或其它因素未付款，达到支付超时时间后，将订单置为失效状态。

用户在配单前可以选择退款取消订单。

配单后的订单，如果取消需要缴纳一定额度的罚金。