免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

XA/二階段提交

基于XA協(xié)議的二階段提交

所謂的 XA 方案，即：兩階段提交，有一個事務管理器的概念，負責協(xié)調多個數(shù)據(jù)庫（資源管理器）的事務，事務管理器先問各個數(shù)據(jù)庫準備好了嗎？如果每個數(shù)據(jù)庫都回 ok，那就正式提交事務，在各個數(shù)據(jù)庫上執(zhí)行操作；如果任何其中一個數(shù)據(jù)庫回答不 ok，那么就回滾事務。

JTA

JTA只是Java實現(xiàn)XA事務的一個規(guī)范，全稱Java事務規(guī)范JTA（Java Transaction API) ，我們日常使用的@Transactional。都可以叫JTA事務管理。實際上，JTA是基于XA架構上建模的，

鏈式

參考

問題

• 同步阻塞問題：
  二階段提交算法在執(zhí)行過程中，所有參與節(jié)點都是事務阻塞型的。
  也就是說，當本地資源管理器占有臨界資源時，其他資源管理器如果要訪問同一臨界資源，會處于阻塞狀態(tài)。
• 單點故障問題：基于 XA 的二階段提交算法類似于集中式算法，一旦事務管理器發(fā)生故障，整個系統(tǒng)都處于停滯狀態(tài)。
  尤其是在提交階段，一旦事務管理器發(fā)生故障，資源管理器會由于等待管理器的消息，而一直鎖定事務資源，導致整個系統(tǒng)被阻塞。
• 數(shù)據(jù)不一致問題：在提交階段，當協(xié)調者向參與者發(fā)送 DoCommit 請求之后，如果發(fā)生了局部網(wǎng)絡異常，或者在發(fā)送提交請求的過程中協(xié)調者發(fā)生了故障，就會導致只有一部分參與者接收到了提交請求并執(zhí)行提交操作，但其他未接到提交請求的那部分參與者則無法執(zhí)行事務提交。
  于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致的問題。

3PC

• 同時在協(xié)調者和參與者中引入超時機制。
  如果協(xié)調者或參與者在規(guī)定的時間內沒有接收到來自其他節(jié)點的響應，就會根據(jù)當前的狀態(tài)選擇提交或者終止整個事務。
• 在第一階段和第二階段中間引入了一個準備階段，也就是在提交階段之前，加入了一個預提交階段。
  在預提交階段排除一些不一致的情況，保證在最后提交之前各參與節(jié)點的狀態(tài)是一致的。

canCommit

precommit

• 如果所有參與者回復的都是“Yes”，那么協(xié)調者就會執(zhí)行事務的預執(zhí)行：

• 發(fā)送預提交請求。協(xié)調者向參與者發(fā)送 PreCommit 請求，進入預提交階段。

• 事務預提交。

  參與者接收到 PreCommit 請求后執(zhí)行事務操作，并將 Undo 和 Redo 信息記錄到事務日志中。

• 響應反饋。

  如果參與者成功執(zhí)行了事務操作，則返回 ACK 響應，同時開始等待最終指令。

• 假如任何一個參與者向協(xié)調者發(fā)送了“No”消息，或者等待超時之后，協(xié)調者都沒有收到參與者的響應，就執(zhí)行中斷事務的操作：

• 發(fā)送中斷請求。

  協(xié)調者向所有參與者發(fā)送“Abort”消息。

• 終斷事務。

  參與者收到“Abort”消息之后，或超時后仍未收到協(xié)調者的消息，執(zhí)行事務的終斷操作。

doCommit

DoCmmit 階段進行真正的事務提交，根據(jù) PreCommit 階段協(xié)調者發(fā)送的消息，進入執(zhí)行提交階段或事務中斷階段。

• 執(zhí)行提交階段：

• 發(fā)送提交請求。

  協(xié)調者接收到所有參與者發(fā)送的 Ack 響應，從預提交狀態(tài)進入到提交狀態(tài)，并向所有參與者發(fā)送 DoCommit 消息。

• 事務提交。

  參與者接收到 DoCommit 消息之后，正式提交事務。

  完成事務提交之后，釋放所有鎖住的資源。

• 響應反饋。

  參與者提交完事務之后，向協(xié)調者發(fā)送 Ack 響應。

• 完成事務。

  協(xié)調者接收到所有參與者的 Ack 響應之后，完成事務。

• 事務中斷階段：

