我正在比较Saga和两阶段提交
我对2PC的分析是，如果在准备阶段我将数据保持在挂起状态，可以避免在事务中锁定，并在最后阶段提交我的更改。
显然，与Saga Pattern相比，成本是2倍，但在某些情况下2PC可能比Saga更有趣。
例如：作为交易的一部分，发送电子邮件，如果使用Saga，则无法恢复，万一失败，但是使用2PC，这是可能的（让我们假设这对于我的业务很重要。
我最后的疑问是，按照我上面的写法，是否有类似2PC的模式？否则，没有其他模式只是2PC的改编。
PS：在公开发表之前，我阅读了一些文章并研究了另一个问题。
两阶段提交协议/分布式事务的主要优势在于，除了征募额外资源和最终的准备/提交阶段（通常是多阶段）外，编程模型或多或少与本地事务模型等效。由框架处理）。 ACID属性仍然完全适用，并且数据一致性由基础结构而非开发人员处理。
一个主要缺点是就基础架构要求和组件故障而言，两阶段提交协议非常复杂。需要一个分布式事务管理器，以便将决策写入稳定的存储中，并且在组件发生故障的情况下，TM可以执行提交/回滚。准备好的事务可能涉及持有的锁，只要该事务尚未提交和/或回滚即可。这特别有问题，因为那些所谓的不确定事务必须由TM处理，这可能会导致严重的延迟，这可能会影响其他（甚至本地）事务和/或数据库内部管理后台进程。
性能是另一方面。根据写入流量，需要维护事务日志的事务管理器可能会成为瓶颈。
系统备份也变得更具挑战性。分布式事务的整个思想是数据库视图保持一致。如果进行备份，则除非您确保根据时间戳或更佳的是本地事务将每个数据库还原到特定的时间点，否则无法重新创建涉及的每个数据库的备份ID。这通常称为分布式时间点恢复，涉及阻止所有新的分布式事务，从每个单独的数据库中读取当前事务ID并将该信息与单独的备份一起存储。在还原时，可以根据记录的事务ID将数据库还原到时间点。此外，TM事务日志必须是备份策略的一部分。
Saga模式或补偿性交易未提供用于保证一致性的基础结构，编程模型必须考虑一致性问题。在分布式事务的情况下，金融事务将涉及一个分布式事务，该事务减去数据库A中的金额并增加数据库B中的金额，随着分布式事务的提交，其结果将变得可见。对于Saga交易或补偿交易，同一笔金融交易可能会在数据库A中创建一个新的未决交易记录，并在数据库B中创建一个未决交易记录，其结果将在确认这笔交易记录的两个单独交易中可见。
[通过许多方式，补偿交易通过要求编程模型处理一致性问题来模拟分布式交易。数据库模式必须通过将状态或版本信息与数据库对象/行相关联来考虑一致性，以再次创建完全或最终一致的数据库视图。所有这些都必须由开发人员（或框架，如果可用）完成，而不是数据库基础结构完成。
Saga和/或补偿性交易的购买是灵活性，因为可以根据所需的实际一致性约束来解决每个单独的一致性问题。通常，在每个使用案例中都不需要总的一致性。这可能意味着更高的性能和可伸缩性，因为一致性需求也可以扩展，并且通常不涉及集中式TM。它还可以提高基础结构方面的灵活性，因为所涉及的组件不必支持分布式事务（大多数NOSQL数据库不需要）。这直接影响可伸缩性，因为数据库的选择会影响所得系统的可伸缩性。通常可以在不涉及其他数据库的情况下创建备份，因为单个系统已经必须在更高层次上处理不一致问题。
分布式事务所需的紧密耦合会严重限制可伸缩性，性能和可用性。服务越大，使用分布式事务来保证所有组件的一致性的可能性就越小。许多大规模部署具有数百个微服务，这些微服务大多彼此独立，仅使用定义良好的API进行协作。服务A的可用性不一定会影响服务B，这是一件好事。替代地或除此之外，通常基于良好定义的标准（例如，客户广告，...）对这些微服务所操作的数据进行分区，以创建实际上可以作为一个单元进行管理并允许水平可伸缩性和高可用性的实例。 。在整个服务中使用分布式事务会破坏目的。