前端数据同步冲突解决：IndexedDB 乐观锁实现

本文链接：https://blog.csdn.net/2501_91474102/article/details/148425653

前端数据同步冲突解决：IndexedDB 乐观锁实现

关键词：前端数据同步、IndexedDB、乐观锁、冲突解决、离线存储

摘要：在离线优先的前端应用中（如笔记软件、协同文档），用户可能在无网络时修改同一数据，恢复网络后同步会引发“数据打架”。本文将用“社区共享账本”的故事类比，从0到1讲解如何用 IndexedDB 的“乐观锁”解决这类冲突。你将学会：IndexedDB 存储原理、乐观锁核心逻辑、实战代码实现，以及如何应对真实业务中的冲突场景。

背景介绍

目的和范围

本文聚焦“前端离线数据同步时的冲突问题”，以 IndexedDB（浏览器内置的大容量存储引擎）为基础，讲解“乐观锁”这一经典冲突解决策略的实现方法。内容覆盖原理讲解、代码实战、场景扩展，适合需要开发离线应用（如在线文档、待办清单）的前端开发者。

预期读者

有基础 JavaScript 能力的前端开发者
接触过 IndexedDB 但未深入的技术人员
正在开发离线优先应用，遇到数据同步冲突的项目成员

文档结构概述

本文从生活案例引出问题→解释核心概念→拆解乐观锁原理→提供完整代码实战→总结应用场景。你可以像“拆快递”一样，逐层揭开技术细节。

术语表

核心术语定义

IndexedDB：浏览器提供的“大仓库”，支持存储结构化数据（如对象、数组），适合需要离线存储大量数据的场景（类似手机里的“本地相册”）。
乐观锁：一种“先假设无冲突”的冲突检测策略（类似图书馆的“预约借书”：先记录书的状态，还书时检查是否被别人改过）。
数据同步冲突：两个或多个用户（或同一用户的不同设备）同时修改同一数据，导致合并时“不知道该保留哪个版本”的问题（比如两人同时修改同一段文档的同一句话）。

核心概念与联系

故事引入：社区共享账本的“打架”事件

老张家的社区有个共享账本，记录每家的“爱心菜”捐赠量。最近大家爱上了离线记录——出门买菜前先在手机上记一笔（无网络时数据存本地），回家连网后同步到共享账本。

但问题来了：上周，王阿姨和李叔叔都离线修改了“3单元201室”的捐赠量（王阿姨加了2斤白菜，李叔叔加了3斤萝卜）。同步时，两人的修改都想覆盖对方，账本直接“罢工”了！

社区管理员小明想了个办法：给每条记录加一个“版本号”（类似“第1版”“第2版”）。每次修改前，先看当前版本号是多少；提交时，如果版本号和修改前一致（说明没人改过），就更新并把版本号+1；如果不一致（说明被别人改了），就提示“冲突啦，需要手动选”。这就是“乐观锁”的思路！

核心概念解释（像给小学生讲故事）

核心概念一：IndexedDB——浏览器里的“大仓库”

IndexedDB 是浏览器给我们的“私人仓库”，可以存大量数据（比 localStorage 大得多，甚至能存几GB）。它的结构像“多层抽屉”：

数据库（Database）：整个大仓库（比如“社区账本库”）。
对象存储（Object Store）：仓库里的抽屉（比如“捐赠记录表”“住户信息表”）。
记录（Record）：抽屉里的具体物品（比如一条捐赠记录：{ 住户: ‘3单元201’, 数量: 5, 版本: 1 }）。

核心概念二：乐观锁——先假设“没冲突”的聪明策略

乐观锁就像你去图书馆借书：

你看到某本书在“第1版”（记录当前版本号）。
你借走书，修改了内容（比如在笔记里加了两页）。
还书时，检查书的版本号还是不是“第1版”：
- 如果是（没人改过），你就把书更新成“第2版”（提交成功）。
- 如果不是（有人改过），说明“冲突”了，需要你和对方商量保留哪个版本（冲突解决）。

核心概念三：数据同步冲突——离线修改的“打架现场”

离线应用中，用户可能在没网时修改同一数据（比如两个手机都改了同一条待办）。当恢复网络同步时，两个修改都想覆盖对方，就像两个小朋友同时抢一个玩具——必须有人“让步”或“商量”。

核心概念之间的关系（用小学生能理解的比喻）

IndexedDB 和乐观锁：IndexedDB 是“仓库”，乐观锁是“仓库的保安”。保安（乐观锁）用“版本号”检查货物（数据）是否被其他人动过，确保仓库（存储）里的数据不会乱。
乐观锁和数据同步冲突：乐观锁是“调解员”，专门解决数据同步时的“打架问题”。它通过版本号判断是否有人先改了数据，避免直接覆盖导致的错误。
IndexedDB 和数据同步冲突：IndexedDB 是“冲突的现场”——因为离线时数据存在这里，恢复网络后需要从这里取数据去同步，所以冲突就发生在数据从“仓库”同步到服务器的过程中。

