解决Next.js与Docker中better-sqlite3数据库锁定的问题

在使用Next.js框架结合Docker容器部署应用时，开发者可能会遇到better-sqlite3数据库锁定的问题。这个问题表现为随机出现的"database is locked"或"SQLITE_BUSY"错误，特别是在构建过程中尤为明显。

问题根源分析

SQLite数据库设计上是单进程访问的数据库系统，当多个进程或线程同时尝试访问同一个数据库文件时，就会出现锁定问题。在Next.js的构建过程中，多个路由处理器可能同时尝试访问数据库，而better-sqlite3作为SQLite的Node.js绑定，继承了这一特性。

在Docker环境下，特别是使用WSL2的Windows系统上，这个问题可能更加复杂。Windows文件系统与Linux文件系统之间的差异可能导致SQLite的WAL(Write-Ahead Logging)模式出现数据丢失问题。

解决方案

1. 调整Next.js构建配置

通过限制Next.js构建时的线程数量，可以有效减少并发访问数据库的情况：

// next.config.js
module.exports = {
  experimental: {
    workerThreads: false,
    cpus: 1
  }
}

这个配置强制Next.js在构建时只使用单线程，避免了多线程同时访问数据库的问题。

2. 设置SQLite的busy_timeout参数

SQLite提供了busy_timeout参数，可以设置当数据库被锁定时等待的时间：

const db = new Database('mydb.sqlite');
db.pragma('busy_timeout = 30000'); // 设置30秒超时

这个设置让SQLite在遇到锁定时不是立即报错，而是等待一段时间再重试。

3. 避免在Windows/WSL2上使用WAL模式

在Windows/WSL2环境下，由于文件系统实现的差异，SQLite的WAL模式可能导致数据丢失。可以考虑：

1. 禁用WAL模式
2. 使用更稳定的日志模式
3. 考虑在Linux原生环境中运行生产服务

4. 实现数据库连接单例模式

确保整个应用中使用同一个数据库连接实例，避免多个连接同时操作数据库：

// db.js
let dbInstance = null;

export function getDatabase() {
  if (!dbInstance) {
    dbInstance = new Database('mydb.sqlite');
    // 其他初始化配置
  }
  return dbInstance;
}

最佳实践建议

1. 开发环境与生产环境分离：在开发环境中可以使用更宽松的配置，但生产环境应该严格限制并发访问。

2. 考虑使用专门的数据库服务：对于生产环境，SQLite可能不是最佳选择，可以考虑PostgreSQL或MySQL等更适合高并发的数据库系统。

3. 定期备份：无论使用何种解决方案，都应该实现定期备份机制，Litestream是一个不错的选择。

4. 监控与日志：实现完善的日志记录，当出现数据库锁定时能够快速定位问题源头。

通过以上方法，开发者可以有效解决Next.js与Docker环境下better-sqlite3的数据库锁定问题，构建更稳定的应用服务。