数据一致性问题

问题本质

由于每个微服务拥有独立数据库，跨服务操作不能用传统的数据库事务，面临“分布式事务”一致性挑战。

数据一致性策略

策略	核心思想	应用场景	优缺点
强一致性（Strong Consistency）	所有操作实时同步成功，用户总是看到最新数据	金融、电商扣款等高安全场景	实现复杂，性能下降
最终一致性（Eventual Consistency）	不保证实时一致，但最终会一致	大多数业务场景，如电商订单、库存	易扩展，性能好，但用户短时间可能看到“旧数据”
分布式事务协议：2PC/3PC	通过协调器两阶段提交实现原子性	事务级别操作，如账户转账	实现难，性能差，可能阻塞
本地事务 + 异步消息补偿（推荐）	本地操作成功后发送消息，由对方服务异步处理，失败可重试或补偿	大多数微服务场景	实用性强，但需自行处理幂等、消息丢失等问题
TCC 模式（Try-Confirm-Cancel）	三阶段事务模型，预留资源后确认/取消操作	资源型操作（预订、库存等）	设计复杂，适用于少数场景
Saga 模式（编排式/事务链）	业务分为多个本地事务，失败时按顺序回滚	订单、支付、发货流程	灵活，适合复杂业务流程

高可用性设计策略

服务高可用（服务不挂）

策略	说明
服务注册与发现	使用 Nacos/Consul 等注册中心实现服务发现与自动切换
负载均衡	使用 Nginx 或 Ribbon/Gateway 等分流到多实例
服务熔断/限流/降级	使用 Sentinel、Hystrix 避免雪崩效应
无状态设计	使服务可任意扩缩容，实现快速替换
容器化部署 + 自动恢复	K8s/Pod 自动拉起故障实例

数据高可用（数据不丢）

策略	说明
数据库主从复制/读写分离	实现高并发读写与故障切换
分布式缓存（如 Redis Sentinel、Cluster）	降低数据库压力，容错性强
消息队列持久化机制	Kafka/RabbitMQ 持久化，保证消息不丢
定期快照 + 增量备份	数据恢复能力

网络/基础设施高可用：

策略	说明
多机房/跨区域部署	容灾设计，机房故障不影响服务
负载均衡器（如 SLB）+ 自动切换	实现自动流量调度

示例

某系统采用微服务架构，请说明如何保证其数据一致性和高可用性？

解答：

数据一致性策略：

• 采用“本地事务 + 消息队列”方案实现最终一致性；
• 各服务完成本地事务后，通过 MQ 异步通知其他服务处理；
• 使用幂等机制和失败重试/补偿机制保障一致性；
• 对于复杂业务，采用 Saga 模式或 TCC 模式。

高可用性策略：

• 服务层使用注册中心 + 网关 + 负载均衡；
• 数据层采用主从复制、缓存降级和数据库读写分离；
• 引入服务熔断、限流、降级机制防止系统雪崩；
• 基础设施层采用容器化 + 自动化部署，提升可用性。