拒绝双写：巧用Lindorm数据订阅

双写问题介绍

双写问题（Dual Write Problem）是指：需要同时修改两个独立系统的场景，比如Database和Kafka，再比如Database和缓存，那么如何保障两个系统的数据一致性？

以Database和Kafka这种常见的场景为例，我们可以有这么几种方式：

1. 并发写Database和Kafka
2. 先写Kafka，再写Database
3. 先写Database，再写Kafka

并发写Database和Kafka

这种情况下需要分布式事务来支持强一致，否则不一致的情况就会比较复杂，Database和Kafka可能没有一个有完整的数据。

先写Kafka，再写Database

先写Kafka，成功后即可返回客户端成功，然后订阅Kafka消息入库Database，实现最终一致性。但这种异步化导致DB的数据更新延迟，会影响一些要求强一致读的场景。比如账单写入成功，但客户不能立即查看；再比如实时归因场景，Flink实时消费Kafka，在遇到交易事件后反查DB归因，但可能此时关键数据还没入库。

先写Database，再写Kafka

串行写Database、Kafka，成功后返回客户成功。这种方式问题也不小，第一写入延迟增加，第二Database成功、Kafka失败怎么处理？