Sidekiq中JSON科学计数法导致的负延迟问题分析

在Sidekiq Pro 5.5.8版本中，用户报告了一个关于负延迟的异常现象。经过深入分析，发现这与Ruby JSON库(v2.11.X)生成科学计数法格式的浮点数有关，特别是在处理时间戳时。

问题背景

当Sidekiq处理作业时，会记录作业的入队时间(enqueued_at)作为浮点数时间戳。在JSON序列化过程中，Ruby的JSON库(v2.11.3)有时会将这些时间戳转换为科学计数法表示，例如将1746830384.7678468表示为1.7468303847678468e+9。

问题根源

Sidekiq内部使用Lua脚本处理作业队列时，有一个正则表达式替换操作，目的是确保时间戳以标准浮点数格式表示。当遇到科学计数法表示的时间戳时，这个替换操作会错误地保留指数部分，导致最终计算出的延迟时间为负值。

具体来说，当JSON中包含类似"enqueued_at":1.7468303847678468e+9的科学计数法表示时，Lua脚本的错误处理会将其转换为1746830384.7678468e+9，这显然是一个无效的时间戳表示。

技术细节

1. JSON序列化行为变化：

   • 旧版本(如v2.10.2)通常生成标准浮点数表示
   • 新版本(v2.11.3)在某些情况下会使用科学计数法
   • JRuby版本的JSON库一直使用科学计数法

2. Sidekiq处理机制：

   • 使用Redis Lua脚本处理作业队列
   • 依赖正则表达式确保时间戳格式一致
   • 当前实现无法正确处理科学计数法

解决方案

1. 短期解决方案：

   • 回退到JSON v2.10.2版本
   • 或者等待JSON库更新(已合并相关修复但未发布)

2. 长期解决方案：

   • 升级到Sidekiq 8，该版本已改用整数时间戳而非浮点数
   • 修改Sidekiq的Lua脚本以支持科学计数法格式

最佳实践建议

1. 对于时间戳这类关键数据，建议使用整数而非浮点数表示
2. 在JSON序列化/反序列化场景中，应对浮点数的不同表示格式做好兼容处理
3. 考虑升级到Sidekiq 8以彻底避免此类问题

总结

这个问题揭示了在分布式系统中数据序列化格式一致性的重要性。虽然JSON规范允许科学计数法表示浮点数，但在实际系统实现中，特别是在涉及跨语言处理时，保持一致的格式表示对于系统稳定性至关重要。Sidekiq团队在v8版本中改用整数时间戳的决定，正是为了避免这类浮点数表示带来的潜在问题。