因此，在付款处理中，您有这种支付交易的概念。当支付或消息来自各种内部和外部接口时，可能会在某些关系数据库中的某个主要基本事务表中创建支付事务（至少为了这个问题）。然后，交易的某些状态会通过一系列修改而发生变化，直到达到几个最终状态（付费或未付，已批准或拒绝等）之一。
在处理数据库时，你当然有数据库事务，我的问题是，是否有关于在数据库事务中处理支付交易的任何经验法则？事务通常是聚合根许多其他表格，以获取有关参与该交易的客户或持卡人或商家或速度设置的信息。
我可以看到一条规则说，＆＃34;永远不会在数据库事务中处理多个支付交易＆＃34;。但是，在执行批处理类型操作时，我还可以看到数据库事务正确，当您必须考虑整批事务成功或失败时，您可以选择回滚。
答案 0 :(得分：1)
正常的设计模式是遵循以下规则：使用数据库事务将数据库从一个有效状态转换到另一个有效状态。
在支付交易的上下文中，可能意味着添加交易是一个数据库交易。然后，事务的每个处理步骤（如验证，履行......）将是另一个db事务。
我可以看到一条规则说，＆＃34;永远不会在数据库事务中处理多个支付交易＆＃34;
出于性能原因或架构原因，您可以将多个逻辑事务放入一个物理事务中。这不一定是个问题。但是，您需要确保工作不会丢失，因为失败将导致整个批次中止。