Sidekiq中负延迟问题的根源分析与解决方案

问题背景

在Sidekiq Pro v5.5.8与Ruby 3.2.0、Rails 7.2.2.1的组合环境中，用户报告出现了负延迟的异常现象。经过深入分析，发现这与JSON gem(v2.11.X)生成浮点数时使用科学计数法有关，进而影响了Sidekiq对任务执行时间的计算。

技术细节解析

当JSON gem(v2.11.3)序列化包含时间戳的哈希时，有时会生成科学计数法表示：

JSON.generate({ foo: Time.now.to_f })
# 可能输出："{\"foo\":1.7468303847678468e+9}"

而早期版本(如v2.10.2)则始终生成标准浮点数表示。这种变化导致Sidekiq内部用于处理延迟任务的Lua脚本中的正则表达式替换出现问题。

根本原因

Sidekiq使用Lua脚本来处理延迟任务队列，其中包含一个针对浮点数时间戳的特殊处理逻辑。当JSON开始输出科学计数法时，原有的字符串替换逻辑会错误地处理这些值，最终导致计算出负的延迟时间。

具体表现为：

1. 原始JSON："{"enqueued_at":1.7468303847678468e+9}"
2. Lua脚本错误替换后："{"enqueued_at":1746830384.12489e+9}"
3. 最终解析出错误的时间值

解决方案

短期解决方案

1. 锁定JSON gem版本至v2.10.2或更低版本，避免科学计数法表示
2. 修改Sidekiq的Lua脚本，使其能够正确处理科学计数法表示的时间戳

长期解决方案

升级至Sidekiq 8.x版本，该版本已将所有时间戳改为整数表示，从根本上避免了浮点数序列化带来的问题。这是更推荐的解决方案，因为：

1. 整数表示更精确，避免了浮点数精度问题
2. 不再受JSON序列化格式变化的影响
3. 统一了不同Ruby实现(JRuby等)的行为

技术启示

这个案例展示了几个重要的技术考量：

1. 时间表示的选择：在分布式系统中，使用整数时间戳通常比浮点数更可靠
2. 数据序列化的兼容性：依赖特定格式的序列化输出存在风险
3. 跨版本兼容性：依赖库的升级可能引入微妙的行为变化

对于开发者而言，这个案例提醒我们在处理时间相关逻辑时应当特别注意数据表示的一致性，特别是在跨组件、跨版本的复杂系统中。