SQLite作为文件型数据库存在并发访问限制，Jellyfin团队分享了其在使用SQLite时遇到的并发问题及解决方案。文章主要面向开发者，介绍了如何通过实现锁机制来解决SQLite的并发问题，并指出该方案可应用于其他EF Core项目。SQLite虽便于存储结构化数据，但需注意其单文件特性带来的访问限制。

SQLite并发机制及其应对策略

概述： SQLite作为一款强大的文件型数据库引擎，因其轻量级特性被广泛应用于各类应用程序中。Jellyfin媒体服务器多年来使用SQLite存储核心数据，但在实际运行中遇到了并发访问问题。本文由开发者JPVenson撰写，旨在分享解决方案。

核心问题： 1. SQLite的独占性本质要求同一时间只能有一个写入操作 2. 即使启用WAL（预写日志）模式，仍可能发生锁冲突 3. Jellyfin 10.11之前的版本存在任务调度缺陷，导致数据库承受数千个并发写入请求

解决方案框架（基于EF Core）： 1. 无锁模式（默认）： - 不进行任何同步控制 - 适用于99%的无冲突场景

2. 乐观锁：

   • 采用"尝试-重试"机制
   • 使用Polly库实现有限次数的自动重试
   • 性能开销较小但存在失败可能

3. 悲观锁：

   • 通过ReaderWriterLockSlim实现严格串行化
   • 允许无限并发读取，但只允许单一线程写入
   • 最稳定但性能最低

技术实现： - 利用EF Core的拦截器(Interceptors)机制 - 重写JellyfinDbContext的SaveChanges方法 - 对调用方完全透明，无需修改现有查询逻辑

未来展望： 计划开发智能锁模式，结合乐观锁和悲观锁的优势。初步测试显示两种模式都能有效解决问题，特别是为之前无法正常使用的用户提供了解决方案。

本文提出的解决方案采用即插即用设计，其他EF Core应用可直接复用相关代码模块。开发者JPVenson表示，这是目前首个全面处理各类SQLite锁冲突的完整解决方案。

以下是评论内容的总结：

1. SQLite事务模式与锁机制

   • 默认"deferred"模式可能导致SQLITEBUSY错误，建议对写操作使用"immediate"模式并设置busytimeout。
   • 引用："transactions by default start in 'deferred' mode... The fix is to set a busy_timeout" (评论1)
   • 引用："SQLite is a cracking database... let down by its awful defaults" (评论2)

2. 高并发改进与替代方案

   • 期待hctree项目带来高并发支持，部分用户建议考虑PostgreSQL。
   • 引用："When hctree becomes stable... it will be the only database I will be using" (评论3)
   • 引用："maybe they should have used postgres" (评论7)

3. 并行写入与内存管理问题

   • 多进程写入需谨慎处理，内存数据库在频繁插入/删除时可能出现内存泄漏。
   • 引用："Curious if anyone has strategies on how to perform parallel writes" (评论4)
   • 引用："memory usage slowly creeping up over hours/days" (评论9)

4. 技术误解与澄清

   • 部分评论指出原文对WAL机制和锁原理存在误解，强调SQLite通过fcntl()实现单写多读。
   • 引用："WAL does not contain modifications, it contains the full pages" (评论5)
   • 引用："sqlite does locking for you... don't have to do anything" (评论11)

5. 调试建议与问题排查

   • 批评部分解决方案缺乏根本问题分析，建议深入调试而非盲目规避。
   • 引用："the 'solutions' are just blind workarounds" (评论8)
   • 引用："It happens quite rarely... seems to be when we fidget in the menus" (评论10)

（注：所有评论均无评分信息，总结时保持观点平衡，关键引用保留中英文对照）