后端定时过期方案选型
最近有个需求：让智能机器人在用户 1 hour 内无活跃消息后，自动关闭当前用户会话，避免无效的上下文对用户的下次提问造成干扰。这里只涉及到后端强制过期清空上下文，前端是否需要有变化/通知基于业务场景去设计就好。我主要是想到了如下三种方案并分析了一下它们的优劣。
定时任务扫表更新状态
分析
创建一个定时任务，每个小时跑一次，每次游标分批捞出会话表中 50 条活跃的会话，check一下该会话关联的 最新消息是否在 1 hour 内，没有的话就把会话状态设置为失效。
优点
- 每小时执行，天然具有重试逻辑，并且每次执行会过滤掉已经失效的会话
- 异步执行，在原代码中不存在耦合逻辑，改造量小
缺点
- 会加重数据库读负担，但是在主从分离的场景下，优先读从库，并且考虑到当前场景的新增会话体量较小，系统负载可接受
- 需要控制分布式场景下单实例执行，考虑当前公司有比较成熟的分布式任务框架，市面上也有类似 Quartz 这种分布式任务框架，可以直接使用
- 会话过期逻辑相对复杂，需要保证编码质量，考虑分批游标的方式减轻内存/CPU压力
Redis key 过期事件监听
分析
新创建会话时设置一个 key = conversationId 的 redis key，expiration time = 1hour，每次有会话关联的消息更新/新增时需要重置其关联的会话 redis key 的 expiration time = 1 hour
优点
- 没有很重地会话失效逻辑，收到 key 过期事件就将对应的会话失效
- 不会加重数据库负担
缺点
- 代码中需要在 insert 会话、create/update 消息处耦合 redis 逻辑，改造量大
- 频繁更新 redis 性能较差
- Redis 过期事件是在服务器删除 key 时发出的，不是 key 过期就会直接发出；Redis 惰性删除 + 过期删除的机制会导致时效性差，删除 key 的时机不一定是 key 过期的时机
- 过期事件监听丢失无法重试
RocketMQ 延迟消息推送
分析
新创建会话时延迟 1 hour 发送一条消息，消费者 1hour 后收到消息会校验该会话的状态，每次有会话关联的消息更新/新增时需要再发送一条其关联的会话的相同延迟消息
优点
- 消息有重试机制，稳定性较高
- 不会加重数据库负担
缺点
- 代码中需要在 insert 会话、create/update 消息处耦合 MQ 逻辑，改造量大
- 每次 insert 会话、create/update 消息都需要发送 MQ，消息冗余
- 接收到消息的会话过期逻辑比较复杂，需要校验状态，也需要做消息幂等处理
- 会有许多和最终关闭会话无关的消息发送出来
最终选型
最终选型为 定时任务扫表更新状态
因为其天然具有重试逻辑，并且不会在原有代码中耦合逻辑，改造成本比较小，此外还没有过多无效消息被发出来。