如何设计一个发布-订阅系统，其中同一实体可以有多个发布者？

Question

请考虑以下情况：

1. 有一个User表，其中包含姓名，电子邮件，contact_no等字段。
2. 我们有多个产品/系统（具有自己的数据库），它们出于各种目的使用用户信息。
3. 这些系统通过pub-sub模式保持同步，例如：系统1更改名称由系统2使用，并在系统2中进行更改。
4. 为简单起见，我们假设有3个系统：
   具有用户界面的
   • S1。用户可以在这里自己更改其信息。
   给销售人员的
   • S2系统。用户可以在这里致电销售人员并更新他们的信息。
   • S3另一种产品，它将来自S1和S2的信息用于各种计算。

因此可以从S1和S2发布信息。

假设用户最初的名称为N1。

• 在时间t1，用户将名称从N1更新为N2。

• 在时间t1，销售人员将姓名从N1更新为N3。

• 现在，S1使用来自S3的事件，并将名称更新为N3。 S2消耗来自S1的事件，并将名称更新为N2。

• 在S3中，名称可以是N2或N3，取决于首先消耗哪个事件。

这导致了各个系统之间的大量数据一致性。

在理想的系统中，只有一个发布者，但是由于要求，我们不得不从“销售”面板中添加发布事件。可以采取什么措施来最大程度地减少数据不一致性？

Answer 1

问题似乎出在确定谁是用户数据的主控者，因为目前S3试图服务于两个主控者。

S1 --> S3
S2 --> S3

让S1成为用户数据的主数据，以便其他任何接受该数据的系统（例如S2）仅负责更新主数据。这样S3可以从单一来源（用户数据的主数据）获取用户数据。

       S1 --> S3
S2 --> S1 --> S3

主服务器负责使用和产生其拥有的数据。另一个系统可能会使用（甚至存储）相同的数据，但它们只能产生给主服务器。除了该数据的主数据外，任何系统都无法生成该数据不属于任何其他系统。

哪个系统是主系统并不重要，只要只有一个系统即可。只要有一个主服务器，存储多少数据副本的系统实际上并不重要。每个系统拥有一种类型的数据可能比单个系统拥有所有数据更具可伸缩性。

Answer 2

让我再改一下。

1. 您具有连接了独立数据库的多个系统。
2. 用户能够从任何系统更改数据
3. 用户应该看到任何系统上的数据已更改。

在这种情况下，我将使用Master DB / System，它将成为每个系统的单点数据源。

如果任何系统要更改数据，则数据1st需要在Master Db /系统上进行更新，则该数据应传播到其他系统以反映更改。

对于Pub-Sub，我将采用扇入和扇出方法。

1. 每个系统都将充当不同主题/频道的发布者和消费者。
2. 发布者（位于S1-SN上）会将更改推送到一个主题/渠道以进行类似的数据更改
3. 主数据库系统将侦听主题/频道，以从其他系统获取更改请求。它还将充当其他系统的发布者，在处理完该消息后，它将同一条消息推送到不同的主题/频道。
4. 消费者（位于S1-SN上）将收听主题/频道，以进行主数据库系统提出的类似数据更改。它将消耗该数据以更新自己的系统数据库以进行数据更改。

通过这种方式，您可以实现系统之间的数据一致性。您唯一需要注意的就是此过程中的延迟，如果任何系统出现故障，都可能会发生。

希望我能回答您的查询。

Answer 3

维护一张表以跟踪所有最新更新（最新的一天更新）。假设最终可以在几分钟之内通过pub / sub系统将所有更新传播到所有其他系统。

在更新条目之前（所有字段，例如姓名，电子邮件和联系电话），所有系统都应联系该主要来源

• 如果该主源表中已经存在一个条目，则需要验证 这是最新的。如果他们是较新的条目，则需要提醒用户 同一记录最近发生了一些更新，您仍然 要更新它。

• 如果没有条目，则可以轻松地使用新的 数据并将一个条目插入这些主源表中。

每当任何系统通过pub-sub处理更新时，只有在同一记录没有新的更新发生时，它才应该更新。