面试题：分布式系统下3PC与分布式锁结合时的一致性保障

Question

在后端开发的分布式系统中，当3PC与分布式锁结合使用来处理事务时，如何确保数据的一致性？如果出现网络分区等异常情况，怎样通过两者的协作来维持一致性，详细说明其原理和处理流程。

Answer 1

1. 3PC 与分布式锁确保数据一致性原理

• 3PC（三阶段提交协议）原理：
  • 准备阶段（CanCommit）：协调者向所有参与者发送 CanCommit 请求，询问是否可以执行事务操作。参与者检查自身资源等情况，如果可以则回复 Yes，否则回复 No。
  • 预提交阶段（PreCommit）：若所有参与者都回复 Yes，协调者发送 PreCommit 请求，参与者接收到后执行事务操作，但不提交。此时参与者会持有数据的锁，防止其他事务对相关数据进行修改，以保证数据一致性。
  • 提交阶段（DoCommit）：协调者收到所有参与者的 PreCommit 成功响应后，发送 DoCommit 请求，参与者真正提交事务。若有参与者在准备阶段回复 No，协调者发送 Abort 请求，参与者回滚事务。
• 分布式锁作用：分布式锁用于保证在分布式环境下同一时间只有一个节点能够对共享资源进行操作。在 3PC 过程中，特别是在预提交阶段，通过获取分布式锁，确保只有持有锁的参与者才能对数据进行操作，避免多个节点同时修改同一数据导致不一致。

2. 网络分区异常情况处理流程

• 网络分区导致部分节点失联：
  • 3PC 角度：
    • 在准备阶段，如果协调者部分参与者失联，若失联节点未回复，协调者等待超时后，会认为这些节点无法参与事务，向所有正常节点发送 Abort 请求，正常节点回滚事务。
    • 在预提交阶段，若部分参与者失联，协调者同样等待超时后，向正常节点发送 Abort 请求。失联节点在恢复网络后，若收到 Abort 请求则回滚事务；若未收到，等待协调者后续处理。
    • 在提交阶段，若部分参与者失联，协调者会重试向失联节点发送 DoCommit 请求，若多次重试仍失败，记录该情况，待失联节点恢复网络后进行补偿操作（如重新发送 DoCommit 请求）。
  • 分布式锁角度：
    • 持有分布式锁的节点若在网络分区中失联，锁服务需要有机制检测节点是否存活。如通过心跳检测，若发现持有锁的节点长时间无心跳，判定其故障，释放锁。这样其他节点在网络恢复后可重新竞争锁，重新参与事务处理。
    • 当网络恢复后，失联节点重新加入系统，若之前处于预提交阶段且未收到 Abort 请求，需重新获取分布式锁（因为之前持有的锁可能已因故障被释放）。若获取成功，继续执行提交阶段；若获取失败，说明有其他节点已处理该事务，需根据协调者状态进行回滚或确认已提交。
• 网络分区导致脑裂：
  • 3PC 角度：协调者需要有选举机制，当出现脑裂情况，多个“协调者”同时存在时，通过选举确定唯一的有效协调者。例如基于 Paxos 或 Raft 算法进行选举。新选举出的协调者向所有节点发送最新的事务状态，确保所有节点状态一致。
  • 分布式锁角度：锁服务需保证在脑裂情况下锁的一致性。可以采用多数投票机制，只有超过半数节点认可的锁操作才是有效的。例如，在脑裂形成的两个分区中，只有一个分区能获取到超过半数节点认可的锁，避免不同分区同时操作共享资源导致数据不一致。当脑裂恢复后，锁服务进行状态整合，确保所有节点对锁的状态认知一致。