數據一致性問題

問題本質

由于每個微服務擁有獨立數據庫，跨服務操作不能用傳統的數據庫事務，面臨“分布式事務”一致性挑戰。

數據一致性策略

策略	核心思想	應用場景	優缺點
強一致性（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 模式。

高可用性策略：

• 服務層使用注冊中心 + 網關 + 負載均衡；
• 數據層采用主從復制、緩存降級和數據庫讀寫分離；
• 引入服務熔斷、限流、降級機制防止系統雪崩；
• 基礎設施層采用容器化 + 自動化部署，提升可用性。