原文链接https://www.confluent.io/blog/dual-write-problem/

双写问题发生于当两个外部系统必须以原子的方式更新时。

问题

说有人到银行存了一笔钱，触发 DepositFunds 命令，DepositFunds 命令被发送到Account microservice。

Account microservice需要做两件事，修改过数据库 和 发送消息到kafka。

​

                                Figure 1: A microservice writes to two separate systems.

如果在修改数据成功之后， 系统崩溃，发送kafka 消息失败，这样就造成了相关kafka事件丢失。

                                        Figure 2: A failure results in a missing event.

同样的问题也会发生于任何系统，包括 monolithic和microservice 系统， 只要是尝试写两入两个独立的系统，却只有其中一个操作成功。

解决办法

事务发件箱模式 （transactional outbox pattern ）

同时利用了数据库事务和重试机制。

这种模式其实就是在 Account microservice 写数据库表的同时，把要发到kafka的消息先写入一张outbox表。这里写入的两张表在同一个事务（transaction）里完成。

至于outbox 表中的数据，可以由专门的程序负责读取和发送到kafka，也可以利用CDC（change data capture）完成。对于发送失败可以加入retry。在确定发送成功之后，可以删除outbox表中的数据。

                                        Figure 9: The transactional outbox pattern.

Event sourcing

事务发件箱模式不合适于不支持事务的数据库，而不依赖于数据库事务的就是 event sourcing。

这种模式不另外写一张表来保存要发送的数据，而是在原来表上（这里原来的表是存放的event，而不是事物发件箱模式中的数据）加一个flag，来过滤那些已经发送过了。

（😂是不是觉得很。。。 反正我看到这里，哎！😂）

The listen-to-yourself pattern

和 event sourcing很像，只不过event sourcing是先写表，在发送至kafka。

而 listen-to-yourself pattern 是直接写入kafka。在从kafka接收消息来修改数据库，同时写表需要retry跟上。

只不过就是这个先后顺序问题，写表虽会最终一致，但若在未写表之时，访问数据库则问题出现。

若系统可接纳，则无所谓。

其它解决办法

        还有其他解决双写问题的方法，我们在这里没有介绍。其目的不是暗示这些是解决问题的唯一方法，而是强调在事件驱动系统中特别有用的具体解决方案。

        在某些情况下，可以使用两阶段提交（ two-phase commit  aka 2PC）、扩展架构（extended architecture aka XA）事务和传奇模式（saga pattern）等技术来规避（circumvent）这个问题。然而，它们具有复杂性，可能不适用于所有技术，因此在实施它们之前，请确保您了解权衡。