分布式事務 - 為什么我們將tranlogs保存到文件系統？

Question

所有事務管理器（Atomikos，Bitronix，IBM WebSphere TM等）都將一些“事務日志”保存到文件系統的“tranlogs”文件夾中。

當一些可怕的事情發生並且服務器崩潰時，有時變更會被破壞。 它們需要一些手動恢復程序。

我被告知，通過簡單地清除已損壞的tranlogs文件夾，我冒着參與交易的資源狀態不一致的風險。

作為一個“愚蠢”的開發者，我對簡單的概念感到更舒服。 我想認為分布式事務管理應該與常規事務管理相似：

1. 如果在任何一方出現問題（網絡，應用程序錯誤，超時） - 我希望整個多資源事務不會在其任何部分提交。 應盡快清理所有剩菜。
2. 如果事務管理器出現故障（文件系統故障，電源故障） - 我預計此TM下的所有事務都將被回滾（顯然，在數據庫超時級別）。
3. 如果我不想進行任何自動TX恢復（無論它意味着什么），則tranlog的文件存儲是可選的。

問題

為什么我不這樣想？ 2PC有什么這么復雜的？

當我清除損壞的tranlogs時，確切的風險是什么？

如果我錯了，我真的需要所有混亂的2PC文件系統狀態。 TX經理是否能夠以簡單而丑陋的方式實際破壞存儲狀態這一事實，您是否感到惡心？

Answer 1

當我在1994年第一次面對現實生活中的2階段提交時（最初是在更大的Oracle7環境中），我有類似的初步反應。 通常不太可能使它變得簡單，這真是一種血腥的恥辱。 但回顧大學的算法書籍，很明顯2PC沒有通用的解決方案。

例如，請參閱如何在分布式環境中達成共識

當然，有許多特定情況可以解決事務的2PC提交更容易完成或完全回滾並且影響較小。 但是一般問題仍然存在，無法解決。

在這種情況下，交易經理必須在某個時間決定做什么; 交易不能永遠保持開放。 因此，作為最終解決方案，他們將始終需要返回到他們自己的交易日志，因為一個或多個其他方可能無法在不久的將來可靠地傳達狀態。 一些交易管理人員可能更高級，並且知道如何更輕松地解決某些案例，但仍需要最終的后備支持。

我很抱歉。 修復它通常似乎與二進制邏輯中的“Falsity暗示任何東西”相同。

總結

Why can't I think like this? What's so complicated about 2PC ：見上文。 這個算法問題無法普遍解決。

What are the exact risks when I clear broken tranlogs? ：事務管理器有一些數據庫支持它。 刪除translogs是一般關系數據庫軟件中的相同問題; 你發現正在進行的交易的信息。 某些數據庫平台仍然可以包含某些或大部分整數文件。 有關背景和一些數據庫理論， 請參閱Wikipedia 。

On Don't you feel sick about the fact that TX manager can actually break storage state in an easy and ugly manner? ：是的，有時當我必須完成團隊的大量工作時，我真的很討厭它。 但是，它讓我有一份工作:-)

增加：2PC或不

從您的添加中我了解到您在考慮是否在項目中包含2PC。

在我看來，您的里程可能會有所不同。 我們公司有2PC的政策：盡可能避免它。 但是，在某些環境中，尤其是遺留系統和復雜環境（例如銀行業中發現的環境），您無法解決這些問題。 客戶需要它，他們可能不願意允許您對其他基礎設施組件進行重大更改。

當你必須做2PC：做得好。 我喜歡軟件和基礎設施的簡潔架構，而且非常簡單，即使是5年后它也很清楚它是如何工作的。

對於所有其他情況，我們遠離兩階段提交。 我們有自己的框架（Invantive Producer），從客戶端到應用服務器到數據庫后端。 在這個框架中，我們選擇在正常工作在分布式環境中時犧牲ACID的元素。 應用程序開發人員必須注意自己的原子性。 通常這很簡單，甚至不需要考慮。 例如，所有軟件必須安全重啟。 即使有交易的原子性，這也需要一些思考才能在龐大的多用戶環境中做得很好（例如鎖定問題）。

一般來說，這種愚蠢的方法很容易理解和維護。 在我們被要求進行兩階段提交的情況下，我們已經能夠替換框架上的一些插件並對客戶端代碼進行一些更改。

所以我的建議是：

• 盡量避免使用2PC。
• 但很好地封裝了你的事務邏輯。
• 允許在沒有完全重建的情況下執行2PC，但只在需要的地方更改內容。

我希望這可以幫助你。 如果你能告訴我更多關於你的典型環境（#tables的大小，GB持久數據的大小，#concurrent用戶的大小，典型的事務管理軟件和平台），我可以做一些補充或改進。

增加：2PC中的電子郵件和避免消息丟失

關於是否建議DB與JMS結合：不，將DB與JMS結合起來通常沒有什么用處; 它本身已經有一些數據庫，因此有關事務日志的原始問題。

關於您的業務案例：我了解每個事件都會從模板發送電子郵件，並且外發郵件在數據庫中注冊為事件。

這是一個難以破解的難題; 我一直很享受安全審計，最簡單的安全問題之一就是檢查電子郵件的使用情況。

電子郵件 - 除了在明信片等大多數情況下不保密和防篡改之外 - 無法保證無需額外措施即可交付和/或閱讀。 例如，即使在您的郵件傳輸代理和收件人之間直接發送電子郵件，也可能會在沒有通知事務監視器的情況下丟失數據。 當涉及多個躍點時，甚至會變得更糟。 例如，每個MTA都有自己的排隊機制，“炸彈可以丟棄”，導致數據丟失。 但是你也可以想到垃圾郵件措施，錯誤的配置，郵件循環，意外刪除文件等等。即使你可以使用2PC注冊發送電子郵件而不丟失任何交易信息，這也絕對不知道是否電子郵件將全部到達，甚至可以跨越第一跳。

我工作的公司為項目驅動的業務銷售大型軟件包。 該軟件包具有集成的排隊機制，該機制還處理電子郵件事件。 現在通常與Exchange的大多數實現相結合。 幾個月我們遇到了一個很好的問題：交易開始，打開郵件渠道，郵件作為MTA發送到Exchange，注冊郵件已處理...事務中止，因為Oracle表空間已滿。 在下一次運行中，郵件再次傳遞到Exchange，再次中止，等等。此算法現在已得到增強，但從這個簡單示例中您可以看到您需要所有端點在您的2PC中進行協作，即使某些端點也是如此在收到並顯示您的電子郵件的組織中很遠。

如果您需要采取措施確保發送或閱讀電子郵件，則需要通過其他措施對其進行補充。 請從文獻中選擇一個應用程序控件，用戶控件和過程控件。