东南大学有多个校区，博士生的课程排课、成绩录入等数据需要跨校区同步。请设计一个方案，确保数据一致性（如排课冲突、成绩录入错误），并考虑系统的高可用性（如故障转移）。

1) 【一句话结论】

采用TiDB分布式数据库（兼容MySQL生态，支持强一致性分布式事务）结合Kafka消息队列，通过主从复制实现跨校区数据实时同步，并配置GTID复制与自动故障转移，确保数据一致性（如排课冲突检测、成绩录入同步）及系统高可用（故障转移秒级完成）。

2) 【原理/概念讲解】

老师口吻：要解决多校区数据同步，核心是分布式数据一致性与异步解耦。

• 分布式数据库（如TiDB）：采用分布式架构，主从复制实现数据实时同步，主库负责写操作，从库实时复制数据，保证核心数据（如成绩、排课）的一致性。TiDB兼容MySQL生态，便于与现有系统（如学工系统）集成。
• CDC（变更数据捕获）：通过MySQL binlog捕获数据变更，实时同步到从库，适用于对一致性要求高的业务（如成绩录入，避免冲突）。
• 消息队列（如Kafka）：解耦数据变更通知，当主校区数据变更时，通过消息队列向其他校区发送事件，消费者异步处理，减少主库压力。
  类比：比如学校跨校区图书馆借书，主库是“总借阅记录”，从库是“分馆借阅记录”，通过消息通知（如Kafka）同步借书记录，同时借书时事务保证数据一致，故障时从库接管。

3) 【对比与适用场景】

方式	定义	特性	使用场景	注意点
同步复制（MySQL GTID）	主库写后立即同步到从库	强一致性，延迟低（秒级），但主库写压力高	核心数据（如成绩录入，需实时检测冲突）	可能导致主库写性能下降，需优化索引
异步复制（MySQL binlog）	主库写后异步推从库	写性能高，延迟高（分钟级），需补偿	非实时同步（如排课通知，允许延迟）	需补偿机制（如重试、缓存）处理不一致
消息队列（Kafka）	生产者-消费者模型，持久化消息	解耦、高吞吐、持久化，支持幂等	跨系统数据变更通知（如排课数据变更）	需消费者ACK确认，避免消息丢失

（注：同步复制保证数据实时一致，异步复制牺牲部分实时性换取性能；消息队列用于解耦数据变更通知，避免系统耦合。）

4) 【示例】

伪代码展示成绩录入流程（含乐观锁与消息幂等）：

1. 用户在主校区提交成绩录入（课程ID、学生ID、分数）。  
2. 系统执行事务：  
   - 检查版本号（乐观锁）：SELECT version FROM grades WHERE course_id=... AND student_id=... FOR UPDATE；  
   - 若版本号匹配，执行INSERT/UPDATE，并更新版本号；  
   - 同时写入Kafka主题（grades_sync），消息包含数据变更（course_id, student_id, score）。  
3. Kafka生产者发送消息，其他校区消费者监听。  
4. 从校区消费者收到消息后，执行事务：  
   - 检查版本号（幂等处理）：若已存在，跳过；否则执行INSERT/UPDATE；  
   - 更新本地缓存（Redis）。  
5. 故障转移：主库故障时，从库通过GTID复制自动切换为主库，后续写入通过GTID同步，确保数据一致。  

5) 【面试口播版答案】

面试官您好，针对多校区数据同步与高可用问题，我的方案核心是**分布式数据库（TiDB）+消息队列（Kafka）**的组合：
首先，选择TiDB作为核心数据库，利用其主从复制实现跨校区数据实时同步，主库处理写操作，从库实时复制，确保排课冲突检测（如教室时间冲突）的准确性。其次，引入Kafka消息队列解耦数据变更通知，当主校区成绩录入变更时，通过消息队列向其他校区发送变更事件，其他校区消费者异步处理数据同步，避免主库写压力过高。同时，配置GTID复制实现自动故障转移，主库故障时从库自动切换为主库，通过心跳检测和秒级切换保证系统可用性。这样既能保证数据一致性（如成绩录入错误及时同步），又能提升系统高可用性。

6) 【追问清单】

• 问：如何处理数据冲突（如两个校区同时修改同一门课的排课信息）？
  答：通过TiDB的乐观锁（版本号校验），比较数据版本号，避免冲突；若冲突，回滚并提示用户重试。
• 问：系统故障转移的具体流程？
  答：主库检测到故障（如连接超时），从库通过GTID复制的心跳检测（如每秒一次）判断主库不可达，自动切换为新的主库，后续写入通过GTID同步，故障转移时间控制在1-2秒内。
• 问：对用户操作的影响？
  答：故障转移过程中，用户操作会自动路由到新的主库，由于从库实时同步，用户感知不到数据不一致，系统可用性保持99.9%以上。
• 问：如何平衡数据同步速度与系统响应？
  答：异步消息队列处理非实时同步数据（如排课通知），实时同步数据通过TiDB的同步复制，同时优化数据库索引（如按课程ID、时间索引），减少主库写压力。

7) 【常见坑/雷区】

• 忽略消息队列解耦：导致主库写性能下降，系统响应变慢（如成绩录入时主库卡顿）。
• 高可用方案不具体：只说主从切换，没提故障检测（如心跳）和切换流程，显得方案不落地。
• 数据冲突处理缺失：两个校区同时修改数据时，没版本控制或补偿机制，导致数据不一致。
• 没考虑延迟补偿：成绩录入时同步延迟可能导致用户看到旧数据，没说明延迟范围（如分钟级）和补偿策略（如重试、缓存）。
• 选型不结合现有系统：比如现有系统用传统MySQL，选TiDB时没说明兼容性测试（如数据迁移、API兼容），导致实施难度大。