微服务中的分布式事务
我有两个微服务S1和S2S1调用S2来更新数据，然后S1插入另一个数据，但让我们考虑一下
我也经历了佐贺patterns.will它满足了这种矛盾
谁能为此提出更好的解决方案？
共有3个答案
如果S1和S2都“在您的控制下”，那么您最好以不需要分布式事务的方式设计它们。毕竟，微服务应该是独立的服务。如果它们必须共享事务，它们显然不是独立的。
如果其中只有一个在您的控制之下，而另一个不在您的控制之下，那么最简单的方法就是以一种不需要回滚不受您控制的服务的方式对调用进行排序。如果你幸运的话，你甚至可以以一种不需要任何回滚的方式进行调用，甚至在你的服务中也不需要。请记住，您不必解决一般的分布式事务，只需解决您所面临的实际用例即可！
我认为Saga模式(编排)使应用程序能够在不使用分布式事务的情况下跨多个服务维护数据一致性。
这种解决方案有以下缺点：
编程模型更复杂。例如，开发人员必须设计补偿事务，以显式撤消在传奇中早期所做的更改。
还有以下问题需要解决:
为了可靠，服务必须自动更新其数据库并发布事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。
分布式事务在大多数情况下都是有问题的，而且对服务不利
- 服务边界–服务边界是信任边界。原子事务需要持有锁并代表外部服务持有锁，这就打开了一个安全漏洞（使拒绝服务攻击变得更容易）。您不能假设两个不同实体或资源之间存在原子性。特别是当这些资源属于不同的企业时
- 事务引入了时间和操作的紧密耦合
- 事务阻碍了可扩展性–并不是你不能扩展，而是更难扩展
Sagas(顺便说一下，它不需要编排)作为协调的解决方案出现，因为它们允许服务更加灵活——并且事实上更接近真实生活的工作方式。另一个你可以和传奇结合来帮助延迟效果的模式是保留。
另一个选择可能是重新考虑如何划分服务。可能是您现在拥有的服务边界不正确，重新设计会将所需的事务包含到一个服务中
-
最近在学微服务的分布式事务，不太明白为什么在微服务这种分布式系统中，原有的单体acid会出现问题 希望大佬们可以讲一下原理和思想
-
我知道最好使用 Saga 模式，但想想还是很有趣的： < Li > 2PC/XA分布式事务是否提供了仅从一个应用程序和一个TM与多个RM进行事务的可能性？ < li >如果没有-如果每个微服务只能访问自己的数据库，如何在多个微服务之间使用2PC/XA分布式事务来提供使用2PC的能力？我很乐意看到一个例子 < li >我们是否需要将TransactionManager服务作为一个独立的微服务，在多个
-
得到了一个使用:< code>spring-boot、< code>spring-cloud、< code>postgresql作为微服务系统的项目。 有 2 个服务，比如 SA 和 SB，它们分别在 2 个 RDBMS 数据库上运行，比如 DA 和 DB。 现在，有一个包含2个子步骤的操作: Http客户端会向服务SA发出请求，将记录保存到中。 然后，SA向服务SB发送请求，将记录保存到中。 作
-
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
-
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致，支持 LOCAL，XA，BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务，默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
-
通过 Apache ShardingSphere 使用分布式事务，与本地事务并无区别。 除了透明化分布式事务的使用之外，Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置，缺省为 Apache ShardingSphere 启动时的默认事务类型。