分布式系統是指由多個節點通過網絡進行通信和協作的系統，它具有高可用性、高擴展性、高性能等優點，但也面臨著一些挑戰，如數據一致性、容錯性、負載均衡等。為了解決這些問題，分布式系統設計出現了一些經典的理論和方法，如 CAP 理論、BASE 理論、一致性等。

CAP 理論

CAP 理論是指一個分布式系統不可能同時滿足以下三個特性：

一致性（Consistency）：所有節點訪問同一份最新的數據副本
可用性（AvAIlability）：每次請求都能獲取到非錯的響應，不保證獲取的數據為最新數據
分區容錯性（Partition tolerance）：系統在網絡分區或故障時仍能繼續提供服務

CAP 理論的含義是，在一個分布式系統中，當發生網絡分區或故障時，只能在一致性和可用性之間做出權衡，不能同時保證兩者。因此分布式系統的設計者需要根據不同的業務場景和需求，選擇合適的架構和策略。對于需要強一致性的場景，如銀行轉賬，可以選擇 CP 架構，犧牲可用性；對于可以容忍一定程度的數據不一致的場景，如社交網絡，面對龐大用戶群體要保證可用性，可以選擇 AP 架構，犧牲一致性。

BASE 理論

BASE 理論是對 CAP 理論的延伸和補充，它是對大規模分布式系統實踐的總結，其核心思想是即使無法做到強一致性（CAP 的一致性是強一致性），但應用可以采用適當的方式來使系統達到最終一致性。BASE 是由 Basically Available（基本可用），Soft state（軟狀態）和 Eventually consistent（最終一致性）三個短語的縮寫。

基本可用（Basically Available）：指分布式系統在出現故障時，仍然能夠保證核心功能的可用性，但可能會降低服務質量，如響應時間、系統吞吐量等。
軟狀態（Soft state）：指分布式系統中的數據存在中間狀態，并且該狀態不影響系統整體可用性。軟狀態主要是由于數據同步存在延時而引起的。
最終一致性（Eventually consistent）：指分布式系統中所有節點經過一定時間后，最終能夠達到一個一致的狀態。最終一致性弱化了對系統實時一致性的要求，允許在特定時間內數據存在不一致。

BASE 理論是對傳統事務 ACID 特性（原子性、一致性、隔離性、持久性）的反思和妥協，在犧牲強一致性的前提下，追求更高的可用性和擴展性。

一致性

一致性問題是指在分布式系統中，由于多個節點之間需要通過網絡進行通信和協調，而網絡本身是不可靠的，可能出現延遲、丟包、重傳等現象，導致不同節點上的數據存在不一致或沖突的情況。例如，在一個分布式數據庫中，如果一個客戶端向一個節點寫入了一個新值，而另一個客戶端從另一個節點讀取了舊值，就出現了一致性問題。一致性問題會影響分布式系統的正確性和可靠性，因此需要采用一些協議和算法來解決。

2PC

兩階段提交（2PC）：是一種保證分布式事務強一致性的協議，它將事務的提交過程分為兩個階段：準備階段和提交階段。在準備階段，事務協調者向所有參與者發送準備請求，要求它們執行事務并鎖定資源，然后等待它們的響應；在提交階段，如果協調者收到了所有參與者的同意響應，就向它們發送提交請求，要求它們釋放資源并完成事務；如果協調者收到了任何一個參與者的拒絕響應或超時，就向它們發送回滾請求，要求它們釋放資源并取消事務。

2PC 的優點是簡單和高效，它只需要兩個階段就可以完成事務的提交或回滾，而且可以保證強一致性。2PC 的缺點是容易出現阻塞，如果協調者或參與者在第二階段發生故障，那么其他節點就無法知道事務的最終狀態，只能等待故障恢復或超時。另外 2PC 也會占用較多的資源，因為它需要在第一階段鎖定所有參與者的資源，直到第二階段結束才釋放。

3PC

