没有事务处理的日子(草译)

本文由  外刊IT评论     组织翻译


没有事务处理的日子

 

在 Transactionless  这篇blog中,Martin Fowler 对eBay的架构师DanPritchett最近的一次关于为什么eBay的架构师并不十分依赖数据库事务处理的演讲发表了评论. ebay的数据的完整性是由应用层代码完成的. Fowler 指出.

不用事务管理的根本原因是它在某种程度上损耗了eBay的处理效率. 这种影响因为eBay非常大量的将它们的数据分割在很多很多的物理数据库里的事实而变得更加恶化. 结果就是使用事务管理就意味着要使用分布式事务管理,这向来就是需要谨慎的事情.

这种大量的分割,以及在性能问题上,让数据库扮演主要角色的做法意味着eBay不能够使用许多的其他的数据库工具.相关的完整性和数据的排序全是用应用层代码完成的. 它们几乎不能用到trigger和存储过程.

Fowler不加思索的指出事务处理是一个非常有用的数据管理工具,而且指出:

没有人想要把事务处理从工具里排除掉. 我没有足够的关于eBay的详细信息让我来判断放弃事务的对于eBay来说是正确的做法. 但是eBay的例子让我们明白,没有事务管理的日子并不是像人们想象的那样不可能.

除了成为一个我们值得考虑的一种替换方案的事实外,它也是一个例子表明非事务处理的方式的使用要比人们平时所认为的更加常见. 业务需要分多步走,而且和多个资源相关,而且时长时间的分布事务,或是资源不支持事务,这样的事情是常见的.

根据Fowler's blog写的,在应用层里控制数据的完整性需要非常的小心,还需要许多额外的代码:

你需要加倍小心你提交的顺序,让最重要的放在最前面. 每一步提交你都要检查是否提交成功了,如果失败了如何处理.

当开发人员观察放大企业应用程序时,经常会发现数据层是最终的瓶颈. 目前好像是出现了两种途径去提高数据库层: In-memory, distributed caches,such as Tangosol's Coherence and JBoss Cache, 和把大数据库分割成许多小的数据库,在这些数据库中横向的反数据集群.

在第一种方法中,缓存成了应用程序的主要持久数据目标了. 许多的缓存解决方案提供了他们自己的API,通过这些API,他们绕过了传统的企业数据管理接口,例如JDBC和J2EE事务管理.

非集群的数据库,在另一方面,需要应用程序管理多个数据库连接,很可能要依赖分布式事务管理来确保这些跨越数据库的操作的成功.分布式事务处理--特别是分布式事务处理的协调者,就成了又一个瓶颈和失败点,而且可测量性也有限. 就像Fowler的文章指出的,分布式数据库中利用应用程序协调跨越数据库的工作可以增加可测量性.

在你的应用中,你是如何避免让数据库成为一个(single point of failure??)个别的失败和可测量到的瓶颈的? 对Fowler的博客里描述的非事务处理类型的应用的你是如何考虑的?

像银行转帐，可以简单的用事务来解决
不用的话，就得需要很多代码来保证一致性，恐怕数据库也需要额外的字段

到了ebay那种级数的应用，不管什么手段，能解决问题就好
要是大多数应用都这么处理，那就是跟自己过不去了