SolidQueue 悲观锁与心跳机制问题解析

在 Rails 的异步任务处理系统 SolidQueue 中，近期发现了一个与悲观锁和心跳机制相关的技术问题。本文将深入分析该问题的成因、影响范围以及解决方案。

问题现象

当 SolidQueue 运行一段时间后，系统会频繁抛出悲观锁错误，错误信息显示为："Locking a record with unpersisted changes is not supported"。该错误主要发生在心跳机制执行过程中，频率约为每分钟一次。

技术背景

SolidQueue 使用心跳机制来维持进程活性检测：

1. 每个工作进程会定期更新自己的 last_heartbeat_at 时间戳
2. 更新操作需要获取记录锁以确保数据一致性
3. 系统使用 ActiveRecord 的悲观锁机制实现并发控制

问题根源

经过分析，问题出现在以下环节：

1. 心跳任务尝试更新记录时，记录已存在未持久化的变更（last_heartbeat_at 字段）
2. ActiveRecord 的悲观锁机制不允许对带有未保存变更的记录加锁
3. 这种状态通常发生在心跳间隔较短且系统负载较高时

影响范围

该问题具有以下特征：

• 主要影响使用 SQLite 作为数据库后端的系统
• 问题在系统运行一段时间后才会显现
• 同时影响本地开发环境和生产环境
• 使用 Puma 插件部署时也会出现

解决方案

SolidQueue 团队已经通过以下方式修复该问题：

1. 在获取锁之前确保所有变更都已持久化
2. 优化心跳机制的事务处理流程
3. 增加对记录状态的预检查

最佳实践

对于使用 SolidQueue 的开发者，建议：

1. 保持 SolidQueue 版本更新
2. 生产环境建议使用 PostgreSQL 或 MySQL 而非 SQLite
3. 监控系统日志中的锁相关警告
4. 合理设置心跳间隔参数

总结

这个问题展示了分布式系统中活性检测机制与数据库锁机制的微妙交互。SolidQueue 的修复确保了系统在高负载下的稳定性，同时也提醒开发者需要深入理解框架的并发控制机制。通过这次问题的分析和解决，SolidQueue 的可靠性得到了进一步提升。