题目重点：围绕低延迟、高可用与最终一致性拆分匹配队列、房间权威状态、跨区故障转移和通信协议。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版小型房间游戏每个房间由某一时刻唯一权威进程处理玩家输入；房间内动作顺序必须确定，跨房间统计允许最终一致。
- 客户端到房间保持低延迟长连接；WebSocket 作为易部署基线，若玩法需要 UDP/QUIC 再根据丢包、顺序与设备支持评估。
- 玩家可按延迟/区域进入匹配队列，跨区匹配在等待过久后放宽；题目未明确公平性或 MMR 规则。
解题路线
- 先澄清每局人数、状态大小、动作频率、容忍回滚和 p95 目标，计算每房间消息吞吐与跨区 RTT；不能从‘实时’直接选单一数据库。
- 匹配服务按 region、队伍规模、等级段、等待时长排队；匹配到后以原子 reservation 占位并设 TTL，重复匹配请求用 playerId/sessionId 幂等处理。
- 房间权威进程串行处理带 sequence 的输入，广播状态增量；客户端预测与服务器校正属于玩法可选项，禁止客户端直接写共享 DB 作为动作排序来源。
- 玩家账户、匹配历史、排行榜可异步写多地域数据库并最终一致；房间瞬时状态由单权威维护，不能因账户库最终一致就让同一局出现多个同时权威。
- 故障时用 lease/epoch 阻止旧进程继续接受输入，检查点+事件日志恢复可用状态；断线重连按 roomId、lastSeenSeq 补增量或快照。
- 跨区优先就近布房间，区域故障转移会增加延迟或中断房间；明确 SLO、恢复点和降级策略，监控匹配等待、动作 RTT、丢包、分叉与重连成功率。
手动走一遍
A、B 在同区域匹配成房间 R，matchmaker 写一次 reservation，R 的权威实例持有 epoch 7。网络故障后实例 8 接管 epoch 8，旧实例即使恢复也不能广播已过期动作。排行榜可稍后同步，但一局射击/移动顺序不能在两个区域各自独立判定。
规模与取舍
设在线玩家 P、平均每房间 r 人、每人每秒 a 个动作，权威服务约 O(Pa) 输入处理与按广播策略 O(Pa·r) 出站消息；房间数约 P/r。存储容量取决于检查点频率、事件日志保留和跨区复制；题目无 P/r/a 实数。
易错点与追问
容易失分的边界
- 把 eventual consistency 套到同局动作顺序，导致双方各自获胜。
- 匹配成功后无占位/幂等，玩家进入两个房间。
- 只用数据库选主却没有 epoch fencing，旧房间进程继续发状态。
- 没按地域估 RTT 就承诺低延迟与全局单房间。
继续深挖
- 跨区域好友组队与延迟公平怎样权衡？
- 房间进程崩溃后恢复多少状态才算满足 HA？
- 观战人数远大于玩家时怎样扇出广播？
- 输入作弊、重放和客户端时钟偏差如何处理？
