分布式 SQL 工具是否可以用作分布式事务协调的两阶段提交或 sagas 模式的替代方案？

Question

我目前正在阅读微服务模式，它说分布式事务主要有两种方法：两阶段提交（2PC）和sagas模式。

此外，我听说了目前正在发展的分布式SQL（DSQL）工具，如CockroachDB、YuGabyteDB和YDB，它们还通过自己的低级db节点通信支持分布式ACID类事务。

那么问题是，后者是否可以作为前者的替代方案？

为了说明这个问题，考虑以下典型的微服务分布式事务示例。这里我们需要2PC或sagas来进行红色区域协调。

我想要的是完全消除从业务逻辑方面开发和支持协调的需要，将其移动到通用 DSQL 引擎：

一方面，很明显，这种方法以某种方式打破了微服务的责任分离原则。此外，据我了解，DSQL 工具主要针对复制/分片任务而发展，而不是用于微服务的业务逻辑协调。另一方面，它将大大简化开发和支持此类解决方案的过程。

Answer 1

在微服务架构中拥有独立的数据库有几个不同的好处。通过使用分布式数据库可以避免一些问题——CockroachDB的弹性、可伸缩性和动态负载平衡意味着您通常不需要担心将数据库调整为单个服务的工作负载。但其他人则不然。拥有独立的数据库迫使您的服务通过定义良好的API进行交互，这可以防止它们的逻辑紧密耦合，从而允许它们独立开发和更新。如果您使用共享数据库来实现一致性，那么无论采用何种机制，您都必须引入逻辑耦合，因为您需要对需要一致性的内容有一个共同的理解。这可能是不可避免的，在这种情况下，关键是使一致性逻辑变得明确易读，这在Raft级别实现时可能比在API中实现时更棘手。

Answer 2

我认为这取决于你想分离什么。对于分布式SQL数据库，一个数据库上的许多操作不会影响同一集群中的其他数据库。比如滚动升级(相对于单一数据库，您必须关闭共享同一个数据库的所有应用程序)、纵向扩展、横向扩展。

您还可以在同一个集群中，将节点专用于特定的应用程序。或者将它们移动到不同的区域。借助PostgreSQL兼容性，您可以使用相同的数据库为许多用例（关系、JSON、键值、时间序列…）提供服务。对于这些，您可以从共享相同的基础架构、管理服务提供商、技能中受益…并且仍然解除应用程序的耦合。

由于需要解耦更多，比如异步复制，YugabyteDB 具有 xCluster 复制。而且，在SQL层中，应用程序和数据之间可以进行许多级别的协调。PostgreSQL兼容性附带触发器，可以调用外部操作，或者外部数据包装器，可以使用标准API与其他数据库进行交互。

因此，我认为分布式数据库在解耦一切(如数据库供应商的选择)和影响应用程序的完全整合之间带来了更多可能性。