Narayana/XA如何從TM故障中恢復？

Question

我試圖推斷可以由保證同步數據源的系統/框架採取的故障恢復操作。我一直無法找到Narayana恢復機制的明確解釋。

問題1：Narayana是否實質上採用兩階段提交來確保跨2個數據源的分佈式事務？問題2：有人可以在這種情況下解釋Narayana的行爲嗎？

1. 應用希望保存X到2個數據存儲
2. 納拉亞納的事務管理器（TM）產生一個事務ID和寫入信息到磁盤
3. TM現在發送準備消息給兩個數據存儲
4. 每個數據存儲迴應prepare_success
5. TM更新本地事務日誌並向兩個數據存儲發送提交消息
6. TM失敗（永久）。由於網絡丟包，只有一個數據存儲接收到提交消息。但其他數據存儲接收併成功處理提交消息。

兩個數據存儲現在彼此不同步（一個源有另一個不存在於另一個源中的事務）。

當一個新的TM出現時，它不能訪問舊的事務狀態記錄。因此，TM無法啓動在其中一個數據存儲中恢復丟失的事務。

那麼2PC/Narayana/XA如何聲稱他們保證可以保持2個數據存儲同步的分佈式事務呢？從我的立場來看，他們只能以極高的概率保持同步數據存儲，但他們無法保證。

問題3：另一個場景，我對應用程序/框架的行爲不清楚。

• 迪=數據源I
• TI =事務我
• PI =用於準備消息： - （具有部分重疊的一組記錄，或者至少兩個在相同的記錄）考慮以下交織交易交易i

D1收到P1;響應P1_成功

D2收到P2;響應P2_成功

D1收到P2;響應P2_failure

D2收到P1;響應P1_failure

網絡數據包到達不同數據源的順序可以確定哪個準備請求成功。這是否意味着在爭議性記錄的高交易速度下 - 所有交易都有可能失敗（直到記錄經歷較低的交易請求率）？

有人可能會爭辯說我們選擇的是可用性的一致性，但與ACID系統不同，不能保證至少有一個事務會成功（從而避免潛在的長時間死鎖）。

Answer 1

我想請您看看我的文章納拉亞納2PC如何工作 https://developer.jboss.org/wiki/TwoPhaseCommit2PC

您的問題

Q1：你已經提到，在註釋中 - 是的，納拉亞納使用2PC =納拉亞納實現XA規範（pubs.opengroup.org/onlinepubs/009680699/toc.pdf）。

Q2：場景中的步驟不準確。 Narayana在準備工作時寫入磁盤，而不是在交易開始時。

1. 應用保存X到2個數據存儲
2. TM現在發送準備消息給兩個數據存儲
3. 每個數據存儲返回響應與prepare_success
4. TM保存有關準備交易和其ID永久信息事務日誌存儲
5. TM發送一個提交消息，兩個數據存儲
6. ...

我不同意2PC聲稱保證保持2個數據存儲同步。 我也想知道這個（例如在這裏問https://developer.jboss.org/message/954043）。保證ACID特性的2PC聲明。同時擁有2個商店就是CAP一致性的一部分。

在這個Narayana嚴格依賴特定資源管理器（數據存儲或數據存儲的jdbc驅動程序）的功能。 ACID聲明

• 原子 - 整個事務被提交或回滾（當它發生時沒有任何信息，關於同步資源沒有資料）
• 一致性 - 之前在事務結束時，系統處於一致的狀態
• 耐用性 - 即使在發生崩潰時也會保存所有文件
• 隔離 - （最棘手的一個，最後留下） - 因爲是ACID，我們必須是可序列化的。這就是您可以觀察「一個接一個」發生的交易。 如果我拿一個簡單的例子來說明我的觀點 - 當事務開始時，期望DB以一種天真的方式鎖定整個數據庫 - 您提交了jms消息，這已經過處理，現在您不提交數據庫記錄。當DB工作在可序列化的隔離級別時（這就是ACID要求的！），那麼你的下一個寫/讀操作必須等待，直到解決了「飛行準備」事務。數據庫只是卡在等待。如果你讀了你不會得到答案，所以你不能說什麼是價值。 Narayana的恢復管理器在連接建立並提交之後來到準備好的事務。並且您讀取操作返回「正確」的信息。

Q3：我不明白這個問題，對不起。但是，如果你聲明The order in which the network packets arrive at the different data sources can determine which prepare request succeeds.那麼你是對的，那麼註定你的交易會失敗，直到網絡變得更加穩定。