分布式事务 - 为什么我们将tranlogs保存到文件系统？

Question

所有事务管理器(Atomikos,Bitronix,IBM WebSphere TM等)都将一些"事务日志"保存到文件系统的"tranlogs"文件夹中.

当一些可怕的事情发生并且服务器崩溃时,有时变更会被破坏.它们需要一些手动恢复程序.

我被告知,通过简单地清除已损坏的tranlogs文件夹,我冒着参与交易的资源状态不一致的风险.

作为一个"愚蠢"的开发者,我对简单的概念感到更舒服.我想认为分布式事务管理应该与常规事务管理相似:

1. 如果在任何一方出现问题(网络,应用程序错误,超时) - 我希望整个多资源事务不会在其任何部分提交.应尽快清理所有剩菜.
2. 如果事务管理器出现故障(文件系统故障,电源故障) - 我预计此TM下的所有事务都将被回滚(显然,在数据库超时级别).
3. 如果我不想进行任何自动TX恢复(无论它意味着什么),则tranlogs的文件存储是可选的.

问题

为什么我不这样想？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:见上文.这个算法问题无法普遍解决.

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中进行协作,即使某些端点也是如此在收到并显示您的电子邮件的组织中很远.

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