4

所有事务管理器（Atomikos、Bitronix、IBM WebSphere TM 等）都将一些“事务日志”保存到文件系统的“tranlogs”文件夹中。

当可怕的事情发生并且服务器宕机时，有时tranlogs会被破坏。他们需要一些手动恢复过程。

有人告诉我，只需清除损坏的 tranlogs 文件夹，我就有可能使参与事务的资源状态不一致。

作为一个“愚蠢”的开发人员，我对简单的概念感到更自在。我想认为分布式事务管理应该类似于常规事务管理：

  1. 如果任何一方出现问题（网络、应用程序错误、超时）——我希望整个多资源事务不会在它的任何部分提交。所有剩菜迟早都应该自动清理干净。
  2. 如果事务管理器失败（文件系统故障、电源故障）——我希望这个 TM 下的所有事务都被回滚（显然，在数据库超时级别）。
  3. 如果我不想进行任何自动 TX 恢复（无论这意味着什么），用于 tranlogs 的文件存储是可选的。

问题

为什么我不能这样想？2PC有什么复杂的？

当我清除损坏的传输日志时，确切的风险是什么？

如果我错了，我真的需要 2PC 文件系统状态的所有混乱。TX 管理器实际上可以以一种简单而丑陋的方式破坏存储状态，您不觉得恶心吗？

4

1 回答 1

7

1994 年，当我在现实生活中第一次遇到 2 阶段提交时（最初是在更大的 Oracle7 环境中），我最初的反应类似。真是太可惜了，通常不可能让它变得简单。但是回头看大学的算法书，很明显2PC没有通用的解决方案。

参见例如如何在分布式环境中达成共识

当然，在许多特定情况下，事务的 2PC 提交可以更容易地完成或完全回滚，并且影响更小。但一般问题仍然存在，无法解决。

在这种情况下，事务管理器必须在某个时间决定要做什么；交易不能永远保持开放。因此，作为最终解决方案，他们总是需要返回自己的交易日志，因为现在和不久的将来，一个或多个其他方可能无法可靠地传达状态。一些事务管理器可能更先进，并且知道如何更轻松地解决某些情况，但最终回退的需求仍然存在。

我为你感到难过。修复它通常似乎与二进制逻辑中的“虚假暗示任何东西”相同。

总结

OnWhy can't I think like this?和What's so complicated about 2PC: 见上文。这个算法问题不能普遍解决。

On 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 中协作，即使某些端点远在接收和显示您的电子邮件的组织中。

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

于 2014-01-09T14:22:57.807 回答