Database 分布式事务-为什么要将事务日志保存到文件系统？

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

当一些可怕的事情发生，服务器宕机时，传输日志有时会被破坏。 它们需要一些手动恢复程序

有人告诉我，通过简单地清除断开的tranlogs文件夹，我就有可能使参与事务的资源状态不一致

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

如果任何一方出现问题（网络、应用程序错误、超时），我希望整个多资源事务不会在其中的任何部分提交。所有的剩菜都应该早晚会自动清理干净

如果事务管理器出现故障（文件系统故障、电源设备故障），我希望回滚此TM下的所有事务（显然是在DB超时级别）

如果我不想有任何自动TX恢复（无论它意味着什么），tranlogs的文件存储是可选的

问题

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

当我清理破损的运输日志时，具体的风险是什么

---

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

当我在1994年第一次面对现实生活中的2阶段提交时（最初在一个更大的Oracle7环境中），我也有类似的最初反应。这是多么可耻的事情啊，一般来说不可能把它简单化。但回顾大学的算法书籍，很明显2PC并没有通用的解决方案

例如，见

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

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

我为你感到抱歉。修复它通常似乎与二进制逻辑中的“虚假意味着任何东西”相同

总结 关于

为什么我不能这样思考？

和

2PC有什么这么复杂的

：见上文。这个算法问题不能普遍解决

在

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

：事务管理器有一些数据库支持它。删除translogs在一般关系数据库软件中也是同样的问题；您丢失了有关正在处理的事务的信息。一些db平台仍然可以有一些或大部分整数文件。对于背景和一些数据库理论

在

上，TX manager实际上可以以一种简单而丑陋的方式破坏存储状态，您不觉得恶心吗？

：是的，有时当我必须让团队完成大量工作时，我真的很讨厌它。但是，它让我有了一份工作：-）

添加：是否添加到2件 从您添加的内容中，我了解到您正在考虑是否在项目中包含2PC

在我看来，你的里程数可能会有所不同。我们公司对2PC的政策是：尽可能避免。但是，在某些环境中，尤其是在遗留系统和复杂环境中，如银行业务中的系统，您无法解决此问题。客户需要，他们可能不愿意让您对其他基础设施组件进行重大更改

当你必须做2件事时：做好。我喜欢一个干净的软件和基础设施架构，它是如此简单，甚至从现在起5年后，它的工作原理都很清楚

对于所有其他情况，我们远离两阶段提交。从客户端到应用服务器再到数据库后端，我们都有自己的框架（Invantive Producer）。在这个框架中，我们选择在分布式环境中正常工作时牺牲ACID元素。例如，应用程序开发人员必须注意原子性。通常，这是可能的，几乎不需要努力，甚至不需要考虑。例如，所有软件都必须能够安全地重新启动。即使事务具有原子性，这也需要一些思考才能在大规模多用户环境中做好（例如锁定问题）

一般来说，这种愚蠢的方法很容易理解和维护。在要求我们进行两阶段提交的情况下，我们只需要替换框架上的一些插件，并对客户端代码进行一些更改

因此，我的建议是：

• 尽量避免2便士
• 但是要很好地封装事务逻辑
• 允许在不进行完全重建的情况下执行2PC，但仅在需要时进行更改

我希望这对你有帮助。如果您能告诉我更多关于您的典型环境（表中的大小、GB持久数据中的大小、并发用户中的大小、典型事务管理软件和平台）的信息，我可以做一些补充或改进

另外：在2PC中发送电子邮件和避免信息丢失 关于是否建议DB与JMS结合：否，DB与JMS结合通常用处不大；它本身已经有了一些数据库，这就是事务日志的原始问题

关于您的商业案例：我了解到，每次活动都会从模板发送一封电子邮件，并且