## 1. 分布式事務協議
> 在分布式系統里,每個節點都可以知曉自己操作的成功或者失敗,卻無法知道其他節點操作的成功或失敗。當一個事務跨多個節點時,為了保持事務的原子性與一致性,而引入一個協調者來統一掌控所有參與者的操作結果,并指示它們是否要把操作結果進行真正的提交或者回滾(rollback)。
### 1.1 二階段提交2PC
二階段提交協議(Two-phase Commit,即 2PC)是常用的分布式事務解決方案,即將事務的提交過程分為兩個階段來進行處理。
**階段**
* 準備階段
* 提交階段
**參與角色**
* 協調者:事務的發起者
* 參與者:事務的執行者
**1\. 第一階段(voting phase投票階段):**
1. 協調者向所有參與者發送事務內容,詢問是否可以提交事務,并等待答復
2. 各參與者執行事務操作,將 undo 和 redo 信息記入事務日志中(但不提交事務)
3. 如參與者執行成功,給協調者反饋**同意**,否則反饋**中止**

**2. 第二階段(commit phase提交執行階段):**
當協調者節點從所有參與者節點獲得的相應消息都為**同意**時:
1. 協調者節點向所有參與者節點發出**正式提交**(`commit`)的請求。
2. 參與者節點正式完成操作,并釋放在整個事務期間內占用的資源。
3. 參與者節點向協調者節點發送**ack完成**消息。
4. 協調者節點收到所有參與者節點反饋的**ack完成**消息后,完成事務。

如果任一參與者節點在第一階段返回的響應消息為**中止**,或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應消息時:
1. 協調者節點向所有參與者節點發出**回滾操作**(`rollback`)的請求。
2. 參與者節點利用階段1寫入的undo信息執行回滾,并釋放在整個事務期間內占用的資源。
3. 參與者節點向協調者節點發送**ack回滾完成**消息。
4. 協調者節點受到所有參與者節點反饋的**ack回滾完成**消息后,取消事務。
不管最后結果如何,第二階段都會結束當前事務。


二階段提交看起來確實能夠提供原子性的操作,但是不幸的是,二階段提交還是有幾個缺點的:
1. **性能問題**:執行過程中,所有參與節點都是事務阻塞型的。當參與者占有公共資源時,其他第三方節點訪問公共資源不得不處于阻塞狀態。
2. **可靠性問題**:參與者發生故障。協調者需要給每個參與者額外指定超時機制,超時后整個事務失敗。協調者發生故障。參與者會一直阻塞下去。需要額外的備機進行容錯。
3. **數據一致性問題**:二階段無法解決的問題:協調者在發出`commit`消息之后宕機,而唯一接收到這條消息的參與者同時也宕機了。那么即使協調者通過選舉協議產生了新的協調者,這條事務的狀態也是不確定的,沒人知道事務是否被已經提交。
### 1.2 三階段提交(3PC)
三階段提交協議,是二階段提交協議的改進版本,三階段提交有兩個改動點。
* 在協調者和參與者中都引入超時機制。
* 在第一階段和第二階段中插入一個準備階段。保證了在最后提交階段之前各參與節點的狀態是一致的。
也就是說,除了引入超時機制之外,3PC把2PC的準備階段再次一分為二,這樣三階段提交就有`CanCommit`、`PreCommit`、`DoCommit`三個階段。處理流程如下:


**1\. 階段一:CanCommit階段**
3PC的`CanCommit`階段其實和2PC的準備階段很像。協調者向參與者發送`commit`請求,參與者如果可以提交就返回Yes響應,否則返回No響應。
1. 事務詢問 協調者向所有參與者發出包含事務內容的`canCommit`請求,詢問是否可以提交事務,并等待所有參與者答復。
2. 響應反饋 參與者收到`canCommit`請求后,如果認為可以執行事務操作,則反饋 yes 并進入預備狀態,否則反饋 no。
**2\. PreCommit階段**
協調者根據參與者的反應情況來決定是否可以進行事務的`PreCommit`操作。根據響應情況,有以下兩種可能。
* 假如所有參與者均反饋 yes,協調者預執行事務。
1. 發送預提交請求 :協調者向參與者發送`PreCommit`請求,并進入準備階段
2. 事務預提交 :參與者接收到`PreCommit`請求后,會執行事務操作,并將`undo`和`redo`信息記錄到事務日志中(但不提交事務)
3. 響應反饋 :如果參與者成功的執行了事務操作,則返回**ACK**響應,同時開始等待最終指令。

假如有任何一個參與者向協調者發送了No響應,或者等待超時之后,協調者都沒有接到參與者的響應,那么就執行事務的中斷。
1. 發送中斷請求 :協調者向所有參與者發送`abort`請求。
2. 中斷事務 :參與者收到來自協調者的`abort`請求之后(或超時之后,仍未收到協調者的請求),執行事務的中斷。

3.
- springcloud
- springcloud的作用
- springboot服務提供者和消費者
- Eureka
- ribbon
- Feign
- feign在微服務中的使用
- feign充當http請求工具
- Hystrix 熔斷器
- Zuul 路由網關
- Spring Cloud Config 分布式配置中心
- config介紹與配置
- Spring Cloud Config 配置實戰
- Spring Cloud Bus
- gateway
- 概念講解
- 實例
- GateWay
- 統一日志追蹤
- 分布式鎖
- 1.redis
- springcloud Alibaba
- 1. Nacos
- 1.1 安裝
- 1.2 特性
- 1.3 實例
- 1. 整合nacos服務發現
- 2. 整合nacos配置功能
- 1.4 生產部署方案
- 環境隔離
- 原理講解
- 1. 服務發現
- 2. sentinel
- 3. Seata事務
- CAP理論
- 3.1 安裝
- 分布式協議
- 4.熔斷和降級
- springcloud與alibba
- oauth
- 1. abstract
- 2. oauth2 in micro-service
- 微服務框架付費
- SkyWalking
- 介紹與相關資料
- APM系統簡單對比(zipkin,pinpoint和skywalking)
- server安裝部署
- agent安裝
- 日志清理
- 統一日志中心
- docker安裝部署
- 安裝部署
- elasticsearch 7.x
- logstash 7.x
- kibana 7.x
- ES索引管理
- 定時清理數據
- index Lifecycle Management
- 沒數據排查思路
- ELK自身組件監控
- 多租戶方案
- 慢查詢sql
- 日志審計
- 開發
- 登錄認證
- 鏈路追蹤
- elk
- Filebeat
- Filebeat基礎
- Filebeat安裝部署
- 多行消息Multiline
- how Filebeat works
- Logstash
- 安裝
- rpm安裝
- docker安裝Logstash
- grok調試
- Grok語法調試
- Grok常用表達式
- 配置中常見判斷
- filter提取器
- elasticsearch
- 安裝
- rpm安裝
- docker安裝es
- 使用
- 概念
- 基礎
- 中文分詞
- 統計
- 排序
- 倒排與正排索引
- 自定義dynamic
- 練習
- nested object
- 父子關系模型
- 高亮
- 搜索提示
- kibana
- 安裝
- docker安裝
- rpm安裝
- 整合
- 收集日志
- 慢sql
- 日志審計s
- 云
- 分布式架構
- 分布式鎖
- Redis實現
- redisson
- 熔斷和降級