點一下關注吧！！！非常感謝！！持續更新！！！
🚀 AI篇持續更新中！（長期更新）
目前2025年06月16日更新到：
AI煉丹日志-29 - 字節跳動 DeerFlow 深度研究框斜體樣式架 私有部署 測試上手 架構研究，持續打造實用AI工具指南！📐🤖
💻 Java篇正式開啟！（300篇）
目前2025年06月26日更新到：
Java-55 深入淺出 分布式服務 分布式一致性 強一致、弱一致、單調讀一致、最終一致
MyBatis 已完結，Spring 已完結，Nginx已完結，Tomcat已完結，分布式服務正在更新！深入淺出助你打牢基礎！
📊 大數據板塊已完成多項干貨更新（300篇）：
包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余項核心組件，覆蓋離線+實時數倉全棧！
目前2025年06月13日更新到：
大數據-278 Spark MLib - 基礎介紹 機器學習算法 梯度提升樹 GBDT案例 詳解
一致性3PC（Three-Phase Commit）
概述
3PC（Three-Phase Commit）全稱為三階段提交協議，是二階段提交協議（2PC）的改進版本。3PC將2PC的提交事務請求過程進一步細分為兩個階段，最終形成由CanCommit、PreCommit和doCommit三個階段組成的分布式事務處理協議。
協議階段詳解
1. CanCommit階段（詢問階段）
- 協調者向所有參與者發送CanCommit請求
- 參與者檢查自身狀態，判斷是否可以執行事務
- 參與者回復Yes/No響應（ACK/NACK）
- 協調者根據響應決定是否進入下一階段
2. PreCommit階段（準備階段）
- 若全部參與者回復Yes，協調者發送PreCommit請求
- 參與者執行事務操作但不提交，寫入undo/redo日志
- 參與者鎖定相關資源，確保事務可回滾
- 參與者回復Ack確認準備完成
3. doCommit階段（提交階段）
- 協調者收到所有Ack后發送doCommit請求
- 參與者正式提交事務
- 參與者釋放資源鎖
- 參與者回復Ack確認提交完成
改進優勢
與2PC相比，3PC的主要改進包括：
- 增加了CanCommit階段，提前驗證參與者狀態
- 降低了阻塞風險（引入超時機制）
- 提高了系統可用性（部分故障可繼續運行）
- 減少了協調者單點故障的影響
應用場景
3PC適用于以下分布式系統場景：
- 數據庫集群事務處理
- 跨服務的事務協調
- 微服務架構中的Saga模式
- 需要較高可用性的分布式系統
局限性
盡管3PC有所改進，但仍存在以下問題：
- 網絡分區時可能導致數據不一致
- 實現復雜度高于2PC
- 性能開銷相對較大
- 不能完全解決所有分布式一致性問題
階段一
● 事務詢問：協調者向所有參與者發送一個包含事務內容的canCommit請求，詢問是否可以執行事務提交操作，并開始等待各參與者的響應
● 各參與者向協調者反饋事務詢問的響應：參與者在接收到來自協調者的包含了事務內容的canCommit請求后，在正常情況下，如果自身認為可以順利執行事務，則反饋Yes，并進入預備狀態，否則反饋No響應。
階段二
PreCommit
協調者在得到參與者的響應之后，會根據結果有2種執行操作的情況：執行事務預提交，或者中斷事務。
假如所有參與者反饋的都是Yes，那么就會執行事務預提交。
● 發送預提交請求：協調者向所有參與節點發出 preCommit 請求，并進入 prepared 階段
● 事務預提交：參與者接收到 preCommit 請求后，會執行事務操作，并將 Undo、Redo 信息記錄到事務日志中
● 各參與協調者反饋事務執行的結果：若參與者執行成功了事務操作，那么反饋ACK。若任一參與者反饋了No的時候，或者超時之后，協調者無法收到所有參與者的響應，則中斷事務
中斷事務也分為兩個步驟：
● 發送中斷請求：協調者向所有參與者發出 abort 請求
● 中斷事務：無論是收到來自協調者的abort請求或者等待協調者請求過程中超時，參與者都會中斷事務
階段三
doCommit
該階段做真正的事務提交或者完成事務回滾，所有會出現兩種情況：
情況一 執行事務提交
● 發送提交請求：進入這一階段，假設協調者處于正常工作狀態，并且它接收到了來自所有參與者ACK響應，那么他將從預提交狀態轉換為提交狀態，并向所有參與者發送doCommit請求
● 事務提交：參與者收到doCommit請求后，會正式執行事務提交操作，并在完成提交之后釋放整個事務執行過程中占用的事務資源。
● 反饋事務提交結果：參與者在完成事務提交后，向協調者發送ACK響應
● 完成事務：協調者接收到所有參與者反饋的ACK消息之后，完成事務。
情況二 中斷事務
● 發送中斷請求：協調者向所有的參與者節點發送abort請求。
● 事務回滾：參與者收到abort請求后，會根據記錄的Undo信息來執行事務回滾，并在完成回滾之后釋放整個事務執行期間占用的資源
● 反饋事務回滾結果：參與者在完成事務回滾后，向協調者發送ACK消息
● 中斷事務：協調者接收到所有參與者反饋的ACK消息后，中斷事務
注意：一旦進入階段三，可能會出現2種故障：
● 協調者出現問題
● 協調者和參與者之間的網絡故障
如果出現任意一種情況，最終都會導致參與者無法收到 doCommit 請求 或者 abort 請求，針對這種情況，參與者都會在超時之后，繼續進行事務提交
2PC對比3PC
超時機制改進
在2PC（兩階段提交）協議中，只有協調者擁有超時機制。這意味著當協調者在規定時間內沒有收到參與者的響應時，會默認事務執行失敗。然而，3PC（三階段提交）對此進行了重要改進：
- 參與者超時機制：
- 每個參與者都設置了超時計時器
- 如果在CanCommit或PreCommit階段長時間未收到協調者指令（如網絡分區或協調者故障）
- 參與者會在超時后自動執行本地Commit操作釋放資源
實際應用場景示例：
當電商系統處理分布式訂單時，如果支付服務（參與者）在PreCommit階段與訂單服務（協調者）失去連接，支付服務會在超時后自動提交本地事務，避免資金長時間凍結。
三階段設計優勢
3PC通過三個階段的設計提供了更好的可靠性：
-
CanCommit階段：
- 協調者詢問參與者是否具備執行事務的條件
- 參與者檢查資源可用性但不鎖定資源
- 類似于"預檢查"階段
-
PreCommit階段：
- 核心緩沖階段
- 協調者在收到所有參與者的Yes響應后發送PreCommit請求
- 參與者執行事務操作但暫不提交
- 在此階段確保所有參與者狀態一致
-
DoCommit階段：
- 最終提交階段
- 協調者確認所有參與者完成PreCommit后發送提交指令
分階段好處示例：
在銀行轉賬系統中，PreCommit階段可以確保所有賬戶的余額檢查通過且金額已臨時扣減，才會進入最終提交階段，避免部分賬戶扣款成功而其他賬戶失敗的情況。
局限性
盡管有上述改進，3PC仍存在以下問題：
-
數據不一致的可能性：
- 在DoCommit階段若發生網絡分區
- 部分參與者可能收不到提交指令
- 導致系統部分節點已提交而其他節點未提交
-
性能損耗：
- 額外的通信階段增加了延遲
- 不適合對延遲敏感的應用場景
-
實現復雜度：
- 需要更復雜的狀態機來處理各階段異常
- 增加了系統開發和維護成本
實際案例：
在分布式數據庫系統中，即使使用3PC，仍然需要額外的補償機制（如人工干預或自動修復程序）來處理極端情況下出現的數據不一致問題。
