面试题：微服务架构下服务拆分对数据一致性的影响及应对策略

Question

在微服务架构进行服务拆分后，数据一致性往往面临挑战。请分析服务拆分是如何影响数据一致性的，并详细说明至少两种应对这种影响的数据一致性解决方案及其适用场景。

Answer 1

服务拆分对数据一致性的影响

1. 分布式事务问题：服务拆分后，原本单体应用中的本地事务被打破。不同服务可能操作不同的数据库，若这些操作需保持一致性，传统本地事务无法满足，引入分布式事务管理难题。例如，订单服务创建订单时需扣减库存服务中的库存，两个操作需原子性完成，但不同服务和数据库使实现难度加大。
2. 数据同步延迟：各服务独立维护数据，数据变更后可能无法实时同步到其他相关服务。如用户信息服务更新用户地址，订单服务可能无法立刻获取新地址，导致展示或使用旧数据，影响数据一致性。
3. 服务间依赖与协调复杂：微服务架构下，服务间调用频繁且依赖关系复杂。若某个服务故障或响应延迟，可能连锁影响其他服务，导致数据处理异常，破坏数据一致性。例如，支付服务依赖银行接口，银行接口故障时，支付服务无法完成交易确认，影响订单状态等相关数据一致性。

应对数据一致性的解决方案及适用场景

1. 两阶段提交（2PC）

• 原理：协调者先向所有参与者发送预提交请求，参与者执行事务操作但不提交，反馈执行结果。若所有参与者反馈成功，协调者再发送提交请求，参与者正式提交事务；若有参与者反馈失败，协调者发送回滚请求，参与者回滚事务。
• 适用场景：适用于对数据一致性要求极高，且事务涉及服务数量相对较少、网络环境相对稳定的场景。如银行转账，涉及转出账户服务和转入账户服务，需确保资金总额不变，2PC 可保证转账操作的原子性和数据一致性。

2. 最终一致性 - 消息队列（MQ）

• 原理：服务产生数据变更时，将相关消息发送到消息队列。其他依赖该数据的服务从队列中消费消息，根据消息内容进行相应数据更新。消息队列提供可靠的消息传递机制，即使部分服务暂时不可用，消息也不会丢失，待服务恢复后可继续消费处理。
• 适用场景：适用于对一致性要求不是强实时，但最终要达到一致的场景。如电商系统中，订单创建成功后，通过消息队列通知库存服务扣减库存、通知物流服务准备发货等。允许一定时间内各服务数据状态存在差异，但最终能达到一致。