支付事务与数据库事务

Question

所以在支付过程中，你有一个支付交易的概念。当支付或消息来自各种内部和外部接口时，就会创建支付事务，可能是在某些关系数据库中的某个主基础事务表中(至少为了这个问题)。然后，事务有一些状态，通过一系列编辑进行更改，直到到达几个最终状态中的一个(已支付或未支付、批准或拒绝等)。

在处理数据库时，您当然有数据库事务，我的问题是，对于处理数据库事务中的支付事务有什么经验规则吗？事务通常是许多其他表的聚合根，用于获取有关参与该事务的客户或持卡人或商人或速度设置的信息。

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

Answer 1

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

在支付事务的上下文中，这可能意味着添加事务是一个db事务。然后，事务上的每个处理步骤(比如验证、实现、.)将是另一个db事务。

我可以看到这样一条规则：“在数据库事务中，不要处理多个支付事务”。

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