Dawarich项目中SQLite数据库锁问题的分析与解决方案

问题背景

在Dawarich项目0.27.2版本中，用户在使用反向地理编码功能时遇到了SQLite数据库锁定问题。具体表现为在执行ReverseGeocodingJob任务时，系统抛出ActiveRecord::StatementTimeout和SQLite3::BusyException异常，提示"database is locked"。

技术分析

SQLite并发限制

SQLite作为轻量级数据库，其并发处理能力存在固有局限性。当多个进程或线程同时尝试访问数据库时，SQLite采用文件级锁机制，这可能导致以下情况：

1. 写操作会锁定整个数据库文件
2. 读操作在写操作进行时会被阻塞
3. 高并发场景下容易出现锁竞争

问题根源

在Dawarich项目中，这个问题主要出现在以下场景：

1. 反向地理编码任务批量执行时
2. 使用SolidQueue作为后台任务队列时
3. 多个工作进程同时访问数据库时

特别是当反向地理编码服务响应缓慢或失败时，会导致任务重试，进一步加剧数据库锁竞争。

解决方案演进

项目团队针对此问题进行了多轮优化：

初步修复尝试

在0.27.3版本中，团队尝试通过调整SQLite配置和优化查询来缓解锁问题，但效果有限。

根本解决方案

在0.27.4 RC版本中，团队做出了架构调整：

1. 将SolidQueue的后端存储从SQLite迁移到PostgreSQL
2. PostgreSQL具有更完善的并发控制机制
3. 支持更高级别的事务隔离
4. 提供更好的读写并发性能

技术实现细节

PostgreSQL优势

相比SQLite，PostgreSQL在并发处理方面具有明显优势：

1. 行级锁定而非表级锁定
2. 多版本并发控制(MVCC)机制
3. 更精细的事务隔离级别控制
4. 更好的连接池管理

架构调整影响

这一变更带来的主要改进包括：

1. 后台任务处理不再阻塞主数据库操作
2. 系统整体吞吐量提升
3. 减少了任务失败率
4. 提高了系统稳定性

用户实践反馈

根据用户测试反馈：

1. 0.27.4 RC版本有效解决了数据库锁问题
2. 反向地理编码任务能够顺利执行
3. 系统启动时的稳定性得到改善
4. 即使在ARM64架构下也能正常工作

总结与建议

Dawarich项目通过将SolidQueue的后端存储从SQLite迁移到PostgreSQL，从根本上解决了高并发场景下的数据库锁问题。这一变更体现了：

1. 根据应用场景选择合适的数据库技术的重要性
2. 架构设计需要随着应用规模增长而演进
3. 对于需要高并发的后台任务处理，专业数据库系统往往能提供更好的性能

对于使用Dawarich项目的开发者，建议：

1. 及时升级到0.27.4或更高版本
2. 合理配置PostgreSQL连接池参数
3. 监控后台任务执行情况
4. 根据实际负载调整工作进程数量