解释分布式事务在在线考试系统中的应用，比如学生提交成绩时，需要同时更新成绩表和用户答题记录。请说明如何保证事务的原子性，以及可能遇到的CAP问题（一致性、可用性、分区容错性），并举例说明如何权衡。

1) 【一句话结论】分布式事务通过两阶段提交（2PC）或Saga模式保证成绩表与答题记录的原子性，需根据业务优先级权衡一致性（如成绩立即可见）与可用性（如系统分区时允许部分操作延迟，通过补偿机制恢复）。

2) 【原理/概念讲解】分布式事务是指跨多个数据库/服务的操作，需保证原子性（要么全做，要么全不做）。在线考试中，学生提交成绩时，同时更新成绩表（记录分数）和答题记录（更新用户答题状态），原子性保障数据一致性。

CAP理论中，分布式系统在分区（网络故障导致服务不可达）时，一致性（所有副本数据一致）与可用性（服务正常响应）不可兼得，需根据业务优先级选择：

• 一致性：所有副本数据完全同步（如成绩立即可见）；
• 可用性：系统在分区时仍能响应请求（如部分用户操作延迟，但最终恢复）。

类比：分布式事务像多人同时记账，必须确保所有账目操作要么都完成，要么都撤销，否则账目混乱；CAP理论像分区的银行系统，若网络分区，要么所有分支的账户更新都成功（一致性），要么部分分支可用（但数据不一致）。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
两阶段提交（2PC）	领导者（协调者）控制所有参与者，先预提交，再提交	强一致性，协调者故障导致整个事务阻塞	需要强一致性（如金融交易）	协调者故障时系统无法提交事务，分区时性能差
Saga模式	分解为多个本地事务，每个事务有补偿操作（失败时撤销）	最终一致性，协调者故障不影响本地事务	需要最终一致性（如电商订单：下单、库存扣减、支付，任一失败补偿）	补偿事务可能失败，需重试机制，逻辑复杂

4) 【示例】（Saga模式示例，学生提交成绩）
步骤：

1. 更新成绩表（记录分数）；
2. 更新答题记录（状态=已提交）；
   若任一失败，触发补偿事务（回滚操作）。

伪代码：

def submit_score(student_id, score):
    # 1. 更新成绩表
    update_score_table(student_id, score)
    if error:
        rollback_score_table(student_id)  # 补偿：回滚成绩表
        return "失败"
    
    # 2. 更新答题记录
    update_answer_record(student_id, "已提交")
    if error:
        rollback_answer_record(student_id)  # 补偿：回滚答题记录
        rollback_score_table(student_id)    # 补偿：回滚成绩表
        return "失败"
    
    return "成功"

5) 【面试口播版答案】
面试官，您好。分布式事务在在线考试系统中，比如学生提交成绩时，需要同时更新成绩表和答题记录，保证原子性。我通常用Saga模式，把事务拆分为多个本地操作，每个操作有补偿步骤。比如先更新成绩表，再更新答题记录，若任一失败就回滚。关于CAP，考试系统需要强一致性（成绩立即可见），所以优先保证一致性，但系统分区时，可能允许部分用户操作延迟，通过补偿机制恢复，权衡后选择最终一致性方案，确保系统可用性。

6) 【追问清单】

• 问：为什么不用两阶段提交（2PC）？
  答：2PC协调者故障会导致事务阻塞，考试系统需要高可用，Saga模式更灵活，协调者故障不影响本地事务，且补偿机制处理失败。
• 问：CAP理论中，考试系统更看重一致性还是可用性？
  答：考试系统需要成绩立即可见（一致性），但分区时允许部分用户操作延迟，通过补偿事务恢复，优先保证一致性，分区时可用性降低。
• 问：Saga模式的补偿事务可能失败怎么办？
  答：补偿事务可能失败，需重试机制（如指数退避），避免循环重试，或设置超时时间防止死锁。
• 问：如果成绩表和答题记录在两个不同数据库，如何保证事务？
  答：通过分布式事务框架（如Seata），或Saga模式协调每个数据库的本地事务，确保原子性。

7) 【常见坑/雷区】

• 误用2PC：忽略协调者故障导致阻塞，考试系统需高可用；
• 忽略补偿事务复杂性：补偿失败可能导致数据不一致，需设计重试机制；
• CAP应用错误：误认为分区时可用性优先，导致成绩更新延迟；
• 忽略网络分区影响：2PC在分区时阻塞，Saga模式本地事务不受影响，但补偿事务可能失败；
• 未考虑隔离级别：分布式事务的隔离级别（如读未提交）可能影响并发性能，需根据业务调整。