简要介绍：本文介绍了双重写作场景的一致性问题，详细介绍了三个解决方案，并为DB-> binlog-> kafka解决方案提供了Lindorm数据订阅的最佳实践。
双写问题是指：需要同时修改两个独立系统的场景，例如数据库和Kafka以及缓存，因此如何确保两个系统的一致性？
以数据库和Kafka等常见场景为例，我们可以有很多方法：
在这种情况下，需要分布式交易来支持强大的一致性，否则情况将更加复杂。数据库和KAFKA可能没有完整的数据。
首先编写Kafka，您可以在成功后成功返回客户端，然后订阅Kafka消息以输入数据库数据库以实现最终的一致性。但是，这种异步数据更新延迟将影响一些需要强大一致要求的方案。例如，该法案已成功编写，但客户无法立即查看；例如，真实的时间归因场景，Flink会实时消耗KAFKA，并在遇到交易事件后检查DB归因，但是此时可能无法输入关键数据。
编写数据库和Kafka序列，并在成功后返回给客户。该方法不小。第一延迟增加。如何处理第二个数据库的成功和卡夫卡的失败？
目前，我们将想到Binlog（或WAL）。新解决方案是db-> binlog-> kafka：写入数据库，您可以在成功后成功返回客户端，然后订阅binlog到kafka并订阅下游的Kafka消费。将确保最终的一致性，同时确保强大的一致性阅读。在数据库上。
以上，我们介绍了三种解决方案，以解决双重写作问题，并适应不同的情况。
Lindorm数据订阅是“ db-> binlog-> kakfa”方案的升级版本。
Yunyuan多模型数据库的Lindorm数据订阅功能支持任何表的每个数据更改，可以在客户端上实时检查数据更改记录。打开表的数据订阅功能，更改的操作数据将存储。以确保数据消耗的顺序和数据编写顺序是一致的，数据订阅功能提供了主要的密钥级别准备。对于同一主键的更新操作，它将按更新顺序存储和消费。
操作的值，时间戳，操作类型）。
总结Lindorm数据订阅的特征：