三階段提交（3PC）：是對 2PC 的改進，它將事務的提交過程分為三個階段：準備階段、預提交階段和提交階段。在準備階段，事務協調者向所有參與者發送準備請求，要求它們執行事務并鎖定資源，然后等待它們的響應；在預提交階段，如果協調者收到了所有參與者的同意響應，就向它們發送預提交請求，并進入預提交狀態；如果協調者收到了任何一個參與者的拒絕響應或超時，就向它們發送回滾請求，并進入中止狀態；在提交階段，如果協調者收到了所有參與者的確認響應，就向它們發送提交請求，并進入完成狀態；如果協調者收到了任何一個參與者的超時或中斷消息，就向其余參與者發送回滾請求，并進入中止狀態。

3PC 的優點是避免了阻塞，它通過引入一個預提交階段來降低協調者或參與者在第二階段發生故障的概率，并且可以在故障發生時快速地進行回滾或提交。3PC 的缺點是增加了網絡開銷，因為它需要多發送一輪消息，并且需要維護一個超時機制來處理異常情況。而且 3PC 也不能完全保證強一致性。

3PC 強一致性失效是因為它無法處理所有可能發生的異常情況，例如網絡分區、協調者故障、參與者故障等。這些異常情況會導致不同的節點之間的信息不同步，從而造成數據或狀態的不一致。如果在提交階段，網絡發生了分區，導致協調者和部分參與者與其他參與者失去聯系，那么就可能出現不同的分區中有不同的提交決定。這樣就會造成數據不一致。

3PC 是一種試圖在保證強一致性的同時，避免阻塞和死鎖的協議，但是它并不完美，它也有自己的局限性和缺陷。因此在實際的分布式系統中，很少使用 3PC 協議，而是采用其他更先進和通用的一致性算法或協議，如 Paxos 算法、Raft 算法等。這些算法或協議可以容忍任意數量的節點故障，并且可以保證線性一致性或最終一致性。

Paxos

Paxos 算法是由 Leslie Lamport 在 1989 年提出的一種分布式一致性算法，它的目標是在一個由若干個提議者（Proposer）、若干個接受者（Acceptor）和若干個學習者（Learner）組成的系統中，選擇一個值作為共識結果。Paxos 算法分為兩個子過程：基本 Paxos 和多數派 Paxos。

基本 Paxos 是指在一個由若干個提議者和若干個接受者組成的系統中，選擇一個值作為共識結果。基本 Paxos 的過程如下：

首先，每個提議者選擇一個提案編號（Proposal Number）和一個提案值（Proposal Value），并向所有接受者發送 Prepare 消息；
然后，每個接受者收到 Prepare 消息后，如果提案編號大于它之前看到的任何編號，就回復 Promise 消息，并承諾不再接受任何編號小于該值的提案；否則，就忽略該消息；
接著，每個提議者收到多數接受者的 Promise 消息后，從中選擇一個最大的已接受提案值（如果存在），作為自己的提案值，并向所有接受者發送 Accept 消息；
最后，每個接受者收到 Accept 消息后，如果提案編號仍然大于等于它之前承諾的值，就回復 Accepted 消息，并接受該提案值；否則，就忽略該消息。當多數接受者都回復 Accepted 消息時，該提案值就被選為共識結果。

多數派 Paxos 是指在一個由若干個提議者、若干個接受者和若干個學習者組成的系統中，選擇一個值作為共識結果。多數派 Paxos 的過程如下：

首先，每個提議者選擇一個提案編號和一個提案值，并向一個領導者（Leader）發送 Propose 消息；
然后，領導者收集所有提議者的 Propose 消息，并從中選擇一個最大的提案編號和一個任意的提案值，作為自己的提案，并向所有接受者發送 Prepare 消息；
接著，每個接受者收到 Prepare 消息后，如果提案編號大于它之前看到的任何編號，就回復 Promise 消息，并承諾不再接受任何編號小于該值的提案；否則，就忽略該消息；
最后，領導者收到多數接受者的 Promise 消息后，向所有學習者發送 Learn 消息，并通知它們共識結果。當多數學習者都收到 Learn 消息時，該提案值就被選為共識結果。

