企业级事件总线的自动回收机制需以业务语义驱动销毁：客户端断连或心跳超时即发sessiondestroyevent，按序释放资源并发布审计事件；辅以ttl兜底扫描、租户/服务标签隔离、引用计数及弱引用监听器，并通过结构化事件与prometheus指标实现可观测闭环。
构建具备自动回收机制的企业级事件总线，核心不是堆砌功能，而是让资源生命周期与业务语义对齐——会话不该靠“定时扫垃圾”来清理，而应随事件流自然消亡。
基于事件驱动的会话销毁
传统轮询清理容易滞后，导致内存堆积和会话泄漏。正确做法是将销毁逻辑绑定到真实业务信号上：
- 客户端断开连接时，立即触发 SessionDestroyEvent，不等待下一次扫描
- 心跳检测超时（如连续3次未响应）即判定会话失效，同步发布销毁事件
- 销毁函数 DestroySession 需按顺序执行：先关闭推理上下文或数据库连接等资源，再从会话存储中删除记录，最后发布 SessionClearedEvent 用于审计
时间阈值兜底策略
事件驱动虽及时，但需防止单点故障导致销毁事件丢失。因此必须叠加时间维度的保险机制：
- 为每个会话打上创建时间戳，并配置 ttl_seconds: 3600（默认1小时）
- 后台启用轻量级周期任务（cleanup_interval: 300，每5分钟一次），仅扫描并清理已过期且未被主动销毁的会话
- 该扫描不遍历全量数据，而是通过索引快速定位过期区间，避免性能抖动
资源隔离与引用计数
企业级场景常需多租户、多服务共用同一总线，回收不能“一刀切”：
- 每个会话关联唯一 tenant_id 和 service_tag，销毁时按标签过滤，避免误删其他业务线资源
- 关键资源（如推理上下文、临时缓存）采用引用计数，只有计数归零才真正释放；一次事件可能被多个下游订阅，需等全部处理完成再减计数
- 事件总线自身维护弱引用监听器列表，防止UI组件或临时处理器残留导致内存泄漏
可观测性闭环
自动回收是否生效，不能靠猜测——必须可验证：
- 每次销毁操作必须发布结构化事件（含 session_id、reason、duration、resource_freed），投递至监控链路
- 在 Prometheus 中定义指标：eventbus_session_active_total（当前活跃数）、eventbus_session_leaked_total（泄漏累计数），配合 Grafana 做趋势告警
- 定期抽样比对：从事件日志中提取销毁事件，反查会话存储确认是否真实移除
