ShedLock 中关于锁记录插入异常的错误日志优化

问题背景

在使用 ShedLock 进行分布式任务调度时，当多个节点同时尝试获取同一个任务的锁时，会出现锁记录插入冲突的情况。在 ShedLock 4.37.0 版本中，这种正常的并发控制场景会被记录为 ERROR 级别的日志，导致监控系统产生不必要的告警。

技术分析

ShedLock 的核心机制是通过数据库表来实现分布式锁。当任务执行时，它会尝试向数据库表中插入一条锁记录。如果插入失败（通常是因为同名的锁记录已存在），ShedLock 会捕获这个异常并尝试更新现有的锁记录。

在 Spring 6.0.3 版本中，数据库主键冲突异常（DuplicateKeyException）被包装为 DataIntegrityViolationException 抛出。由于这是一个通用数据完整性异常，ShedLock 无法准确识别这是预期的锁竞争场景还是真正的数据问题，因此将其记录为 ERROR 级别。

解决方案演进

1. 早期版本（如 4.37.0）：直接记录完整的异常堆栈，导致监控系统产生告警。

2. 改进方案：

   • 使用 useDbTime() 配置可以部分缓解问题，确保时间戳由数据库生成
   • 但在 Spring 6.0.3 环境下仍会产生错误日志

3. 最新版本（5.0.1+）：

   • 增加了对 Spring 6.x 异常处理的适配
   • 能够正确识别主键冲突异常
   • 将预期的锁竞争场景降级为 WARN 级别日志

最佳实践建议

1. 版本升级：建议升级到 ShedLock 5.0.1 或更高版本，以获得更好的异常处理机制。

2. 配置优化：

   @Bean
   public LockProvider lockProvider(DataSource dataSource) {
       return new JdbcTemplateLockProvider(dataSource)
           .useDbTime(); // 使用数据库时间而非应用服务器时间
   }
   

3. 日志监控调整：如果暂时无法升级，可以在日志配置中针对特定类（JdbcTemplateStorageAccessor）设置 WARN 级别，避免产生告警噪音。

技术原理深入

ShedLock 的锁获取过程实际上是一个乐观锁的实现：

1. 首先尝试插入新记录（INSERT）
2. 如果失败（主键冲突），则尝试更新现有记录（UPDATE）
3. 更新时检查锁是否已过期（lock_until < now）
4. 如果更新成功且影响行数>0，则获取锁成功

这种设计确保了在高并发场景下，只有一个节点能够成功获取锁，同时避免了传统悲观锁的性能问题。

总结

分布式锁实现中的竞争条件是正常现象而非错误。ShedLock 在最新版本中已经优化了相关日志级别，使系统监控更加精准。对于仍在使用旧版本的用户，可以通过配置调整来减少误报，但长期解决方案仍是升级到最新版本。