1. 抢单系统概述：业务场景、核心挑战、性能指标定义
各位同学，咱们今天聊聊抢单系统。说实话，我做了十几年高并发系统，抢单系统是我见过最“拧巴”的业务场景之一。为什么？因为它既要快，又要准，还得扛得住瞬间流量洪峰。嗯，咱们一步步拆解。
1.1 业务场景：到底什么是“抢单”？
抢单，说白了就是多个用户同时竞争一个有限资源。你想想看，外卖骑手抢订单、网约车司机抢乘客、电商平台抢限量商品——本质都一样。
我参与过一个日活千万的外卖平台项目。高峰期，一个热门商家的订单刚发布，瞬间就有几百个骑手同时点击“抢单”按钮。系统要在几十毫秒内完成：
- 资源锁定：确保订单不被重复抢走
- 规则校验：检查骑手距离、评分、接单上限
- 结果返回：告诉用户“抢到了”还是“手慢了”
这里有个坑——你以为的“同时”，在计算机世界里其实是“串行”的。我曾经见过一个团队，上线第一天就被流量打崩了，原因就是没理解这个本质。
1.2 核心挑战：抢单系统为什么难做？
我总结了三座大山，你听听看是不是这么回事：
挑战一：高并发下的数据一致性
抢单系统最怕什么？超卖。一个订单被两个人同时抢到，那就是事故。我在项目中遇到过，库存扣减用了乐观锁，但并发一高，CAS重试次数飙升，数据库连接池直接打满。嗯，后来改成了Redis+Lua脚本才稳住。
核心矛盾：性能要求高（毫秒级响应） vs 一致性要求严（不能超卖）
挑战二：瞬时流量洪峰
抢单的流量曲线不是平滑的，是脉冲式的。平时可能只有几百QPS，抢单瞬间飙到几万甚至几十万。我见过最夸张的一次，某平台搞“秒杀”，预热阶段流量就翻了20倍，网关直接挂了。
为什么会这样？因为用户会提前刷新页面、反复点击。你想想看，一个订单背后可能是几千次无效请求。
挑战三：公平性与防作弊
这个容易被忽略。抢单系统如果被脚本党、黄牛盯上，普通用户根本抢不到。我做过一个分析，某次抢单活动中，前10%的“用户”抢走了80%的订单——全是机器脚本。
注意：防作弊不能只靠前端限制，后端必须做风控。我曾经见过一个团队，只在前端加了点击频率限制，结果人家直接绕开前端调接口，照样抢得飞起。
1.3 性能指标定义：怎么衡量系统好坏？
做性能优化，首先得知道“好”的标准是什么。我个人习惯用这几个指标：
| 指标 | 定义 | 抢单系统建议值 |
|---|---|---|
| QPS | 每秒查询数，衡量系统吞吐能力 | 单机至少 5000+，集群按需扩展 |
| TP99 | 99%的请求在多少毫秒内完成 | 抢单核心链路 ≤ 200ms |
| 成功率 | 抢单请求成功返回的比例 | ≥ 99.9% |
| 超卖率 | 实际抢到人数超过库存的比例 | 0%（必须严格保证） |
| 资源利用率 | CPU、内存、网络IO的使用情况 | CPU ≤ 70%，内存 ≤ 80% |
这里我要强调一下：TP99比平均响应时间更有意义。平均响应时间容易被极端值拉低，但TP99能真实反映大多数用户的体验。我记得有一次优化，平均响应时间从500ms降到了100ms，但TP99还是800ms——说明还有一批用户体验很差，后来发现是慢查询导致的。
避坑指南：我曾经在压测时只看平均QPS，结果上线后用户反馈“卡死了”。后来才明白，峰值QPS才是关键。建议压测时关注“毛刺”——就是那些突然飙升的请求，它们才是压垮系统的元凶。
1.4 知识体系总览
下面这张图是我自己画的，把抢单系统的核心知识点串起来了。你仔细看看，后面每一章都会围绕这些展开：
这张图其实就概括了咱们这门课的核心脉络。业务场景决定了你要解决什么问题，核心挑战告诉你难点在哪，性能指标则是你判断优化是否有效的标尺。三者缺一不可。
好了，第一章就到这里。记住一句话：抢单系统调优，不是堆机器就能解决的。后面咱们会深入每个环节，从架构设计到代码实现，一步步把性能榨干。