我有一个使用orientdb(DB#1)作为数据库的应用程序(应用程序A)。现在我们正在开发另一个使用PostgreSQL(DB #2)作为数据库的应用程序(应用程序B)。
我们现在有一个要求，我们需要在应用"B"中列出应用"A"的一些实体，并允许用户在应用 B 中修改这些实体。在应用程序"B"中对应用程序"A"的实体执行的所有更改都应反映在数据库 #1 中。在与团队进行一系列内部讨论后，我们确信立即将所需的实体数据从数据库 #1 迁移到数据库 #2，然后使用在数据库 #1 中创建/更新的记录动态更新数据库 #2，反之亦然。 有人可以建议保持db #1和db #2同步的有效方法吗？
注意：
- 我们对实时同步 db #1 和 db #2 不感兴趣，最终一致性对我们来说很好。
- 东方数据库提供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 内部的子进程运行。
我们考虑的一些方法：
- 每当用户在应用程序"A"中创建/更新实体时，在数据库 #1 中创建/更新相应的记录，一旦我们在应用程序层 (java) 中的数据库 # 1 中更新它，推送等效的 Postgres sql 查询以将数据库 #2 中的记录更新到持久队列中并异步处理这些消息，反之亦然
这是微服务体系结构中出现的经典模式，其中每个微服务应用都有自己的数据库，然后需要将该数据传递给其他服务。有多种方法：
应用- A 直接更新应用 B 使用的数据库。 应用
- A 调用应用 B 公开的 Web 服务，然后该 Web 服务更新应用 B 使用的数据库。
上述两种方法都会导致应用程序 A 和 B 之间的紧密耦合，这并不好。如果应用 B 使用的数据库架构发生更改，则还需要在上述两种方法中更新应用 A。
相反，在现代世界中的应用程序之间进行数据集成的标准和推荐方法是使用持久队列，例如 Kafka。在这种情况下，每当应用 A 收到数据更新时，它都会将包含数据的事件推送到 Kafka 队列，并且不关心应用 B 是否收到该事件。 应用 B 订阅队列，当它收到应用 A 推送的事件时，它会更新自己的数据库。
使用这种方法，两个应用程序都非常松散地耦合。维护这个 Kafka 基础设施是有开销的，但从长远来看，如果应用程序要变得更大，这是值得的。如果 Kakfa 完全不是一个选项，那么方法 2(通过 Web 服务)比方法 1 或其他集成机制更好。
希望这有帮助。
您还可以考虑将基于"更改数据捕获"方法的解决方案与外部工具(如debezium)一起使用。
原则是将某些内容插入数据库的 bin 日志，这将触发数据更改事件，然后您将实现负责在第二个数据库中复制更改的侦听器。此方法避免显式耦合不同的应用程序。