代码之家 › 专栏 › 技术社区 › TheXenocide

什么时候交易变得更像是负担而不是利益?

transactions design-patterns performance sql

TheXenocide · 技术社区 · 17 年前

在当今时代,事务性编程是现代开发的主要内容。并发性和容错性对于应用程序的寿命至关重要,因此,事务逻辑变得易于实现。但是,随着应用程序的增长,事务性代码对应用程序的可伸缩性的负担似乎越来越重,当您连接到分布式事务和镜像数据集时,问题开始变得非常复杂。我很好奇,在数据大小或应用程序复杂性方面,事务常常开始成为问题的根源(导致超时、死锁、任务关键代码中的性能问题等),这些问题更难解决,排除故障或解决方法,而不是设计本身更具容错性的数据模型,或使用其他方法确保数据完整性。另外,什么样的设计模式可以最大限度地减少这些影响,或者使标准事务逻辑过时或不存在问题?

——

编辑:到目前为止,我们已经得到了一些质量合理的答案,但我想我会自己发布一个答案,提出一些我听说的事情,试图激发一些额外的创造力;我得到的大多数回答都是对问题的悲观看法。

另一个重要的注意事项是,并不是所有的死锁都是由于编码不正确的过程造成的;有时有一些任务关键型操作以不同的顺序依赖于相似的资源,或者在 不同的 这是一个有时似乎是不可避免的问题,但我一直是重新设计工作流的一部分,以便于执行顺序不太可能导致一个。

5 回复 | 直到 7 年前

Sklivvz 17 年前

我认为没有设计模式可以解决这个问题本身。良好的数据库设计、良好的存储过程编程,特别是学习如何使事务保持简短,将缓解大多数问题。但是,没有100%的方法可以保证没有问题。

不过,基本上在我职业生涯中见过的每一种情况下,通过修复存储过程可以解决死锁和速度减慢的问题:

确保访问所有表以防止死锁
修正索引和统计数据可以使一切更快(因此减少了死锁的可能性)
有时没有真正的交易需要,它只是“看起来”像它。
有时,可以通过在单个语句中创建多个语句存储过程来消除事务。

Roman Glass 17 年前

从长远来看,使用共享资源是错误的。因为通过重用现有的环境,你正在创造越来越多的可能性。只需回顾一下繁忙的beavers:)erlang的方式是生成容错且易于验证的系统的正确方式。

但是事务内存对于许多广泛使用的应用程序来说是必不可少的。例如,如果你咨询一家拥有数百万客户的银行,你就不能仅仅为了效率而复制数据。

我认为单子是一个很酷的概念来处理改变状态的困难概念。

TheXenocide 17 年前

我听说过的一种方法是创建一个只插入版本的模型,在这个模型中永远不会发生更新。在选择期间,版本仅用于选择最新的行。我知道这种方法的一个缺点是数据库可以很快地变得相当大。

我也知道一些解决方案,比如FogBugz,不使用强制外键,我相信这也有助于减轻这些问题,因为SQL查询计划可以在选择或更新期间锁定链接表,即使其中没有数据改变,如果它是一个高度争用的表,它会增加死锁或超时的几率。

我对这些方法不太了解,因为我从来没有使用过它们,所以我假设每种方法都有我不知道的优点和缺点,以及一些我从未听说过的其他技术。

我也在查卡洛·佩西奥的资料 recent post 很不幸,我没有足够的时间做这件事,但是材料看起来很有趣。

Philipp 7 年前

如果你在这里说的是“云计算”,那么答案就是将每个事务本地化到它在云中发生的地方。

整个云不需要保持一致,因为这会降低性能(如您所述)。简单地说,当更改通过系统传播时,跟踪更改内容以及在何处处理多个小事务。

在云的另一端,用户a更新记录r和用户b的情况与用户a在当前严格事务环境中还没有进行更改的情况相同。这可能会导致更新繁重的系统中出现差异,因此系统的架构应尽可能少地使用更新—将数据移动到聚合中,并在准确的数字至关重要时(即将一致性要求从写入时间移动到关键读取时间)。

好吧,就我的观点。在这种情况下,很难设想一个与应用程序无关的系统。

DJo 1JD 7 年前

尝试在数据库级别以尽可能少的指令进行更改。

一般规则是在最短的时间内锁定资源。使用Oracle或任何类似的方式使用T-SQL、PLSQL、Java,可以减少每个事务锁定共享资源的时间。事实上,数据库中的事务使用行级锁、多版本和其他智能技术进行优化。如果您可以在数据库中进行事务,则可以节省网络延迟。除了其他层,如odbc/jdbc/olebd。

有时程序员试图获得数据库的好处(它是事务性的、并行的、分布式的),但却保留了大量的数据。然后他们需要手动添加一些数据库功能。