Paxos 算法的優點是簡潔和高效，它只需要兩輪消息就可以完成一個值的共識，并且可以保證線性一致性。Paxos 算法的缺點是難以理解和實現，它涉及到多個角色和多個子過程，并且需要處理各種可能發生的情況。Paxos 算法也不適用于動態變化的系統，因為它需要預先知道所有節點的數量和身份。

Raft

Raft 算法是由 Diego Ongaro 和 John Ousterhout 在 2013 年提出的一種分布式一致性算法，它的目標是在一個由若干個節點組成的系統中，選擇一個領導者，并通過領導者來維護系統的狀態。Raft 算法將系統分為領導者、跟隨者和候選者三種角色，并且通過心跳和日志復制來維持系統的狀態。

Raft 算法的過程如下：

首先，所有節點都以跟隨者的身份啟動，如果一個跟隨者在一段時間內沒有收到領導者的心跳消息，就認為領導者已經失效，并轉變為候選者，開始發起選舉；
然后，每個候選者向其他節點發送投票請求，并為自己投票，如果一個候選者收到了多數節點的投票，就成為新的領導者，并向其他節點發送心跳消息；如果一個候選者收到了另一個候選者或領導者的消息，就放棄選舉，并轉變為跟隨者；
接著，每個領導者負責接收客戶端的請求，并將其作為日志條目追加到自己的日志中，然后向其他節點發送日志復制請求，要求它們將日志條目寫入自己的日志中；
最后，每個跟隨者收到日志復制請求后，如果日志條目與自己的日志匹配，就將其寫入自己的日志中，并回復確認消息；否則，就回復拒絕消息。當一個領導者收到了多數節點的確認消息后，就將該日志條目標記為已提交，并應用到自己的狀態機中；然后向其他節點發送提交通知，要求它們也將該日志條目應用到自己的狀態機中。

Raft 算法的優點是易于理解和實現，它將系統分為三種角色，并且通過心跳和日志復制來維持系統的狀態。Raft 算法的缺點是可能存在較高的網絡開銷，因為它需要頻繁地發送心跳消息，并且需要同步所有節點的日志。Raft 算法也不適用于高并發的場景，因為它只允許一個領導者來處理所有的請求。

EasyRetry

在上面講解了常見的一致性協議和算法后，博主這里介紹一個開源的分布式一致性解決方案 EasyRetry。

EasyRetry 是一款基于 BASE 思想實現的分布式服務重試組件，旨在通過重試機制確保數據的最終一致性。它提供了控制臺任務觀測、可配置的重試策略、重試后執行回調以及豐富地告警配置等功能。通過這些手段，可以對異常數據進行全面監測和回放，從而在確保系統高可用性的同時，大大提升數據的一致性。

核心優勢

數據持久化

對于系統中核心場景的數據安全是非常重要的保障手段，基于內存重試策略(目前業界比較比較出名的 SpringRetry 或者 GuavaRetry 都是基于內存重試實現的)數據的持久性得不到保障， EasyRetry 提供了本地重試、服務端重試、本地重試和服務端重試相結合三種重試模式。EasyRetry 的本地重試方案依然保留了內存重試的策略，應對短暫不可用場景下的快速補償。服務端重試則實現了數據的持久化，支持多種數據庫配置。用戶可以通過控制臺管理異常數據，自定義多種配置，便捷地完成數據補償操作。

基于補償機制保證分布式事務

在分布式系統里，我們可以使用 EasyRetry 來捕獲和處理異常數據，將不同系統產生的異常數據集中到 EasyRetry 的控制臺進行配置和管理。通過 EasyRetry，我們可以自定義重試策略和觸發時間。當重試任務執行成功或達到系統配置的最大執行次數時，服務端會向客戶端發送回調請求。在接收到回調請求后，客戶端可以指定后續動作。舉例來說，當服務端發起重試達到最大請求次數但仍然失敗時，客戶端可以執行回滾操作，確保事務的完整性。通過靈活配置回調請求的處理方式，我們可以根據具體業務需求進行相應的處理操作。