应用程序架构 - 您将如何设计此过程

Question

我有一个由以下内容组成的应用程序：

包含100k +记录的中央数据库 许多“客户”数据库，每个数据库包含大约10-20k记录

客户端数据库包含每个都具有唯一ID（contactID）的联系人的详细信息 中央数据库包含由同一contactID标识的一些联系人。

一夜之间我们需要遍历客户端数据库，查询中央数据库以获取每个联系人的更新，然后将其带入客户端数据库。
中央数据库由第三方持有，因此我们无法改变任何内容。
持有中央数据库的公司希望通过遍历每个联系人的Web服务来执行此操作。

我担心的是，考虑到记录的数量，这对于Web服务来说是非常缓慢的。

目前我正在考虑在每个客户端上生成一个文件，其中包含该客户端的所有联系人列表。然后将其发送到中央数据库。然后，中央数据库将处理此文件并发回包含所有更新的另一个文件。

您如何创建它以便尽可能快地运行？

Answer 1

我不会查看您描述的场景中的每条记录。 Web服务很好，但您可以轻松地将它们用于批量更新。

从我的头脑中，这样的事情会更好一点：

1. 获取包含master数据库中所有更改的' diff '。这可以在同步开始之前完成，并且每天只需要完成一次。
2. 从客户端向服务器发送完整的联系人列表。有一个大的列表并不重要它如何发送，但如果你不喜欢SOAP Web服务考虑JSON。为方便起见，我会选择网络服务。同样，联系人列表可以提前准备。
3. 通过将“ diff ”与客户列表进行比较，创建需要更新的记录列表。
4. 一次性获取所有更新的详细信息（如果使用MS SQL，则可以使用XML执行此操作，其他SQL服务提供不同的路径）
5. 将详细信息发送给客户

同样的机制只能用于更新一条记录，你只需要在p.2中使用不同的列表（包含1个ID）

Answer 2

由于您受到第三方的限制，您可能希望执行以下操作之一：

1. 让第三方创建一个Web服务，该服务返回所有ID的列表，其中包含最近一天更改的详细信息。

2. 然后，您使用Web服务（希望比整个列表小得多）遍历此缩减列表，并根据需要更新您的联系人。

或

1. 让第三方创建一个包含xml文档的Web服务，该文档包含系统中已在特定时间段内更改的联系人详细信息的转储。 然后，您将处理此文档，更新您的详细信息。

Answer 3

尽可能使用批量转移。

打开TCP / IP连接是一个非常缓慢的过程。在单个WS请求中传输20K联系ID（即使ID很大）比20K Web服务请求快得多。

您不想等待他们回复。您有两种潜在的工作流程。

1. 忙碌等待。您发送批次。您每隔几分钟轮询一次，直到完成批处理。这是相当狡猾的，但完全是片面的。你做了所有的工作，他们只是回答“尚未完成”或“完成”。然后您请求批量结果。

2. <强>通知即可。您发送一个批次，包括一些可以通知您的地址。它可能是一个电子邮件地址，也可能是您想要通知的URL（IP地址，端口和路径）。

   • 如果您选择使用电子邮件（或类似）通知，则可以执行正确的WS请求以检索批次。

   • 如果您选择使用WS通知，您将拥有一个小型Web服务，该服务可以获得简单的通知，并执行WS请求以获取结果，或者它们会向您发送整个结果。

     < / LI>

3. 如果你想要粗鲁，打开几百个线程并发出几百个并发请求。这将花费更少的时间，但会淹没他们的服务器。

Answer 4

您可以要求提供包含来自中央数据库的所有ID详细信息的文件（XML），您可以将其转换为某些对象映射。 然后在您的最后有对象列表，您可以相应地进行比较和更新。

Answer 5

消息怎么样？在中央数据库端，可以创建用于存储db记录更新事件的消息传递队列系统，并且每个客户端数据库可能有一个主题，以便客户端只能订阅那些有趣的事件。该队列将负责通知客户端记录更新事件。