双重写入：如何解决微服务分布式系统中数据不一致？Thorben

什么是双重写入？
双重写入描述了您在两个个系统（例如数据库和Apache Kafka）中更改数据时的情况，而没有额外的层来确保两个服务上的数据一致性。

只要两个操作都成功，一切就OK了。即使第一笔交易失败，也还是可以的。但是，如果您成功提交了第一笔交易而第二笔交易失败，则说明您遇到了问题。您的系统现在处于不一致状态，没有容易修复的方法。

分布式事务不再是一种选择
过去，当我们构建整体/.单体/Monolith时，我们使用分布式事务来避免这种情况。分布式事务使用两阶段提交协议。它将事务的提交过程分为两个步骤，并确保所有系统的ACID原则。
但是，如果我们要构建微服务系统，则不会使用分布式事务。这些交易需要锁，并且无法很好地扩展。他们还需要所有涉及的系统同时启动和运行。

那你该怎么办呢？

3个无效的“解决方案”
当我在会议演讲中或在一个研讨会上与与会者讨论此主题时，我经常听到以下3条建议之一：

1. 是的，我们知道此问题，我们没有解决方案。但这还不错。到目前为止，什么都没有发生。让我们保持原样。
2. 让我们将与Apache Kafka的交互移动到提交后监听器。
3. 在提交数据库事务之前，让我们将事件写入Kafka中的主题。

1. 仅当您可以将失败的事件保留在数据库中时，它才有效。如果数据库事务失败，或者您的应用程序或数据库崩溃，然后才能存储有关失败事件的信息，则将丢失它。
2. 仅当事件本身没有引起问题时，它才起作用。
3. 如果在清除作业恢复失败的事件之前，另一个操作为该业务对象创建了一个事件，则事件将混乱。

如何避免双重写入？
您可以选择几种方法来避免双重写入。但是您需要知道，如果不使用分布式事务，则只能构建最终一致的系统。
总体思路是将流程分为多个步骤。这些步骤中的每个步骤仅适用于一个数据存储，例如数据库或Apache Kafka。这使您能够使用本地事务，所涉及系统之间的异步通信以及异步的，可能无限的重试机制。
如果您只想在服务之间复制数据或通知其他服务已发生事件，则可以将发件箱模式与Debezium等变更数据捕获实现一起使用。我在以下文章中详细解释了这种方法：

• 使用Hibernate实现发件箱模式
  
• 使用Debezium用CDC实现发件箱模式
  

结论
双重写入常常被低估，许多开发人员甚至都不知道潜在的数据不一致。
如本文所述，在没有分布式事务或确保最终一致性的算法的情况下，写入2个或更多系统可能会导致数据不一致。如果使用多个本地事务，则无法处理所有错误情况。
避免这种情况的唯一方法是将通信分为多个步骤，并且在每个步骤中仅写入一个外部系统。SAGA模式和变更数据捕获实现（例如Debezium）使用这种方法来确保对多个系统的一致写入操作或将事件发送到Apache Kafka。