如何设计一个pub-sub系统，同一实体可以有多个发布者？

Question

考虑以下情况：

1. 有一个用户表，其中包含姓名，电子邮件，contact_no等字段。
2. 我们有多个产品/系统（有自己的数据库），它们将用户信息用于各种目的。
3. 这些系统通过pub-sub模式保持同步，例如：系统1更改名称由系统2消耗并在系统2中进行更改。
4. 为简单起见，我们假设有3个系统： S1具有用户的UI。用户可以在这里自己更改信息。 给予销售人员的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，它将成为每个系统的单点数据源。

如果任何系统想要更改数据，则数据首先需要在主Db /系统上更新，然后它应传播到其他系统以反映更改。

对于Pub-Sub，我将遵循Fan-IN和扇出方法。

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

这样，您就可以实现系统之间的数据一致性。只有你需要注意的是这个过程的延迟，如果任何系统出现故障，可能会出现这种情况。

希望我已经回答了你的问题。

Answer 3

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

在更新条目之前，所有系统都应联系此主要来源（对于名称，电子邮件和联系电话等字段）

• 如果该主要源表中已有条目，则需要验证哪个是最新的。如果它们是较新的条目，则需要提醒用户相同记录中发生了一些最新更新，您是否仍想更新它。
• 如果没有条目，则可以使用新数据轻松更新数据，并在这些主要源表中插入一个条目。

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