每当实体在应用程序中更新时更新另一个数据库的高效设计

Question

我有一个使用orientdb（DB＃1）作为数据库的应用程序（App A）。现在我们正在开发另一个使用PostgreSQL（DB＃2）作为数据库的应用程序（App B）。

我们现在有一个要求，我们需要在应用'B'中列出应用'A'的几个实体，并允许用户在应用B中修改这些实体。对应用'A'的实体执行的所有更改app'B'应该反映在DB＃1中。在与团队内部进行一系列讨论之后，我们确信将所需的实体数据从db＃1一次迁移到db＃2，然后使用在db＃1中创建/更新的记录动态更新DB＃2，反之亦然。有人可以建议保持db＃1和db＃2同步的有效方法吗？

注意：

1. 我们对实时同步db＃1和db＃2不感兴趣，最终的一致性对我们来说很好。
2. Orientdb提供2种钩子 动态钩子（https://orientdb.com/docs/last/Dynamic-Hooks.html），它在模式级别工作，而不是跨数据库。 Java钩子（https://orientdb.com/docs/last/Java-Hooks.html），它要求你创建一个jar并将它放在orientdb的lib文件夹中。我们排除了这个选项，因为我们有多个orientdb实例在不同的区域运行，这意味着每次我们更新jar时我们都需要更新在oriendb和调试的所有实例中都很困难，因为这个jar作为oriendb中的子进程运行。

我们考虑的一些方法：

1. 每当用户在应用程序'A'中创建/更新实体时，在db＃1中创建/更新相应的记录，并且一旦我们在db＃1中更新它，在应用程序层（java）中，将等效的Postgres sql查询推送到将db＃2中的记录更新为持久队列，并异步处理这些消息，反之亦然

Answer 1

这是一种在微服务架构中出现的经典模式，其中每个微服务应用程序都有自己的数据库，然后需要将该数据传递给其他服务。有多种方法：

1. App A直接更新App B使用的数据库。
2. App A调用App B公开的Web服务，然后该Web服务更新App B使用的数据库。

上述两种方法都导致App A和B之间的紧密耦合，这是不好的。如果App B使用的数据库模式发生变化，则App A也需要在上述两种方法中进行更新。

相反，现代世界中应用程序之间进行数据集成的标准和推荐方法是使用持久性队列，例如Kafka。在这种情况下，只要App A收到数据更新，它就会将事件推送到带有数据的Kafka队列，并且它不关心App B是否接收到它。应用B订阅队列，当它收到App A推送的事件时，它会更新自己的数据库。

通过这种方法，两个应用程序都非常松散耦合。维护这种Kafka基础架构需要一定的开销，但从长远来看，如果应用程序将变得更大，它是值得的。如果Kakfa完全不是一个选项，那么方法2（通过webservices）比方法1或其他集成机制更好。

希望这可以帮助。

Answer 2

您也可以考虑使用基于“change data capture”方法的解决方案和debezium等外部工具。

原理是将某些内容插入到数据库的bin日志中，这将触发数据更改的事件，然后您将实现负责复制第二个DB中的更改的侦听器。这种方法避免明确地耦合不同的应用程序。