在解耦系统之间同步数据的最佳方式是什么？答案

【问题标题】：What's the best way of synchronizing data between decoupled systems?在解耦系统之间同步数据的最佳方式是什么？
【发布时间】：2010-09-27 00:51:14
【问题描述】：

我假设有 2 个（但将来会变得更多）完全解耦的系统：系统 A 和系统 B。

假设每个系统上的每条信息都有一个 informationID。没有什么可以阻止 informationID 在不同系统上相同。在所有系统中唯一标识一条信息的是 Source-informationID 对。

假设我需要将一条信息从系统 A 导出到系统 B。然后我想从系统 B 导出相同的信息并将其重新导入系统 A，我需要能够识别这是相同的信息。

根据人们的经验，最好的方法是什么？

这是我想做的：

设置消息总线之间具有消息队列的系统。
为每个系统设置端点这将监控变化和生成包裹在将被抽出的消息进入队列（例如当一条信息是创建/删除/更新）。
为端点分配等级相对于创建/删除/更新命令，以便不依赖系统名称，但仅限于一般层次结构——使每个系统不需要知道其他人。
在更新/删除/创建每个命令端点，使命令不满足门槛要求将被过滤掉而不是已处理

这并不能解决我仍然需要携带 originalSource+originalSourceID 的事实。

任何帮助表示赞赏。

【问题讨论】：

我猜“相同”的信息是可以更改的，否则，您不需要重新导入它，对吗？
是的，它可以在任何地方编辑创建删除 - 但我需要跟踪什么是什么

标签： synchronization eai application-integration

【解决方案1】：

正如有人已经写过的，这听起来像是一个典型的 EAI 问题。即使 EAI 工具过去很昂贵，现在也有多种免费的开源工具可供选择。下面是我最喜欢的列表

我最喜欢的是 OpenESB，我最了解它，它有一个完整的 IDE (Netbeans)、来自大供应商的可选支持和 huge amount of additional components。由于它的简单性和有效性，我喜欢 Apache Camel，但您可以尝试其中的一些并决定哪一个更适合您。然后，您甚至可以决定为所有这些购买支持服务。

【讨论】：

【解决方案2】：

Tibco 和 webMethods（现在是 Software AG 的一部分）等 EAI（企业应用程序集成）供应商已经解决了这个问题。我以前从未使用过 Tibco，但我使用 webMethods 来解决这类问题，所以我将只关注 webmethods。例如，在企业中，有关员工的数据可能同时存在于 Active Directory 和 PeopleSoft 中。 webMethods 可用于确保一个系统（应用程序）中的更改、添加、删除将实时反映在另一个系统（应用程序）中。在其他一些组织中，有关员工的数据也可能位于 Oracle 或 SQL Server 数据库中。再次，不是问题。这些 EAI 工具（如 webMethods）可以与各种后端通信。 webMethods 并不局限于单一来源和单一目标，而是因为它具有发布-订阅架构，来自单一来源的数据可以流向订阅特定信息的多个感兴趣的目标。在这些产品中可以找到保证交付和可能的其他功能。回到员工的例子，最终，如果做对了，在任何给定时间，企业中的所有系统和应用程序都可以包含有关员工的相同信息，而不会出现任何差异。

因此，您无需使用 C# 或 Java 进行编程，而是使用非常类似于 4GL 语言的 webMethods 编程。我称之为编程是因为仍然涉及逻辑、循环、if then else、分支、变量、包等，但它非常面向过程，即根本没有 OOP 的概念。

这些 EAI 工具的构建目的有限，其中一个目的是在企业中的不同系统之间轻松同步数据。他们做得很好。

缺点是这些工具要花很多钱。公司在投资这些工具之前通常有一个长期战略。

【讨论】：

【解决方案3】：

如果您为每条信息分配一个 GUID，这将大大简化。如果您需要跟踪源 ID 和其他 ID，这很好，但信息应始终使用其分配的 GUID。

当机器再次看到该信息时，它会看到 GUID 并将其与现有数据相关联，然后您可以决定要做什么。但您已经知道它是相同的数据片段 - 只是更好地旅行。

请记住，GUID 的创建方式是每台机器都将创建自己的 GUID，并且它们不会与在另一台机器上创建的 GUID 或同一台机器上不同的 GUID 冲突（出于所有实际意图和目的）时间。

这是创建 GUID 的重要原因之一。

-亚当

【讨论】：

听起来我的 GUID 可能是 source + sourceID

【解决方案4】：

我们正在做的事情几乎与您描述的 A -> B -> A 完全一样。我们最初考虑尝试让所有 A、B、C 等节点成为对等节点，但这太难了，所以我们现在指定一个为主节点，其他节点为副本。从一个副本到另一个副本仍然很容易，但要通过主副本。

这一切都是通过 Web 服务完成的 - 数据集从副本到主数据库上下移动，反之亦然，并且副本在其自身上运行导出，并在主数据库上调用导入。然后它告诉主节点进行导出，并自行运行导入。

所以每个系统上的代码都是相同的。只有复制品才是家。

导出和导入过程告诉相关业务对象完成所有列出和保存的工作，因为它们已经知道如何从 DataRows 实例化和持久化自己。

它不是每秒数十个事务的架构，但它可以工作，并且可以实现近乎实时的同步。

顺便说一下，我们还没有改进 Source/Id 的唯一性 :)

【讨论】：

听起来是个不错的选择 - 我主要担心的一个问题是 Source-Id 的唯一性！

【解决方案5】：

除非系统设计中存在某些特定限制以防止这种情况发生，否则我建议将共享/可共享信息分解到单独的数据库中，其他两个可以引用或仅在本地复制。那么你就不需要双元素密钥，也不需要任何复杂的 ESB 装置......

【讨论】：

这是 Big-DB 方法 - 这是我正在研究的一个选项。但它也有缺点，因为它很快就会变得混乱。