面试题：微服务架构中RPC超时处理机制与分布式事务的关系及处理策略

Question

在微服务架构里，当RPC调用出现超时时，可能会影响到分布式事务的一致性。请详细分析RPC超时处理机制与分布式事务之间的关联，并阐述针对不同的分布式事务模型（如两阶段提交、TCC等），如何设计相应的RPC超时处理策略，以保障系统数据的一致性和完整性。

Answer 1

RPC超时处理机制与分布式事务的关联

1. 分布式事务依赖RPC调用：在微服务架构中，分布式事务通常涉及多个服务间通过RPC调用协作完成一系列操作。例如，一个电商下单场景，可能涉及库存服务、订单服务等之间的RPC交互。如果其中某个RPC调用超时，可能导致部分服务执行了事务操作，而其他服务未执行，破坏事务一致性。
2. 超时导致不确定性：RPC调用超时并不一定意味着操作未执行。可能是网络延迟、服务繁忙等原因导致响应未及时返回，但目标服务已成功处理请求。这种不确定性使得分布式事务难以判断最终状态，进而影响一致性。
3. 连锁反应：一个RPC调用超时可能触发重试机制，如果处理不当，重试可能导致重复操作，进一步破坏数据一致性。比如重复扣减库存，造成超卖现象。

针对不同分布式事务模型的RPC超时处理策略

两阶段提交（2PC）

1. 第一阶段（投票阶段）超时处理
   • 协调者视角：如果协调者在向参与者发送准备请求后，部分参与者超时未响应，协调者应等待一段时间（可根据业务设定合理时间阈值）。若仍未收到响应，协调者应向所有已响应的参与者发送回滚请求，放弃本次事务。这是因为只要有一个参与者未响应，就无法保证事务的原子性，回滚能避免部分提交导致的数据不一致。
   • 参与者视角：参与者在等待协调者指令过程中，如果协调者超时未发送后续指令，参与者应主动回滚本地事务，释放资源。因为没有协调者的最终确认，无法确定事务是否成功，回滚可保证数据处于一致状态。
2. 第二阶段（提交/回滚阶段）超时处理
   • 协调者视角：若协调者向参与者发送提交/回滚请求后，部分参与者超时未响应，协调者应持续重试发送指令，直到所有参与者都有明确响应。这是因为在第一阶段所有参与者都已同意提交，只要继续重试确保所有参与者执行最终操作，就能保证事务一致性。若重试多次仍有参与者无响应，可记录日志并人工介入处理。
   • 参与者视角：参与者在收到提交/回滚请求后，执行相应操作并返回确认。如果参与者处理成功但响应超时，协调者会重试，参与者应能正确处理重复请求，避免重复操作。例如，使用幂等性设计，对于提交操作，多次执行结果相同，保证数据一致性。

TCC（Try - Confirm - Cancel）

1. Try阶段超时处理
   • 服务提供方视角：如果Try操作超时，服务提供方应检查本地资源预留情况。若资源已成功预留，可记录操作日志并等待后续Confirm或Cancel操作。若资源预留未完成，应清理已执行的部分操作，释放资源，确保数据一致性。
   • 服务调用方视角：调用方在Try操作超时时，应根据业务需求决定是否重试。若重试，需注意幂等性问题，避免重复预留资源。若不重试，应向相关服务发送Cancel请求，确保已预留资源被释放，防止资源浪费和数据不一致。
2. Confirm阶段超时处理
   • 服务提供方视角：若Confirm操作超时，服务提供方应检查Try阶段资源预留状态。若资源预留有效，应持续重试执行Confirm操作，直到成功。因为Try阶段已通过，Confirm操作应确保完成以提交事务。若资源已被释放（可能因Cancel操作），则应根据业务逻辑处理，如记录异常并通知相关方。
   • 服务调用方视角：调用方在Confirm操作超时时，应持续重试发送Confirm请求，直到收到成功响应或达到最大重试次数。若达到最大重试次数仍失败，可记录日志并人工介入处理，确保事务最终一致性。
3. Cancel阶段超时处理
   • 服务提供方视角：服务提供方在Cancel操作超时时，应持续重试释放资源，确保资源被正确释放。若重试多次仍失败，应记录详细日志，包括资源状态、操作记录等，方便后续排查和处理。
   • 服务调用方视角：调用方在Cancel操作超时时，应持续重试发送Cancel请求，直到收到成功响应或达到最大重试次数。若失败，可结合日志和监控信息人工介入，保证资源被释放，维护数据一致性和完整性。