我们一直在使用带有发件箱模式的变更数据捕获，通过使用debezuim和kafka在我们的事件驱动架构中保持不同微服务之间的数据库同步。我们在早期阶段所面临的挑战之一是，如果kafka不能跨多个分区保持秩序，我们如何确保数据库不会失去同步。处理这种情况的方法是明智地选择分区键，以便与相同实体相关的所有事件都应基于分区键转到相同的分区。因此，可以为同一实体保留顺序。一开始这似乎很简单，但要解决涉及两个不同实体的情况似乎有一个根本性的挑战。由于我们只能有一个分区键，因此我们需要决定选择哪个实体作为分区键。下面是一个可能出错的示例：
假设有两个实体。 USER 以及 WORKSPACE 与mxn的关系。每个 USER 可以访问多个 WORKSPACE s、 以及每个 WORKSPACE 可由多个 USER s。因此定义了三组不同的事件来处理 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-仅使用的架构中每个实体的id USER-WORKSPACE : user_id 以及 workspace_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的发件箱模式中，如何管理关系类型事件的情况，我遗漏了什么吗？这是否意味着唯一的方法是为每一段关系定义一个fat事件并使其完全独立？