Apache DolphinScheduler JDBC注册中心重构：支持会话超时与数据变更事件

背景与挑战

Apache DolphinScheduler作为分布式任务调度系统，其服务发现机制是整个系统稳定运行的关键基础。当前版本中基于JDBC的注册中心实现存在几个显著问题：

1. 架构设计不够清晰，代码维护困难
2. 客户端心跳数据与业务数据强耦合，调试排查问题不便
3. 所有客户端必须使用相同的配置，缺乏灵活性
4. 数据变更事件基于快照对比实现，多次变更可能导致事件丢失

这些问题在实际生产环境中可能引发服务发现不及时、配置管理混乱等问题，亟需架构层面的重构优化。

重构设计方案

整体架构

新的JDBC注册中心采用清晰的分层设计，将功能明确划分为服务端和客户端两部分：

• JdbcRegistryServer：每个服务实例创建一个，负责维护客户端心跳、响应客户端请求
• JdbcRegistryClient：提供数据操作、锁获取、事件订阅等能力

核心数据结构

重构引入了两张关键表来解耦心跳数据和业务数据：

1. 客户端心跳表(t_ds_jdbc_registry_client_heartbeat)

   • 记录活跃客户端的心跳信息
   • 服务端会定期检查，超时未更新的客户端记录将被自动清理
   • 支持客户端自定义会话超时时间

2. 数据变更事件表(t_ds_jdbc_registry_data_change_event)

   • 完整记录所有数据变更事件(增删改)
   • 采用事件溯源(Event Sourcing)模式，确保不丢失任何变更
   • 自动清理机制(2小时后删除)防止数据膨胀

关键改进点

1. 会话超时支持

   • 客户端可配置独立的心跳间隔和会话超时时间
   • 服务端基于配置动态调整检测策略
   • 超时客户端自动下线，相关资源自动释放

2. 可靠事件通知

   • 每个数据变更生成独立事件记录
   • 订阅者基于事件ID确保不遗漏变更
   • 支持批量变更的高效通知

3. 调试友好性

   • 心跳数据与业务数据物理分离
   • 提供完整的事件追溯能力
   • 丰富的监控指标暴露

技术实现细节

心跳管理机制

服务端采用分层检测策略：

1. 高频检测(秒级)：快速发现新注册客户端
2. 低频检测(分钟级)：稳定期常规检测
3. 自适应调整：根据客户端数量动态优化检测频率

事件处理流程

1. 数据变更时原子性写入业务表和事件表
2. 服务端定期扫描新事件
3. 按订阅关系分发事件
4. 确认处理成功后标记事件状态

故障恢复设计

• 客户端断线重连后自动恢复订阅
• 服务端重启后重建内存状态
• 提供数据一致性校验工具

最佳实践建议

1. 配置调优

   • 生产环境建议心跳间隔设为30秒
   • 会话超时设为心跳间隔的3-5倍
   • 根据业务规模调整事件保留时间

2. 监控指标

   • 客户端在线数
   • 心跳延迟分布
   • 事件处理延迟
   • 存储空间使用率

3. 升级注意事项

   • 需要重建注册表结构
   • 建议在低峰期执行升级
   • 先升级服务端再升级客户端

总结

本次重构使Apache DolphinScheduler的JDBC注册中心具备了生产级可靠性，通过清晰的架构分层、完善的事件机制和灵活的配置能力，能够更好地支撑大规模分布式部署场景。新的设计也为未来扩展多注册中心支持奠定了基础。