双写问题介绍

“双光照问题”(Dual Write Problem )是指，如果需要同时修改两个独立系统的场景(如数据库和Kafka、数据库和缓存)，该如何处理两个系统

以Database和Kafka等常见场景为例，有以下方法。

同时写Database和Kafka需要先写Kafka，然后写Database需要先写Database，然后写Kafka

并发写Database和Kafka

需要分布式事务来支持强匹配。 否则，不匹配的情况会变得复杂，数据库和Kafka中可能没有完整的数据。

先写Kafka，再写Database

先写Kafka，成功后返回客户端成功，然后订阅Kafka邮件签入数据库，实现最终的一致性。 然而，这种异步化会导致数据库数据更新的延迟，影响要求强且一致的读取的场景。 例如，账单填写成功，但客户不能马上看到； 例如，实时的原因场景，Flink实时消费Kafka，在遭遇交易事件后，调查数据库的原因，但此时重要数据可能还没有签入。

用

先写Database，再写Kafka

序列写数据库、Kafka，成功后返回客户成功。 这种方式的问题也不小。 如果第一个写入延迟增加，第二个数据库成功，Kafka失败，你会怎么处理？

此时，会想到Binlog (或WAL )。 新计划是DB-Binlog-Kafka。 写入数据库，成功后返回客户端成功。 然后订阅Binlog，写入Kafka，在下游订阅Kafka进行消费。 在实现最终一致性的同时，确保数据库中的较强一致性。

基于业务场景决策

上文介绍了双光照问题的三种解决方案。 各自适应不同的场景。

如果企业需要全面一致的体验，则必须选择分布式事务处理。 如果您的业务趋势最终是一致的，则选择以MQ为第一入口来实现最终的一致性。 如果您的业务需要一致，则选择功能强大、一致的读写数据库，以便使用DB binlog实现最终一致的下游业务。

Lindorm 数据订阅介绍

Lindorm数据订阅是“DB-Binlog-Kakfa”程序的升级版。

云本机多模式数据库的Lindorm数据订阅功能支持任意表的所有数据更改，客户端可以实时有序地查看数据更改的记录。 打开某个表的数据订阅功能时，将保存更改该数据的操作。 数据订阅功能提供主键级别的保证，以使数据消耗顺序与数据写入顺序一致，并按照更新顺序对同一主键的更新操作进行存储和消耗。 每次对Lindorm表中的数据执行添加/删除操作时，数据预订都会生成一对流记录键和值。 键-值对的键是该行数据的主键，值是本次操作的详细信息(操作前的值、操作后的值、时间戳、操作类型)。

总结Lindorm数据订阅的特征：

实时订阅100%兼容Kafka客户端Key级别保证序列原文链接： http://click.a liyun.com/m/1000296623 /

本文原创内容为AlibabaCloud (阿里巴巴云)，未经许可不得转载。