数据一致性问题
问题本质
由于每个微服务拥有独立数据库，跨服务操作不能用传统的数据库事务，面临“分布式事务”一致性挑战。
数据一致性策略
| 策略 | 核心思想 | 应用场景 | 优缺点 |
|---|---|---|---|
| 强一致性（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 模式。
高可用性策略：
- 服务层使用注册中心 + 网关 + 负载均衡；
- 数据层采用主从复制、缓存降级和数据库读写分离；
- 引入服务熔断、限流、降级机制防止系统雪崩；
- 基础设施层采用容器化 + 自动化部署，提升可用性。