在事件驱动的体系结构中将变更数据捕获与Debezium一起使用引起的不一致

如何解决在事件驱动的体系结构中将变更数据捕获与Debezium一起使用引起的不一致

我们一直在通过 Debezuim 和 Kafka 将更改数据捕获与发件箱模式结合使用在我们的事件驱动架构中的不同微服务之间同步。在早期阶段，我们面临的挑战之一是，如何确保数据库不会因Kafka不能保持跨多个分区的顺序而保持不同步。处理这种情况的方法是明智地选择分区键，以便与同一实体相关的所有事件都应基于分区键进入同一分区。因此，可以为同一实体保留订单。乍一看这很简单，但是要解决涉及两个不同实体的情况，似乎存在着根本性的挑战。由于我们只能有一个分区键，因此我们需要确定在选择分区键时可以考虑使用哪个实体。这是一个可能出问题的实际示例：

让我们假设有两个实体。 USER和WORKSPACE具有MxN关系。每个USER可以访问多个WORKSPACE，每个WORKSPACE可以被多个USER访问。因此，定义了三种不同的事件集来解决USER和WORKSPACE之间的关系：

• USER事件（CREATE，UPDATE和DELETE）
• WORKSPACE事件（CREATE，UPDATE和DELETE）
• USER-WORKSPACE事件（CREATE和DELETE）

因此，将WORKSPACE分配给USER时，可以生成三种类型的事件，如下所示：

• UPDATE USER
• UPDATE WORKSPACE
• CREATE USER-WORKSPACE

如果我们想为这些事件定义模式，将有两种方法：

1-当我们为一个关系事件定义模式时，我们需要使用两个事件的所有属性来使其保持独立。这意味着USER-WORKSPACE包含USER和WORKSPACE的所有属性。

2-仅在USER-WORKSPACE：user_id和workspace_id的架构中使用每个实体的ID。

第一种方法的问题是它是非常冗余的，并且我们需要创建太多重复的记录。

另一方面，第二种方法的问题是我们不能保证在不同类型的事件之间保留顺序，因此我们需要通过假设USER-WORKSPACE为在消费USER或WORKSPACE实体之前，我们需要在消费者服务中创建一个占位符。因此，如果相应的实体不存在，则可以为USER和WORKSPACE创建一个空实体。

仅当我们可以保证同一事件类型的顺序时，此解决方案才有效。但是，当涉及USER-WORKSPACE事件时，如果我们选择user_id，那么WORKSPACE可能会不同步；如果我们选择workspace_id，那么USER将会得到不同步。

这是一系列事件的示例，如果将user_id用作USER-WORKSPACE事件的分区键，可能会导致不一致。这是产生的事件的顺序：

1- USER U1已创建

2- WORKSPACE W1已创建

3- USER-WORKSPACE U1-W1已创建

4- WORKSPACE W1被删除

5- USER-WORKSPACE U1-W1已删除

快照：

• USER U1

这些事件按以下顺序使用：

1- WORKSPACE W1已创建

2- WORKSPACE W1被删除

3- USER U1已创建

4- USER-WORKSAPCE U1-W1已创建（应创建WORKSPACE的占位符）

5- USER-WORKSPACE U1-W1被删除（WORKSPACE的占位符无法删除，因为我们不知道这是删除WORKSPACE实体还是删除{对应关系）

快照：

• USER U1
• WORKSPACE W1（占位符）

如您所见，这可能会导致不一致。对于CDC的“发件箱”模式应如何管理关系类型事件的情况，我是否有所遗漏？这是否意味着唯一的方法是为每个关系定义一个胖事件并使其完全独立？