多用户协同操作网页通讯录的并发冲突处理方案问询

一、经典并发控制方案 #

• 乐观锁（Optimistic Locking）

  • 实现逻辑：给每条通讯录记录添加version版本号或last_modified时间戳字段。用户读取记录时同步获取版本信息，提交修改时对比本地版本与数据库当前版本，仅当两者一致时允许更新，否则提示用户数据已过期，需重新读取后再编辑。
  • 数据库操作示例：

    UPDATE contacts 
    SET phone = '138xxxx1234', version = version + 1 
    WHERE id = 123 AND version = 4;
    

  • 适用场景：冲突频率较低的场景，避免悲观锁带来的性能损耗。

• 悲观锁（Pessimistic Locking）

  • 实现逻辑：用户进入编辑流程时，立即对目标记录加排他锁，数据库层面可通过SELECT ... FOR UPDATE语句实现，其他用户读取或编辑该记录时会被阻塞，直到锁被释放。
  • 数据库操作示例：

    SELECT * FROM contacts WHERE id = 123 FOR UPDATE;
    

  • 适用场景：冲突频率较高的场景，确保操作强一致性，但会降低系统并发能力。

• 关键字段对比校验

  • 实现逻辑：用户提交修改时，将读取记录时保存的关键字段（如原电话号码、姓名）与数据库当前值对比，若不一致则拒绝更新，提示用户重新操作。
  • 缺点：字段较多时对比逻辑繁琐，易出现非关键字段修改触发冲突的误判。

二、新型并发控制思路 #

• 操作日志与冲突合并（Operational Transformation, OT）

  • 核心逻辑：不依赖锁机制，而是记录用户的每一步操作（如“修改电话号码从A到B”“更新邮箱为C”），当多个用户操作同一记录时，系统自动合并无冲突操作；对同一字段的冲突修改（如两人同时改电话号码），则提示用户选择保留版本。
  • 适用场景：支持实时协作的通讯录系统，类似协作文档的处理模式，提升用户体验。

• CRDT（Conflict-free Replicated Data Types）

  • 核心逻辑：设计特殊的可合并数据结构，让多用户端的修改操作无需协调即可自动达成一致。例如将通讯录的每个字段设计为CRDT类型，用户本地编辑后同步到服务器，服务器自动合并所有修改。
  • 优势：无需锁机制，天然适配分布式多端同步场景。

• 实时推送与前端主动感知

  • 实现逻辑：通过WebSocket或Server-Sent Events（SSE）建立前端与服务器的实时连接，当某条记录被修改时，服务器主动推送更新通知给所有正在查看/编辑该记录的用户，前端立即刷新界面并提示“记录已被修改，请刷新后操作”。
  • 搭配方案：结合乐观锁使用，前端实时感知+后端最终校验，双重保障数据一致性。

三、辅助优化策略 #

• 会话级编辑标记：用户进入编辑页面时，服务器标记该记录为“编辑中”，其他用户进入编辑流程时收到友好提示，但不强制阻塞；若用户长时间无操作（超时），自动释放标记。
• 增量更新：允许用户仅提交修改的字段，而非整个记录，缩小冲突范围，同时降低数据传输量。
• 版本回溯机制：保存记录的历史版本，冲突发生时，允许用户查看历史修改记录，手动合并或恢复到指定版本。

内容的提问来源于stack exchange，提问作者maximiliansport