题目重点：针对题目只给主题的开放系统题，明确训练假设后讨论事件接入、地理候选、能力匹配、原子认领与故障重派。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版事件含位置、严重等级、所需能力与截止时间；英雄含实时位置、能力、当前任务与可用状态。一次事件允许先分配一名英雄，多名协同是追问。
- 位置先按地理格/H3 类单元粗筛，最后按地球表面距离/预计到达时间精排；具体索引产品不作为题面事实。
- 目标为优先救援严重事件且避免同一英雄同时接两单，派单可以在短时窗口内最终一致，但认领必须原子化。
解题路线
- 先和面试官定规模与目标：事件/秒、在线英雄数、位置更新频率、候选半径、响应 SLA，以及是否所有城市都覆盖；不急于画微服务。
- 事件写入带唯一 ID 的持久队列；地理索引按最近位置粗筛在线英雄，再过滤技能、状态、距离/预计到达时间，排序时给严重事件与长时间等待事件明确权重。位置 TTL 过期的英雄不作可派候选。
- 向最优候选发送 offer，采用事件/英雄上的租约或版本化 CAS：只有一个待认领 offer 能成功，超时或拒绝再派下一候选。记录每次 offer/接受/撤销，消息重试按事件 ID 和 attempt ID 幂等。
- 英雄离线、定位延迟、网络分区、紧急事件无人可派时设置扩圈、技能要求可否放宽及人工升级规则；严重安全事件不能靠静默降级。
- 用事件受理到首次 offer、接单率、到场时间、重派率、位置新鲜度、重复认领率做分层指标。多英雄协作时把事件任务拆子任务并设 barrier/替补，而非把单人租约硬套全局。
手动走一遍
虚构训练例：事件 E 在位置 x 需飞行能力，附近 H1 距离 2km 但位置已 10 分钟未更新，H2 距离 5km 且新鲜可用。过滤 H1 后先 offer H2；若 15 秒未确认，租约失效并试 H3。即使 H2 的迟到确认到达，也必须因 attempt 版本过期而拒绝，防止双接单。所有数值均为训练假设。
规模与取舍
一次派单若在线英雄 H 全扫为 O(H)，地理格索引取候选 K 后粗筛近似 O(K)，排序 O(K log K)；位置更新成本随 U 次更新及索引写放大增长。网络和人工响应是主延迟，需按场景估算。
易错点与追问
容易失分的边界
- 只说像 Uber，未问严重事件、能力、可用性和救援安全边界。
- 只根据距离选人，忽略位置过期和技能。
- 两个调度 worker 并发给同一英雄派两单，无原子状态或租约。
- 租约超时后迟到确认仍成功，导致冲突。
- 把训练假设说成题目披露的规模和要求。
继续深挖
- 一个事件需要三名不同能力英雄同时到场时，如何避免只到两人而无人接最后一个槽？
- 恶意/误报事件如何抑制而不延误真正急救？
- 跨地域灾难导致本地区英雄全忙时怎样扩圈和预留应急容量？
