游戏REST API失联玩家数据自动清理方案可行性咨询

现有Node Cron方案的可行性与效率 #

你提出的用Node Cron每30秒检测失联玩家（updatedAt超过1分钟未更新则清理）的方案是可行的，但在效率和实时性上存在局限：

• 优点：实现简单，依赖成熟的定时任务库，逻辑直观，适配中小玩家量级的场景。
• 缺点：
  • 固定轮询易造成无效负载：玩家数量少时，频繁的数据库查询会浪费资源；玩家数量多时，单次全表/大范围扫描可能拖慢服务性能。
  • 清理实时性不足：从玩家失联到被清理，最短需30秒，最长可能接近90秒（心跳停止1分钟+下一次轮询的30秒间隔），会延迟释放大厅位置，影响新玩家匹配体验。

更优替代方案 #

1. 数据库TTL索引原生过期机制 #

如果你的数据库支持TTL（Time-To-Live）索引（如MongoDB、Redis、MySQL 8.0+），这是最高效的方案：

• 给会话表的updatedAt字段创建TTL索引，设置过期时间为1分钟，数据库会自动清理超时的会话记录。
• 通过数据库的变更监听（比如MongoDB的changeStream），在会话被自动删除时，触发从对应大厅的sessions数组中移除该sessionId的操作。
• 优势：无需额外定时任务服务，利用数据库原生能力完成清理，实时性更高，同时降低应用层逻辑复杂度和数据库轮询负载。

2. 心跳触发的延迟队列方案 #

• 玩家每发送一次心跳，就创建一个延迟1分钟执行的任务（任务内容为清理该玩家的会话和大厅数据），同时取消之前为该玩家创建的延迟任务。
• 玩家主动退出时，直接取消对应的延迟任务并执行清理操作。
• 优势：仅针对活跃玩家创建任务，资源利用率更高，清理动作可在玩家失联1分钟后立即执行，实时性拉满。可借助BullMQ、Bee-Queue等Node.js延迟队列库实现。

3. 优化后的定时任务方案（若坚持使用Cron） #

如果仍倾向于定时任务，可以通过以下优化提升效率：

• 添加索引：给updatedAt字段创建索引，查询时仅筛选updatedAt < 当前时间 - 1分钟的记录，避免全表扫描。
• 调整轮询间隔：改为1分钟一次，因为失联判定阈值是1分钟，30秒间隔会有一半查询无有效数据，徒增负载。
• 批量处理：一次查询所有待清理会话，批量从大厅中移除sessionId，减少数据库操作次数。

总结 #

• 中小规模场景：优化后的定时任务或TTL索引方案均可，后者更省心。
• 大规模高并发场景：延迟队列方案的资源利用率和实时性更优。

内容的提问来源于stack exchange，提问作者jeputier