• 發(fā)送中斷請求。

  協(xié)調者向所有參與者發(fā)送 Abort 請求。

• 事務回滾。

  參與者接收到 Abort 消息之后，利用其在 PreCommit 階段記錄的 Undo 信息執(zhí)行事務的回滾操作，并釋放所有鎖住的資源。

• 反饋結果。

  參與者完成事務回滾之后，向協(xié)調者發(fā)送 Ack 消息。

)

TCC

TCC 的全稱是：Try 、 Confirm 、 Cancel 。

• Try 階段：

  這個階段說的是對各個服務的資源做檢測以及對資源進行鎖定或者預留。

• Confirm 階段：

  這個階段說的是在各個服務中執(zhí)行實際的操作。

• Cancel 階段：

  如果任何一個服務的業(yè)務方法執(zhí)行出錯，那么這里就需要進行補償，就是執(zhí)行已經(jīng)執(zhí)行成功的業(yè)務邏輯的回滾操作。

這種方案說實話幾乎很少人使用。因為這個事務回滾實際上是嚴重依賴于你自己寫代碼來回滾和補償了，會造成補償代碼巨大，非常之惡心。等于一個借口拆成三個。
一般來說跟錢相關的，支付、交易，會用 TCC，嚴格保證分布式事務要么全部成功，要么全部自動回滾，嚴格保證資金正確。
而且最好是各個業(yè)務執(zhí)行的時間都比較短。

Sega

金融核心等業(yè)務可能會選擇 TCC 方案，以追求強一致性和更高的并發(fā)量，而對于更多的金融核心以下的業(yè)務系統(tǒng) 往往會選擇補償事務，補償事務處理在 30 多年前就提出了 Saga 理論，隨著微服務的發(fā)展，近些年才逐步受到大家的關注。目前業(yè)界比較公認的是采用 Saga 作為長事務的解決方案。

基本原理

業(yè)務流程中每個參與者都提交本地事務，若某一個參與者失敗，則補償前面已經(jīng)成功的參與者。下圖左側是正常的事務流程，當執(zhí)行到 T3 時發(fā)生了錯誤，則開始執(zhí)行右邊的事務補償流程，反向執(zhí)行 T3、T2、T1 的補償服務 C3、C2、C1，將 T3、T2、T1 已經(jīng)修改的數(shù)據(jù)補償?shù)簟?/p>

使用場景

對于一致性要求高、短流程、并發(fā)高 的場景，如：金融核心系統(tǒng)，會優(yōu)先考慮 TCC 方案。而在另外一些場景下，我們并不需要這么強的一致性，只需要保證最終一致性即可。
比如 很多金融核心以上的業(yè)務（渠道層、產(chǎn)品層、系統(tǒng)集成層），這些系統(tǒng)的特點是最終一致即可、流程多、流程長、還可能要調用其它公司的服務。這種情況如果選擇 TCC 方案開發(fā)的話，一來成本高，二來無法要求其它公司的服務也遵循 TCC 模式。同時流程長，事務邊界太長，加鎖時間長，也會影響并發(fā)性能。
所以 Saga 模式的適用場景是：

• 業(yè)務流程長、業(yè)務流程多；

• 參與者包含其它公司或遺留系統(tǒng)服務，無法提供 TCC 模式要求的三個接口。

優(yōu)勢

• 一階段提交本地事務，無鎖，高性能；

• 參與者可異步執(zhí)行，高吞吐；

• 補償服務易于實現(xiàn)，因為一個更新操作的反向操作是比較容易理解的。

缺點

• 不保證事務的隔離性。

可靠消息最終一致性

流程

1. A 系統(tǒng)先發(fā)送一個 prepared 消息到 mq，如果這個 prepared 消息發(fā)送失敗那么就直接取消操作別執(zhí)行了；

2. 如果這個消息發(fā)送成功過了，那么接著執(zhí)行本地事務，如果成功就告訴 mq 發(fā)送確認消息，如果失敗就告訴 mq 回滾消息；

3. 如果發(fā)送了確認消息，那么此時 B 系統(tǒng)會接收到確認消息，然后執(zhí)行本地的事務；

4. mq 會自動定時輪詢所有 prepared 消息回調你的接口，問你，這個消息是不是本地事務處理失敗了，所有沒發(fā)送確認的消息，是繼續(xù)重試還是回滾？

   一般來說這里你就可以查下數(shù)據(jù)庫看之前本地事務是否執(zhí)行，如果回滾了，那么這里也回滾吧。

   這個就是避免可能本地事務執(zhí)行成功了，而確認消息卻發(fā)送失敗了。

