分布式事务 - 为什么我们将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中进行协作，即使某些端点也是如此在收到并显示您的电子邮件的组织中很远。

如果您需要采取措施确保发送或阅读电子邮件，则需要通过其他措施对其进行补充。 请从文献中选择一个应用程序控件，用户控件和过程控件。