支付交易与数据库交易答案

【问题标题】：Payment Transactions vs Database Transactions支付交易与数据库交易
【发布时间】：2016-03-17 10:33:42
【问题描述】：

所以在支付处理中，你有支付交易的概念。当支付或消息来自各种内部和外部接口时，支付交易被创建，可能在一些关系数据库的一些主要基础交易表中（至少为了这个问题）。然后，交易的某些状态会通过一系列编辑而发生变化，直到达到几种最终状态（已付款或未付款、批准或拒绝等）中的一个。

在处理数据库时，当然有数据库事务，而我的问题是，在处理数据库事务中的支付事务是否有任何经验法则？事务通常是聚合根到许多其他表格，以获取有关参与该交易的客户或持卡人或商家或速度设置的信息。

我可以看到一条规则说，“永远不要在数据库交易中处理多个支付交易”。但是在执行批处理类型的操作时，我也可以看到数据库事务是正确的，当您必须考虑整批事务成功或失败时，您可以选择回滚。

【问题讨论】：

【解决方案1】：

正常的设计模式是遵循以下规则：使用数据库事务将数据库从一种有效状态转换为另一种。

在支付交易的上下文中，这可能意味着添加交易是一个数据库交易。然后，事务的每个处理步骤（如验证、履行等）都将是另一个数据库事务。

我可以看到一条规则说，“从不处理数据库交易中的多个支付交易”

出于性能原因或架构原因，您可以将多个逻辑事务放入一个物理事务中。这不一定是个问题。不过，您需要确保工作不会丢失，因为失败会中止整个批次。

【讨论】：

这是有道理的，可以帮助我将其可视化，谢谢...并且完全了解批次。事实上，很多时候都希望在遇到一个错误（特别是某种数据处理或格式错误）时使整批事务失败。如果我不能信任（通常是外部准备的）批次中的一个项目中的信息，我就会失去对整个批次的信任。