好未来的课程管理系统需要存储大量课程信息、用户学习记录等数据。请设计分库分表策略，并说明如何处理数据一致性，比如课程信息更新时，多端同步的冲突。
答案
1) 【一句话结论】针对课程管理系统的数据存储需求，分库分表采用业务分库（按业务拆库）+ 维度分表（按ID范围/哈希/时间拆表），结合乐观锁（处理高并发冲突）与分布式事务（如Seata TCC，处理强一致性场景），平衡数据量与多端同步一致性，确保课程信息更新时冲突率低且强一致性需求满足。
2) 【原理/概念讲解】分库分表的核心是解决单库数据量过大、性能瓶颈。分库是将数据按业务或数据类型拆分到不同数据库（如课程表在“课程库”，用户学习记录在“学习库”），分表是将单表数据按维度（ID范围、哈希、时间）拆分到多个表（如课程表按ID范围分表为course_1（ID 1-1e6）、course_2（ID 1e6-2e6））。数据一致性挑战在于跨库事务的协调，比如课程信息更新时，多端同步可能冲突。乐观锁通过版本号解决冲突（更新前检查版本，冲突则重试），分布式事务（如两阶段提交、TCC）保证强一致性但需权衡性能。类比：就像把大超市分成多个小超市（分库），每个小超市再按商品类别分货架（分表），取课程信息更快，但需要统一库存系统（分布式事务）保证价格（课程信息）一致。跨库事务的阻塞风险：两阶段提交（2PC）可能导致长事务阻塞，影响系统性能，而TCC模式通过预检查、执行、确认/补偿步骤，预检查阶段避免阻塞，执行阶段短事务，减少阻塞时间。
3) 【对比与适用场景】
| 分表策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 按ID范围分表 | 按主键ID区间拆分（如1-1e6→表1） | 数据分布均匀，查询连续 | ID有序增长的业务（如课程ID、订单ID） | 可能导致数据倾斜（ID集中） |
| 按哈希分表 | 主键ID哈希取模拆分（如哈希%3） | 负载均衡，随机访问高效 | 随机访问的业务（如用户学习记录、日志） | 需考虑哈希碰撞，负载均衡 |
| 按时间分表 | 按时间维度拆分（如2023/2024） | 适合历史数据，查询按时间 | 历史数据统计、按时间线业务（如用户行为日志） | 需定期合并旧表，避免存储膨胀 |
4) 【示例】
- 课程表（
course）：字段course_id（主键）、course_name、version（版本号），按ID范围分表为course_1（ID 1-1e6）、course_2（ID 1e6-2e6）。 - 用户学习记录表（
user_study）：字段user_id、course_id、study_time，按用户ID哈希分表为user_study_1（user_id哈希%2=0）、user_study_2（%2=1）。 - 更新课程信息流程：
- 查询当前版本v：
SELECT course_id, version FROM course WHERE course_id = ? FOR UPDATE； - 若版本为v，执行
UPDATE course SET course_name = ?, version = v+1 WHERE course_id = ? AND version = v； - 若失败（版本不一致），重试。
- 查询当前版本v：
- 跨库事务（Seata TCC）：
- 预检查：检查课程状态是否允许更新（如课程是否在售）；
- 执行：更新课程表；
- 确认：提交事务；
- 补偿：若确认失败，回滚更新。
5) 【面试口播版答案】
面试官，针对好未来的课程管理系统，分库分表策略我会这样设计：首先分库，把课程表、用户表等按业务拆到不同数据库，比如课程库、用户库；分表的话，课程表按课程ID范围分表（如course_1到course_2），用户学习记录按用户ID哈希分表。这样既能分散数据量，又保证查询性能。数据一致性方面，课程信息更新时，多端同步冲突用乐观锁（版本号），更新前检查版本，冲突则重试。如果需要强一致性，比如核心课程信息更新，用分布式事务，比如Seata的TCC模式，通过预检查、执行、确认/补偿步骤保证一致性，但要注意性能。对于跨库事务，预检查阶段避免阻塞，减少长事务影响。
6) 【追问清单】
- 问：分库分表后，跨库查询如何优化？比如查询用户所有课程学习记录？
答：可通过预聚合表（如用户学习记录汇总表，按用户ID分表+course_id索引），或全局索引（如用户学习记录表按course_id分表+user_id索引），或分步查询（先查用户表，再查对应分表）。 - 问：分布式事务选型，比如两阶段提交和TCC，哪种更适合课程信息更新？
答：若业务对一致性要求高（如课程状态变更），用TCC（异步补偿，减少阻塞），若允许最终一致性，用乐观锁+补偿更高效。 - 问：分表策略如何避免数据倾斜？比如课程ID集中到某个表？
答：按ID范围分表时，定期重新分配ID范围（如通过数据库工具重新哈希），或用哈希分表（注意哈希碰撞处理）。 - 问：分表后如何处理跨库事务的阻塞问题？
答：用TCC模式（预检查、执行、确认/补偿），预检查阶段避免阻塞，执行阶段短事务，减少阻塞时间。
7) 【常见坑/雷区】
- 跨库事务阻塞：两阶段提交可能导致长事务阻塞，影响性能。
- 数据倾斜：按ID范围分表时，若ID集中（如新课程ID连续），导致某表负载过高。
- 预聚合表维护：定期合并旧表或更新预聚合表，避免数据不一致。
- 乐观锁适用场景：高并发场景下，若冲突率低，乐观锁高效；若冲突率高，需分布式事务。
- 分库分表后路由规则：需维护路由规则（如分库分表工具），避免数据迁移时路由错误。