面试题：分布式系统中微服务架构下保证ACID一致性的常见策略有哪些

策略简述：
- 第一阶段（准备阶段）：协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。参与者执行事务操作，但不提交，记录undo和redo日志，然后向协调者反馈执行结果。
- 第二阶段（提交阶段）：如果所有参与者都返回同意，协调者向所有参与者发送提交指令，参与者收到后正式提交事务；如果有任何一个参与者返回不同意，协调者向所有参与者发送回滚指令，参与者回滚事务。
适用场景：适用于对一致性要求极高，且系统中节点故障概率较低的场景，如银行转账等核心交易场景，确保资金等关键数据的一致性。

策略简述：
- 第一阶段（CanCommit阶段）：协调者向参与者发送CanCommit请求，询问是否可以执行事务提交操作。参与者如果可以正常执行事务则返回Yes响应，否则返回No响应。
- 第二阶段（PreCommit阶段）：若所有参与者都返回Yes响应，协调者向参与者发送PreCommit请求，参与者执行事务操作，但不提交，记录undo和redo日志，然后向协调者反馈执行结果。若有参与者返回No响应，或等待超时，协调者向所有参与者发送Abort请求，参与者回滚事务。
- 第三阶段（DoCommit阶段）：如果协调者收到所有参与者的成功反馈，向所有参与者发送DoCommit请求，参与者正式提交事务；如果在等待反馈过程中有参与者反馈失败，或等待超时，协调者向所有参与者发送Abort请求，参与者回滚事务。
适用场景：相比2PC，3PC降低了单点故障导致数据不一致的风险，适用于节点故障可能性相对较高，但仍对一致性有严格要求的场景，例如一些涉及多方数据交互且不容许数据不一致的金融业务场景。

策略简述：
- Try阶段：主要是对业务系统做检测及资源预留。例如在订单系统中，Try阶段会检查库存是否足够，并冻结相应库存。
- Confirm阶段：确认执行业务操作，即提交事务。在上例中，Confirm阶段会真正扣减库存，完成订单。
- Cancel阶段：若Try阶段执行成功，但Confirm阶段执行失败，Cancel阶段会取消之前的操作，释放预留资源，如解冻库存。
适用场景：适用于业务逻辑较复杂，需要跨多个服务进行事务操作，且对性能要求较高的场景。如电商的下单、支付、库存管理等业务，允许一定程度的最终一致性，通过补偿机制来保证数据的正确性。

策略简述：在本地数据库中建立消息表，业务操作和消息写入在同一个本地事务中完成。消息表中的消息通过异步机制发送到消息队列，接收方从消息队列获取消息并处理，处理完成后反馈确认信息。发送方如果未收到确认信息，会进行重试。
适用场景：适用于对一致性要求较高，允许一定延迟，且业务操作和消息发送可以在同一数据库事务中的场景。如电商的订单创建后异步通知库存系统扣减库存的场景。

策略简述：利用消息中间件的可靠消息传递机制。发送方发送消息时，消息中间件保证消息的可靠存储和投递。接收方消费消息后进行业务处理，通过事务机制确保消息处理和业务操作的一致性。如果消息处理失败，消息中间件会进行重试。
适用场景：适用于系统之间解耦性要求高，对一致性要求最终达成即可的场景，例如电商系统中的订单创建后通知物流系统发货，允许在一定时间内数据达到一致。

星途面试题库