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

Question

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

我们现在有一个要求，其中我们需要在应用程序“ B”中列出一些应用程序“ A”的实体，并且还允许用户修改应用程序B中的这些实体。对应用程序“”的实体执行的所有更改应用程序“ B”中的“ A”应反映在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 hooks（https://orientdb.com/docs/last/Java-Hooks.html），它要求您创建一个jar并将其放置在orientdb的lib文件夹中。由于我们有多个Orientdb实例在不同区域中运行，因此每次我们更新jar，我们需要在oriendb的所有实例中进行更新，并且调试可能很困难，因为此jar作为oriendb中的子进程运行。

我们考虑过的一些方法：

1. 无论何时用户在应用程序“ A”中创建/更新实体，都在db＃1中创建/更新相应记录，并在应用程序层（java）中在db＃1中对其进行更新，则推送等效的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。在这种情况下，只要应用程序A接收到数据更新，它就会将事件与数据一起推送到Kafka队列中，而不管应用程序B是否接收到它。应用程序B订阅了该队列，并在接收到应用程序A推送的事件时更新了自己的数据库。

通过这种方法，两个应用程序都非常松散地耦合在一起。维护此Kafka基础架构会有开销，但从长远来看，如果应用程序变得更大，则值得这样做。而且，如果完全不选择Kakfa，则方法2（通过Web服务）比方法1或其他集成机制要好。

希望这会有所帮助。

Answer 2

您还可以考虑将基于“ change data capture”方法的解决方案与debezium之类的外部工具一起使用。

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