使用 Outbox 模式保持微服务数据一致性
在一个由许多小型服务组成的系统中保持数据一致性是困难的，因为它们分散在各处。以下是一些常见问题以及如何处理它们的方法：当服务发送消息时，同时更新数据库和发送消息是棘手的问题。
在微服务中发出事件时，我们必须解决如何以事务方式更新数据库并发出事件的问题。
Outbox 模式
处理这个问题的简单方法是使用事务性 Outbox 模式。
1*4ApYkrLX-KMWMqLZs1Ea9Q.png
问题：双写问题
当我们必须同时更新两个不同的系统时，就会出现双写问题。例如，如果我们需要在 Apache Kafka 和数据库中记录事件。由于这些系统没有连接，我们无法一次性更新它们。我们必须找到一种方法来确保两者同时更新，或者两者都不更新。这就是事务性 Outbox 模式发挥作用的地方。
如果我们的数据库支持事务性更新，我们可以使用它来解决双写问题。我们将事务逻辑移到数据库中，而不是尝试同时更新数据库和 Kafka。每当我们更新数据库时，我们也在同一个事务中更新一个 Outbox 表。可以将 Outbox 想象成一个邮箱，我们将需要发送的信件放在其中。然后，我们等待邮递员收集这些信件并将其送到邮局。在我们的情况下，这些信件代表我们想要发送到 Kafka 的事件，而 Kafka 则充当邮局。但是，我们仍然需要某种东西扮演邮递员的角色。
要从 Outbox 表中发出事件到 Apache Kafka，我们可以使用一个单独的进程来异步监视该表。每当它检测到事件时，就可以将其发送到 Kafka。
1*bF5bu2znS9hSZOLGG5i56w.png
双写问题
一旦事件成功传递，它就可以从 Outbox 表中删除。该进程通常是在原始微服务中的另一个线程中编写的；但是，它也可以作为完全独立的应用程序运行。根据您使用的数据库，您可能可以使用 Kafka 连接器（例如 Postgres-Kafka 连接器）或更改数据捕获（CDC）系统（例如 Debezium）来监视表并发送事件。
1*LIIuyIzUQ6owQY81k5LqRg.png
Kafka 连接器或更改数据捕获（CDC）
使用 CDC 解决双写问题的优势
Outbox 事务模式避免了双写问题。原因是状态和 Outbox 表将始终以事务方式更新。如果由于某种原因状态未能更新，则事件不会写入 Outbox；这意味着我们可以保证 Outbox 中的数据与数据库中的数据完全同步。然后，负责将事件传递到 Kafka 的独立进程确保 Outbox 表和 Kafka 保持同步。这使我们能够保证每个数据库操作都会在 Kafka 中有一个相应的事件，尽管会有一点延迟。
缺点：当传递过程向 Kafka 发出事件时，可能会出现失败或超时。在这种情况下，为了确保 Kafka 收到数据，我们必须重试。这些重试可能导致重复的消息；因此，我们向 Kafka 的传递保证是至少一次的。我们保证 Outbox 中的每条消息最终都会到达 Kafka，但可能会重复到达。因此，我们需要确保下游系统准备好处理任何重复消息。
在分布式系统中，至少一次的保证是常见的，因此，即使不涉及双写问题，实现去重逻辑也是一个良好的做法。例如，接收方在处理 Kafka 消息时可能会失败，并且当它重新启动时可能会再次收到相同的消息。
1*Q3y3m680RrZ05SevzCY2Og.png
Outbox 模式中的挑战
我们必须准备好处理这些情况。这可能会导致大量的流量。频繁的更新意味着数据库可能会始终将表保存在内存中，占用大量资源。与此同时，一些数据库在处理删除时效率不高。它们可能在幕后使用墓碑，并且随着频繁的插入和删除发生，这些墓碑可能会累积，这会导致资源使用量大增，并在我们的表中引起争用。如果数据库无法处理此类流量，可能会减慢我们的应用程序，因为请记住，每个写入都将触及该 Outbox 表。为了解决这些问题，我们可能需要进行调整，例如将记录而不是删除它们，或者调整数据库管理墓碑的方式。保留事件可能会带来长期的好处，因此删除可能并非绝对必要。一些数据库专门设计用于处理这种类型的流量。
结论
如果您的系统满足事务性 Outbox 模式的要求，那么它可以是解决双写问题的一种简单有效的方法。与其他选项（例如事件溯源或监听自己模式）相比，这种方法采用事件优先的方法，使用 Kafka 实时通知微服务变更，保持系统一致性。但是，诸如订单履行之类的组件可能需要编排，无法运行。