面试题：微服务架构与传统架构在数据一致性方面的挑战及应对策略

Question

分析微服务架构与传统架构在数据一致性维护上分别面临哪些不同的挑战。针对微服务架构中的分布式数据一致性问题，阐述至少两种主流的解决方案，包括其原理、适用场景及可能存在的局限性。

Answer 1

微服务架构与传统架构在数据一致性维护上的挑战差异

1. 传统架构
   • 集中式数据库问题：传统架构常基于集中式数据库，虽然数据一致性相对好维护，但随着业务规模增长，数据库可能成为性能瓶颈，高并发读写时，锁争用严重，影响系统响应速度。例如大型电商系统在促销活动时，集中式数据库处理大量订单读写，易出现卡顿。
   • 架构耦合度：业务逻辑紧密耦合在整体架构中，一处数据修改可能影响多处相关逻辑，牵一发而动全身，增加了一致性维护的复杂性。比如一个大型单体应用，用户信息修改可能影响订单、支付等多个模块。
2. 微服务架构
   • 分布式数据管理：微服务架构中数据分布在多个独立的数据库或存储系统中，不同服务间数据同步困难，易出现数据不一致。例如订单服务和库存服务分别有自己的数据库，订单创建时库存扣减操作若不同步完成，就会造成数据不一致。
   • 网络延迟与故障：各微服务通过网络通信，网络延迟、故障等会导致消息传递不及时或丢失，进而影响数据一致性。如服务 A 向服务 B 发送更新数据的消息，因网络问题未送达，就会产生数据状态不一致。
   • 事务处理复杂：传统单体架构的本地事务难以适用于微服务的分布式场景，分布式事务的实现和管理复杂，增加了一致性维护难度。

微服务架构中分布式数据一致性主流解决方案

1. 两阶段提交（2PC）
   • 原理：引入协调者（Coordinator）角色。第一阶段，协调者向所有参与者发送准备（Prepare）消息，参与者执行事务操作但不提交，向协调者反馈执行结果；第二阶段，若所有参与者准备成功，协调者发送提交（Commit）消息，参与者正式提交事务；若有参与者准备失败，协调者发送回滚（Rollback）消息，参与者回滚事务。
   • 适用场景：适用于对数据一致性要求极高，且事务参与者数量相对较少的场景。如银行转账，涉及账户服务和交易记录服务，要求金额一致性极高。
   • 局限性
     • 单点故障：协调者是关键节点，若协调者故障，整个事务无法推进，可能导致参与者资源长时间锁定。
     • 性能问题：两阶段过程中，参与者资源处于锁定状态，等待协调者指令，在高并发场景下，性能较差。
     • 网络依赖：依赖可靠的网络，若网络故障导致消息丢失，可能出现数据不一致。
2. 最终一致性（以消息队列为例）
   • 原理：发生数据变更时，将变更消息发送到消息队列，相关服务从消息队列消费消息并处理，最终使数据达到一致状态。例如订单创建成功后，订单服务向消息队列发送库存扣减消息，库存服务消费该消息进行库存扣减。
   • 适用场景：适用于对一致性要求不是强实时，允许一定时间内数据不一致的场景。如电商系统中的商品评论更新，用户看到评论有一定延迟可接受。
   • 局限性
     • 一致性延迟：从数据变更到最终一致有时间差，不适用于对实时一致性要求高的场景。
     • 消息处理异常：若消息在队列中丢失、重复消费或处理失败，可能导致数据不一致，需额外的机制保证消息可靠处理。