设计一个用户学习进度同步的数据库表结构，并说明如何处理并发写入（如多个设备同时更新同一进度），保证数据一致性。

好未来IOS难度：中等

答案

1) 【一句话结论】：采用带乐观锁（版本号）的数据库表结构，通过事务和版本号校验解决并发写入冲突，结合事务隔离级别优化性能，保证数据一致性。

2) 【原理/概念讲解】：面试官问的是多个设备同时更新用户进度时，如何避免覆盖。核心是并发控制。

乐观锁（Optimistic Locking）思路：每次更新前检查数据版本是否被修改，若未修改则更新，否则回滚。
类比：图书馆借书，版本号像“借书证”，若借书证被他人更新（即版本号变化），则当前借书失败，需重新借。这样避免锁竞争，减少阻塞。

3) 【对比与适用场景】：

方式	定义	特性	使用场景	注意点
乐观锁	更新前检查数据版本是否匹配，不匹配则失败	无锁竞争，失败后重试	读多写少（如用户进度更新，写操作少）	需版本字段，失败率低时高效
悲观锁	更新前加锁，独占资源	阻塞其他写入，保证原子性	写多读少（如库存扣减）	可能导致性能瓶颈，锁竞争严重

4) 【示例】：

表结构设计：

CREATE TABLE user_progress (
    user_id INT PRIMARY KEY,
    course_id INT,
    current_chapter INT,
    version INT DEFAULT 1,  -- 版本号，初始1
    update_time TIMESTAMP
);

更新逻辑伪代码（乐观锁）：

-- 更新进度，检查版本号
UPDATE user_progress 
SET current_chapter = ?, version = version + 1, update_time = NOW()
WHERE user_id = ? AND course_id = ? AND version = ?
RETURNING version;  -- 返回更新后的版本号

若返回版本号等于传入版本号，更新成功；否则失败，需重试。

5) 【面试口播版答案】：
“面试官您好，针对用户学习进度同步的数据库表结构设计，核心思路是构建带乐观锁的表结构，保证并发写入的一致性。首先，表结构设计：创建user_progress表，包含user_id（用户标识）、course_id（课程标识）、current_chapter（当前章节）、version（版本号，初始1）、update_time（更新时间）。版本号用于检测数据是否被其他设备修改。处理并发时，采用乐观锁策略：每次更新时，先检查version是否匹配，若匹配则更新并递增版本号，否则失败并提示用户。这样避免锁竞争，减少阻塞。具体来说，更新逻辑是：先查询当前版本号，然后执行更新，若更新行数为0（即版本号已变化），则重试。这种方式在写操作较少的场景下高效，同时保证数据一致性。”

6) 【追问清单】：

问：版本号如何生成？是否需要全局唯一？
回答：版本号用数据库自增字段（如AUTO_INCREMENT），每次更新自动+1，确保唯一性。
问：乐观锁失败后如何处理？是否需要重试？
回答：失败后重试3次（合理次数），若仍失败则提示用户手动同步。
问：分布式环境下，如何保证版本号一致性？
回答：用分布式事务或消息队列（如Kafka）同步版本号，确保所有节点版本一致。
问：事务隔离级别如何选择？比如RC或RR？
回答：读多写少用RC（读未提交），减少锁开销；写多时用RR（读已提交）。
问：是否考虑缓存？如何处理缓存与数据库同步？
回答：缓存（如Redis）存储进度，更新时先数据库，再缓存，若缓存失效则从数据库读取。

7) 【常见坑/雷区】：

坑1：版本号递增失败（如自增字段被占用），导致冲突检测失效。
雷区：确保版本号字段自增且唯一，避免并发冲突。
坑2：乐观锁失败重试次数过多，导致性能问题。
雷区：设置合理重试次数（如3次），超限则放弃。
坑3：忽略事务隔离级别，导致脏读/不可重复读。
雷区：根据场景选隔离级别，读多写少用RC，避免锁过多。
坑4：分布式环境下版本号同步问题。
雷区：用分布式锁或消息队列同步版本号。
坑5：未考虑幂等性，多次更新导致错误。
雷区：检查版本号，失败则不执行，保证幂等。