核心概念原理和架构的文本示意图

用户A离线修改数据 → 存入 IndexedDB（带版本号v1）  
用户B离线修改同一数据 → 存入 IndexedDB（带版本号v1）  
恢复网络后，用户A尝试同步：  
   检查服务器中该数据的版本号是否为v1 → 是 → 提交修改，版本号变为v2  
用户B尝试同步：  
   检查服务器中该数据的版本号 → 已变为v2（≠v1）→ 冲突！提示用户处理

Mermaid 流程图

graph TD
    A[用户离线修改数据] --> B[存入IndexedDB（带当前版本号vN）]
    B --> C[恢复网络，尝试同步]
    C --> D[从IndexedDB读取数据（版本号vN）]
    D --> E[检查服务器/其他设备中该数据的当前版本号]
    E -->|版本号 == vN| F[提交修改，更新版本号为vN+1]
    E -->|版本号 != vN| G[触发冲突解决（如提示用户选择）]

核心算法原理 & 具体操作步骤

乐观锁的核心是“版本号校验”，步骤如下：

1. 存储数据时添加版本号

每条数据必须包含一个“版本号”字段（如 version），初始值为1（或0）。例如：

{ 
  id: '3单元201',       // 数据唯一标识（主键）
  amount: 5,            // 捐赠数量
  version: 1            // 版本号（关键！）
}

2. 修改数据前读取当前版本号

用户修改数据时，先从 IndexedDB 中读取该数据的当前版本号（比如 version: 1）。

3. 提交修改时校验版本号

提交修改（同步到服务器或本地存储）时，检查数据库中的版本号是否还是之前读取的版本号：

如果是（无冲突）：允许修改，并将版本号+1（version: 2）。
如果否（有冲突）：拒绝修改，提示用户处理冲突。

关键代码逻辑（JavaScript）

// 假设我们有一个函数 updateData，用于更新 IndexedDB 中的数据
async function updateData(dataToUpdate) {
  // 步骤1：从 IndexedDB 中读取当前数据的版本号
  const currentData = await getFromIndexedDB(dataToUpdate.id); // 自定义读取函数
  const currentVersion = currentData.version;

  // 步骤2：检查当前版本号是否与用户修改时的版本号一致
  if (dataToUpdate.version !== currentVersion) {
    throw new Error('冲突：数据已被其他操作修改！');
  }

  // 步骤3：无冲突，更新数据并递增版本号
  const newData = { ...dataToUpdate, version: currentVersion + 1 };
  await saveToIndexedDB(newData); // 自定义保存函数
  return newData;
}

数学模型和公式 & 详细讲解 & 举例说明

数学模型

设数据对象为 D = { id, ...其他字段, version }，其中 version 是整数。

当用户尝试修改 D 时，需满足以下条件才能提交成功：
$\text{当前数据库中的 } D_{db}.version = \text{用户修改前读取的 } D_{old}.version$

提交成功后，新版本号为：
$D_{new}.version = D_{old}.version + 1$

举例说明

假设初始数据：
$D_1 = \{ id: 'a1', amount: 5, version: 1 \}$

用户A读取到 D_1，修改 amount 为7，准备提交：

检查数据库中 D_1 的 version 是否为1 → 是。
提交成功，数据变为：
$D_2 = \{ id: 'a1', amount: 7, version: 2 \}$

用户B之前也读取了 D_1（version:1），修改 amount 为9，准备提交：

检查数据库中 D_1 的 version 现在是2（≠1）→ 冲突！拒绝提交。

项目实战：代码实际案例和详细解释说明

我们以“离线笔记应用”为例，演示如何用 IndexedDB + 乐观锁实现冲突解决。

开发环境搭建

浏览器：Chrome（或其他支持 IndexedDB 的现代浏览器）
工具：VS Code（或任意代码编辑器）
依赖：无需额外安装（IndexedDB 是浏览器原生API）

源代码详细实现和代码解读

步骤1：初始化 IndexedDB 数据库

创建一个名为 NoteDB 的数据库，包含一个 notes 对象存储（用于存笔记），主键为 id，并包含 version 字段。

