事务处理最佳实践

Question

你在多大程度上依赖数据库事务？

你更喜欢小型还是大型事务范围？

你更喜欢客户端处理事务（例如 .NET 中的 TransactionScope）还是服务器端处理事务，或者两者都可以？

那么嵌套事务呢？

你有关于事务的一些提示和技巧吗？

在处理事务时遇到了什么坑点吗？

欢迎分享各种回答。

- aku

Answer 1

我总是在 using 语句中包装事务。

using(IDbTransaction transaction )
{
// logic goes here.
   transaction.Commit();
}

一旦事务超出范围，它就被处理。如果事务仍然处于活动状态，则会回滚。这种行为可以防止意外锁定数据库。即使抛出未处理的异常，事务仍将回滚。

在我的代码中，我实际上省略了显式的回滚，并依赖于 using 语句来完成工作。我只显式执行提交。

我发现这种模式极大地减少了记录锁定问题。

- Simon Johnson

Answer 2

个人而言，我在开发高流量性能的网站时，尽可能避免使用数据库事务。当然它们是必要的，所以我使用ORM和页面级对象变量来最小化我需要进行的服务器端调用次数。

嵌套事务是最大程度减少调用次数的绝佳方式，只要它们是快速查询且不会引起锁定问题，我就朝着这个方向前进。在这些情况下，NHibernate是一个救星。

- Sara Chipps

---

请帮我解码这个：“我正在避免交易”“但它们是必要的”“所以我使用ORM”。这三个有点像谜语——因为第一个陈述与最后一个相矛盾，或者我没理解到什么？ - maxkoryukov

Answer 3

我在每次向数据库写入操作时都使用事务。
因此，有许多小的“事务”包含在一个大的事务中，基本上嵌套代码中有一个未完成的事务计数。如果在结束父级时存在任何未完成的子级，则所有内容都会被回滚。

如果可以，在客户端处理事务更好。如果您被限制只能使用存储过程或其他服务器端逻辑单元，则服务器端事务也可以。

- ChanChan

---

客户端交易？！ - Totty.js

Answer 4

哇！好多问题！

一年前我完全依赖事务。现在只有98%。在高流量网站（如Sara提到的）和高分区数据的特殊情况下，需要分布式事务，可以采用无事务架构。现在你需要在应用程序中编写引用完整性。

此外，我喜欢使用注释（我是Java开发人员）和方面声明式地管理事务。这是一种非常干净的确定事务边界的方式，它包括事务传播功能。

- marcio

---

值得一提的是，在关系型数据库中，对于常规应用程序而言，最好使用事务。因为现在你必须在应用程序中编写引用完整性。这只是相同的事务（已经实现于数据库中），但对于具有复杂数据库的应用程序而言，它被优化用于特定任务（高速处理特定表格/或处理分片/副本）。 - maxkoryukov

Answer 5

提供一点信息… 嵌套事务可能是危险的。 它只是增加了死锁的机会。 因此，虽然它是好的和必要的，但在高并发情况下实现的方式非常重要。

- Oglester

Answer 6

服务器端事务，每秒35,000次交易，SQL Server：来自35K tps的10个教训

我们只使用服务器端事务：

• 可以晚启动并尽早完成
• 非分布式
• 可以在之前和之后执行工作
• SET XACT_ABORT ON意味着出现错误会立即回滚
• 客户端/操作系统/驱动程序不可知

其他：

• 我们嵌套调用但使用@@TRANCOUNT检测已经启动的TXNs
• 每个DB调用始终是原子性的

我们每天处理数百万条INSERT行（通过暂存表批量处理），完整OLTP，没有问题。不过不是35k tps。

- gbn

Answer 7

正如Sara Chipps所说，对于高流量应用程序来说，事务处理是过度的。因此，我们应该尽可能避免使用它。换句话说，我们使用BASE架构而不是ACID。eBay是一个典型的例子。在eBay架构中根本不使用分布式事务。但是对于最终一致性，您必须自己进行某种技巧处理。

- yanky