在当今时代，事务性编程已成为现代开发中的重要组成部分。并发和容错对于应用程序的寿命至关重要，并且正确的说，事务逻辑变得易于实现。但是，随着应用程序的增长，事务代码似乎在应用程序的可伸缩性上变得越来越繁重，并且当我们桥接到分布式事务和镜像数据集时，问题开始变得非常复杂。我很好奇在数据大小或者应用程序复杂性方面，事务经常开始成为问题的根源(导致超时，死锁，关键任务代码中的性能问题，等等)，这些问题更容易修复，排除故障或者解决方法，而不是设计本身更具容错能力的数据模型，或者使用其他方法来确保数据完整性。此外，哪些设计模式可用来最大程度地减少这些影响或者使标准的事务逻辑过时或者不可行？

--

编辑：到目前为止，我们已经收到了一些质量合理的答案，但我想我会自己发布一个答案，以提出一些我听说过的东西，以激发更多的创造力。我得到的大多数答复都是对该问题的悲观看法。

另一个重要的注意事项是，并非所有的死锁都是由于程序编码不佳造成的；有时，关键任务操作依赖于不同顺序的相似资源，或者依赖于彼此相邻的不同查询中的复杂联接；这个问题有时似乎是无法避免的，但是我已经参与了工作流程的重做工作，以促进不太可能引起执行顺序的执行顺序。

解决方案

回答

我认为没有设计模式可以自己解决这个问题。良好的数据库设计，良好的存储过程编程，尤​​其是学习如何使事务简短，可以缓解大多数问题。
虽然没有100％保证没有问题的方法。

基本上，在我职业生涯中遇到的每种情况下，都可以通过修复存储过程来解决死锁和速度变慢的问题：

• 确保按顺序访问所有表可防止死锁
• 固定索引和统计信息使一切变得更快(因此减少了死锁的机会)
• 有时并没有真正的交易需要，只是像它一样"看起来"
• 有时可以通过在单个语句中创建多个语句存储过程来消除事务。

回答

从长远来看，使用共享资源是错误的。因为通过重用现有环境，我们正在创造越来越多的可能性。只需查看繁忙的海狸:) Erlang的运行方式是生产容错和易于验证的系统的正确方法。

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

我认为monads是处理状态改变这一难题的一个很酷的概念。

回答

如果我们在这里谈论"云计算"，答案将是将每个交易本地化到云中发生交易的地方。无需使整个云保持一致，因为那样会降低性能(如我们所述)。简而言之，当更改通过系统传播时，请跟踪更改的内容以及更改的位置，并处理多个小事务。用户A更新记录R而用户B在云的另一端却看不到它的情况(至今)与用户A在当前严格事务环境中尚未进行更改时的情况相同。这可能会导致大量更新的系统出现差异，因此，系统的体系结构应尽可能少地进行更新，以便将事物移至数据的聚合，并在精确的数字至关重要时撤出聚合(即，从写入中移去对一致性的要求) -时间到临界读取时间)。

好吧，就是我的POV。在这种情况下，很难想象一个与应用程序无关的系统。

回答

尝试以最少数量的指令在数据库级别进行更改。

一般规则是锁定资源，以尽可能减少时间。使用T-SQL，PLSQL，Oracle上的Java或者任何类似的方法，我们可以减少每个事务锁定共享资源的时间。实际上，数据库中的事务已通过行级锁，多版本和其他种类的智能技术进行了优化。如果可以在数据库上进行事务，则可以节省网络延迟。来自ODBC / JDBC / OLEBD等其他层的Appart。

有时，程序员尝试获取数据库的优点(它是事务性的，并行的，分布式的)，但保留大量数据。然后，他们需要手动添加一些数据库功能。

回答

我听说过的一种方法是制作一个版本化的仅插入模型，该模型不会发生任何更新。在选择期间，版本仅用于选择最新的行。我知道这种方法的一个缺点是数据库可以很快变得很大。

我也知道某些解决方案(例如FogBugz)不使用强制外键，我相信这也将有助于缓解其中的一些问题，因为SQL查询计划可以在选择或者更新期间锁定链接表，即使其中没​​有数据更改它们，如果它是一个竞争激烈的表而被锁定，则可能会增加DeadLock或者Timeout的机会。

我对这些方法知之甚少，因为我从未使用过它们，所以我认为每种未知方法都有其优缺点，还有一些我从未听说过的其他技术。

我还一直在研究Carlo Pescio最近的帖子中的一些材料，不幸的是，我没有足够的时间对此进行公道，但是该材料似乎非常有趣。