基础 17 · 并发、锁与事务

并发就是「多件事同时发生」。事务和锁，是保证它们不打架的手段。

「同时」这个词在服务器上有两层意思，你要分清：①真同时（多个 CPU 核同时在跑，几纳秒级交错）；②假同时（单个 CPU 在多个任务间快速切换，每个任务以为自己从头跑到尾、中间没人打断）。

这是本页最重要的一段。先讲没有 WAL 是什么样，再讲有了 WAL 是什么样。

// 开WAL 只需要一行，门店系统 v2.5.0 里就是这么写的
db.pragma('journal_mode = WAL');
// 配套的三个建议参数
db.pragma('busy_timeout = 5000');   // 拿不到锁时最多等 5 秒，别立刻报 BUSY
db.pragma('synchronous  = NORMAL');  // 配合 WAL：断电可能丢最后几笔，换来的写入提速
db.pragma('foreign_keys = ON');      // 外键约束默认是关的，必须手动开

成因一句话：AI 生成的代码把「读-改-写」这三步当成了一个原子操作，但这三步之间是可以被别人插进来的。

一个能看懂的例子：少卖了一件

库存 10 件，两个经销商门店同时各要 1 件。正确结果应该是 8。

// ✗ 有 bug 的写法（AI 常生成这样）：读-改-写三步各自独立
app.post('/api/orders', async (req, res) => {
  const row = db.prepare('SELECT qty FROM inventory WHERE sku = ?').get(sku);

  if (row.qty >= 1) {
    db.prepare('UPDATE inventory SET qty = ? WHERE sku = ?')
         .run(row.qty - 1, sku);            // ← 危险：这里的值是「读的时候」的旧值
  }
  res.json({ ok: true });
});

// 时间线（两个请求交错执行）
// t1请求A：SELECT → 读到 qty = 10
// t2  请求B：SELECT → 也读到 qty = 10        ← B 读到的是旧快照
// t3  请求A：UPDATE SET qty = 9 → 库里现在是 9
// t4  请求B：UPDATE SET qty = 9 → 库里还是 9！B 手里的旧值是 10，减1还是 9
// 结果：卖出去 2 件，库存只减了 1 → 少卖了一件

三种解法

// 解法 1a：数据库事务（最标准）
const wrap = db.transaction(() => {
  const row = db.prepare('SELECT qty FROM inventory WHERE sku = ?').get(sku);
  if (row.qty < 1) throw new Error('库存不足');
  db.prepare('UPDATE inventory SET qty = ? WHERE sku = ?').run(row.qty - 1, sku);
});
wrap();   // better-sqlite3 的 transaction() 自动 BEGIN/COMMIT，出错自动 ROLLBACK

-- ✓ 正确：让数据库自己减，且加条件防超卖
UPDATE inventory
SET qty = qty - 1,
    updated_at = ?,
WHERE sku = ? AND qty >= 1;
-- 影响行数 = 1 → 成功扣减
-- 影响行数 = 0 → 库存不足，直接拒绝（连超卖的漏洞都没有）

// 读的时候把 version 一起返回给前端
SELECT qty, version FROM inventory WHERE sku = ?;    -- 假设 version = 7

// 写的时候带上「我看到的版本是 7」
UPDATE inventory
SET qty = 9, version = version + 1
WHERE sku = ? AND version = 7;
-- 影响行数 = 0 → 版本已经不是 7 了 → 有人改过 → 提示「库存已变动，请刷新」

原则只有一句：一次业务操作 = 一个事务。

「业务操作」是从用户角度看是一件事的那个粒度。「创建一张订单」是一件事：写订单主表 + 写明细行 + 锁库存。这三步必须在同一个事务里，因为它们要么一起成功要么一起不算。但「导入 5000 张订单」不是一件事，它是 5000 件事。

// 逐条事务 + 失败收集（这是正确的样子）
const failed = [];
for (const row of rows) {
  const runOne = db.transaction(() => {
    const id = insertOrder(row);
    for (const line of row.lines) insertOrderLine(id, line);   // 同一事务内
  });
  try {
    runOne();
  } catch (e) {
    failed.push({ row, error: String(e) });     // 记下来，不中断整批
  }
}
// 导出 failed 成 CSV，人工/脚本重试

WAL 只解决「读和写互相阻塞」，不解决「两个写同时来」。WAL 模式下同一时刻仍然只有一个写者，第二个写依然会撞 SQLITE_BUSY。把 WAL 当成并发问题的终点，是最常见的误解。

见第 04 节。这是你的真实事故：AI 生成的代码把 SELECT → 判断 → UPDATE 当成一步，实际三步之间会被插入。症状是数据悄悄少一点，不报错。防范动作：写代码时凡是「先查出来再算再写回去」，都要停下来想一句「这两步之间别人插进来会怎样」。能改成一条 SQL 就改。

「套个大事务不就安全了」——安全是真的，但代价是整库被锁住。WAL 下写锁是库级的，大事务一跑，页面上所有人的写操作全排队，表现为「系统卡了」。正确做法是「小事务 + 失败单独处理 + 可重跑」。

两个错叠加就出大事故：①「SQLite 是单线程的」——单个连接内部确实是串行的，但你的进程不止一个连接（请求之间各自开连接），而且 pm2 多进程各开各的；②「我只有一个用户」——你只有 4 家经销商门店，但并发不是按人数算的，是按「同一时刻有几个请求在处理中」算的。结果是 WAL 下多进程写会直接报 SQLITE_BUSY。

WAL 模式下最新数据可能还在 xxx.db-wal 里没合并回 xxx.db。只拷主文件会丢掉最近的数据。要么三个文件一起拷，要么用 SQLite 自带的 .backup 命令（它会正确处理 WAL）。只拷 .db 还要小心：拷的过程中如果有写入发生，拷出来的主文件本身可能是不一致的。

SQLite 为了兼容老应用，外键约束默认不开启。不开启的话，「订单明细指向一个不存在的订单」这种脏数据可以被正常写进去——数据库不拦，脏数据一路流到业务层才炸。必须显式开：db.pragma('foreign_keys = ON')。

• ✓我知道并发不等于多核，单核一样有并发 bug（任务切换就会插进来）
• ✓我能用一句话说清事务、锁、隔离级别、WAL 各是什么
• ✓我知道没有 WAL 时读写互相阻塞，有 WAL 时读的是旧快照但不卡
• ✓我知道 WAL 的代价：只能一个写者、会生成 -wal、备份必须连它一起拷
• ✓我知道 WAL 模式下不能把库放网络共享盘（依赖本机文件锁）
• ✓我能讲出丢更新的完整时间线（两个请求都读到 10，各自减1，都写回 9）
• ✓我知道三种解法：加锁 / UPDATE ... SET qty = qty - 1（推荐） / 乐观锁版本号
• ✓我知道为什么 collections 的 JSON blob 会让并发串行（整行重写 → 冲突面积从1 个字段变整行）
• ✓我知道你项目里 qty/locked 双字段 + inventory_movement 流水 = 业务层锁 + 账本
• ✓我能说出四种并发场景，特别是批量脚本 + 页面同时操作
• ✓我知道pm2 多进程也是并发，LumenX 是 3 个进程
• ✓我知道事务边界 = 一次业务操作，并且能给出「大事务 vs 每条一事务」的对比
• ✓我知道大事务会锁整库（WAL 的写锁是库级），迁移要拆批 + sleep
• ✓我知道事务里不能放 HTTP 请求、等用户确认、大文件操作
• ✓知道要显式 pragma('foreign_keys = ON')，因为 SQLite 外键默认关