// 初始化 IndexedDB
function initDB() {
  return new Promise((resolve, reject) => {
    const request = window.indexedDB.open('NoteDB', 1); // 数据库名，版本号（首次为1）

    // 数据库需要升级（首次创建或版本号变化时触发）
    request.onupgradeneeded = (event) => {
      const db = event.target.result;
      // 创建 notes 对象存储（类似“表”），主键为 id
      if (!db.objectStoreNames.contains('notes')) {
        const store = db.createObjectStore('notes', { keyPath: 'id' });
        // 为 version 字段创建索引（方便快速查询版本号）
        store.createIndex('version', 'version', { unique: false });
      }
    };

    request.onsuccess = (event) => {
      const db = event.target.result;
      resolve(db);
    };

    request.onerror = (event) => {
      reject('数据库打开失败：' + event.target.error);
    };
  });
}

步骤2：实现“带乐观锁”的更新函数

用户修改笔记时，先读取当前版本号，提交时校验版本号是否一致。

// 更新笔记（带乐观锁）
async function updateNoteWithOptimisticLock(note) {
  const db = await initDB(); // 获取数据库实例

  return new Promise((resolve, reject) => {
    // 开启事务（模式：readwrite，允许读写）
    const transaction = db.transaction('notes', 'readwrite');
    const store = transaction.objectStore('notes');

    // 步骤1：读取当前笔记的版本号
    const getRequest = store.get(note.id);
    getRequest.onsuccess = (event) => {
      const currentNote = event.target.result;
      if (!currentNote) {
        reject('笔记不存在！');
        return;
      }

      // 步骤2：检查版本号是否一致
      if (note.version !== currentNote.version) {
        reject(`冲突：当前版本为${currentNote.version}，你的版本为${note.version}`);
        return;
      }

      // 步骤3：无冲突，更新数据并递增版本号
      const newNote = { ...note, version: currentNote.version + 1 };
      const putRequest = store.put(newNote);
      putRequest.onsuccess = () => resolve(newNote);
      putRequest.onerror = (e) => reject('更新失败：' + e.target.error);
    };

    getRequest.onerror = (e) => reject('读取失败：' + e.target.error);
  });
}

步骤3：测试冲突场景

模拟两个用户同时修改同一笔记：

// 初始笔记数据
const initialNote = { id: 'note1', content: '初始内容', version: 1 };

// 用户A修改内容为“用户A的修改”，并尝试提交
const userANote = { ...initialNote, content: '用户A的修改' };
updateNoteWithOptimisticLock(userANote)
  .then((res) => console.log('用户A提交成功：', res)) // 输出：version:2
  .catch((err) => console.error('用户A提交失败：', err));

// 用户B同时修改内容为“用户B的修改”（假设用户B也读取了version:1）
const userBNote = { ...initialNote, content: '用户B的修改' };
updateNoteWithOptimisticLock(userBNote)
  .then((res) => console.log('用户B提交成功：', res))
  .catch((err) => console.error('用户B提交失败：', err)); // 输出：冲突！

代码解读与分析

事务的作用：transaction('notes', 'readwrite') 确保读取和更新操作在一个原子操作中完成，避免中途有其他操作修改数据（比如用户A读取后，用户B的修改不会在用户A提交前生效）。
版本号校验：通过比较 note.version 和 currentNote.version，确保只有未被修改的数据才能提交。
错误处理：冲突时抛出明确的错误信息，方便前端提示用户（如弹出“数据已被修改，是否覆盖？”的对话框）。

实际应用场景

1. 离线笔记/待办应用

用户可能在地铁（无网络）时修改同一条笔记，恢复网络后同步到服务器。乐观锁可避免“后提交的修改覆盖先提交的”的问题。

2. 协同编辑工具（如在线文档）

多人同时编辑同一段文字时，前端可通过乐观锁检测冲突，提示用户选择保留哪一版或自动合并（需结合更复杂的算法）。

3. 移动应用本地缓存同步

App 在无网络时修改本地数据（如购物车商品数量），联网后同步到服务器。乐观锁可确保手机和服务器的数据一致性。

工具和资源推荐

Dexie.js：简化 IndexedDB 操作的轻量级库（官网：https://dexie.org/），可将原生复杂的回调代码转为更简洁的 Promise 风格。
示例代码（用 Dexie.js 重写更新函数）：

import Dexie from 'dexie';
const db = new Dexie('NoteDB');
db.version(1).stores({ notes: 'id, version, content' });

async function updateNoteWithOptimisticLock(note) {
  return db.transaction('rw', db.notes, async () => {
    const currentNote = await db.notes.get(note.id);
    if (note.version !== currentNote.version) {
      throw new Error('冲突！');
    }
    return db.notes.put({ ...note, version: currentNote.version + 1 });
  });
}

MDN IndexedDB 文档：官方权威指南（https://developer.mozilla.org/zh-CN/docs/Web/API/IndexedDB_API）。
浏览器兼容性检查：使用 Can I Use（https://caniuse.com/indexeddb）查看各浏览器支持情况（现代浏览器基本全覆盖）。