微服務和分布式

• 微服務 是一種軟件架構風格，它將應用程序拆分成一系列小型、獨立的服務，每個服務專注于單一功能，彼此通過輕量級通信機制（如 API）進行交互。微服務通常是松耦合的，可以獨立開發、部署和擴展。

• 分布式系統 是指一組獨立的計算機（或節點）通過網絡協同工作，共同完成任務。這些節點沒有共享內存，依靠消息傳遞來通信。分布式系統的目標通常是提高性能、可靠性或容錯能力。

• 微服務但非分布式：一個電商系統被拆分為“訂單服務”和“支付服務”，但它們都運行在同一臺服務器上。

• 分布式但非微服務：一個單體應用部署在多臺服務器上，通過負載均衡分擔流量。

• 微服務+分布式：一個電商系統的“訂單服務”運行在服務器 A 上，“支付服務”運行在服務器 B 上，它們通過 API 通信。

CAP

Base理論

BASE 理論本質上是 CAP 定理中 AP 的一種實踐指導原則，告訴開發者如何通過基本可用、軟狀態和最終一致性來應對分區和故障。

示例一

• 場景：系統包括訂單服務、庫存服務、支付服務，用 Nacos 作為注冊中心。訂單服務下單時需要調用庫存服務扣減庫存。
• 網絡分區發生：庫存服務的 3 個實例（A、B、C）中，C 與 A、B 網絡斷開（分區）。
• AP 選擇（基于 BASE）
  • 基本可用：訂單服務繼續接受用戶下單請求（保證 A）。如果庫存服務 C 不可用，訂單服務調用 A 或 B，或者降級（記錄訂單，稍后扣庫存）。
  • 軟狀態：分區期間，實例 C 的庫存數據未更新（顯示 100 件），A 和 B 已扣到 90 件。
  • 最終一致性：分區恢復后，系統通過消息隊列（比如 Kafka）或日志重放，將 C 的庫存同步到 90 件。

示例二

分布式事務

XA模式

AT模式

TCC模式

需要自己寫代碼完成邏輯

MQ分布式事務

接口冪等性

冪等性是一個數學概念，用在接口上：用在接口上就可以理解為：同一個接口，多次發出同一個請求，請求的結果是一致的。

在系統的運行中，可能會出現這樣的問題：

• 用戶在填寫某些form表單時，保存按鈕不小心快速點了兩次，表中竟然產生了兩條重復的數據，只是 id 不一樣。
• 開發人員在項目中為了解決接口超時問題，通常會引入了重試機制。第一次請求接口超時了，請求方沒能及時獲取返回結果（此時有可能已經成功了），于是會對該請求重試幾次，這樣也會產生重復的數據。
• mq 消費者在讀取消息時，有時候會讀取到重復消息，也會產生重復的數據。

方案一

請求接口之前，需要先獲取一個唯一的 token，再帶著這個 token 去完成業務操作，服務端根據這個 token 是否存在，來判斷是否是重復的請求。

方案二

直接在數據庫上加鎖的做法性能不夠友好，可以使用分布式鎖的方式，目前最流行的分布式鎖實現是通過 Redis，具體實現一般都是使用 Redission 框架。