5. 這個方案里，要是系統(tǒng) B 的事務失敗了咋辦？

   重試咯，自動不斷重試直到成功，如果實在是不行，要么就是針對重要的資金類業(yè)務進行回滾，比如 B 系統(tǒng)本地回滾后，想辦法通知系統(tǒng) A 也回滾；

   或者是發(fā)送報警由人工來手工回滾和補償。

6. 這個還是比較合適的，目前國內互聯(lián)網(wǎng)公司大都是這么玩兒的，要不你就用 RocketMQ 支持的，要不你就自己基于類似 ActiveMQ？

   RabbitMQ？

   自己封裝一套類似的邏輯出來，總之思路就是這樣子的。

下單為例

以下單為例

1. 訂單系統(tǒng)把訂單消息發(fā)給消息中間件，消息狀態(tài)標記為“待確認”。

2. 消息中間件收到消息后，進行消息持久化操作，即在消息存儲系統(tǒng)中新增一條狀態(tài)為“待發(fā)送”的消息。

3. 消息中間件返回消息持久化結果（成功 / 失敗），訂單系統(tǒng)根據(jù)返回結果判斷如何進行業(yè)務操作。

   失敗，放棄訂單，結束（必要時向上層返回失敗結果）；

   成功，則創(chuàng)建訂單。

4. 訂單操作完成后，把操作結果（成功 / 失敗）發(fā)送給消息中間件。

5. 消息中間件收到業(yè)務操作結果后，根據(jù)結果進行處理：

   失敗，刪除消息存儲中的消息，結束；

   成功，則更新消息存儲中的消息狀態(tài)為“待發(fā)送（可發(fā)送）”，并執(zhí)行消息投遞。

6. 如果消息狀態(tài)為“可發(fā)送”，則 MQ 會將消息發(fā)送給支付系統(tǒng)，表示已經(jīng)創(chuàng)建好訂單，需要對訂單進行支付。

   支付系統(tǒng)也按照上述方式進行訂單支付操作。

7. 訂單系統(tǒng)支付完成后，會將支付消息返回給消息中間件，中間件將消息傳送給訂單系統(tǒng)。

   訂單系統(tǒng)再調用庫存系統(tǒng)，進行出貨操作。

最大努力通知方案

這個方案的大致意思就是：

1. 系統(tǒng) A 本地事務執(zhí)行完之后，發(fā)送個消息到 MQ；

2. 這里會有個專門消費 MQ 的最大努力通知服務，這個服務會消費 MQ 然后寫入數(shù)據(jù)庫中記錄下來，或者是放入個內存隊列也可以，接著調用系統(tǒng) B 的接口；

3. 要是系統(tǒng) B 執(zhí)行成功就 ok 了；

   要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務就定時嘗試重新調用系統(tǒng) B，反復 N 次，最后還是不行就放棄。

總結

一般來說，最嚴格的就是TCC。其他常用的是基于消息的最終一致性。

ACID

Base理論

BASE 理論包括基本可用（Basically Available）、柔性狀態(tài)（Soft State）和最終一致性（Eventual Consistency）。

• 基本可用：

  分布式系統(tǒng)出現(xiàn)故障的時候，允許損失一部分功能的可用性。

  比如，某些電商 618 大促的時候，會對一些非核心鏈路的功能進行降級處理。

• 柔性狀態(tài)：

  在柔性事務中，允許系統(tǒng)存在中間狀態(tài)，且這個中間狀態(tài)不會影響系統(tǒng)整體可用性。

  比如，數(shù)據(jù)庫讀寫分離，寫庫同步到讀庫（主庫同步到從庫）會有一個延時，其實就是一種柔性狀態(tài)。

• 最終一致性：

  事務在操作過程中可能會由于同步延遲等問題導致不一致，但最終狀態(tài)下，數(shù)據(jù)都是一致的。

可見，BASE 理論為了支持大型分布式系統(tǒng)，通過犧牲強一致性，保證最終一致性，來獲得高可用性，是對 ACID 原則的弱化。具體到今天的三種分布式事務實現(xiàn)方式，二階段提交、三階段提交方法，遵循的是 ACID 原則，而消息最終一致性方案遵循的就是 BASE 理論。