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

简介： 本文介绍了双写场景的一致性问题，详细介绍了三种解决方案，并针对DB->Binlog->Kafka方案给出了Lindorm数据订阅的最佳实践

双写问题介绍

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

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

并发写Database和Kafka
先写Kafka，再写Database
先写Database，再写Kafka

并发写Database和Kafka

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

先写Kafka，再写Database

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

先写Database，再写Kafka

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

此时我们会想到Binlog（或者WAL），新的方案是DB->Binlog->Kafka：写入Database，成功后即可返回客户端成功，然后订阅binlog写入Kafka，下游订阅Kafka消费。实现最终一致性，同时保证了Database上的强一致读。

基于业务场景决策

上面我们介绍了双写问题的三种解决方案，他们各自适应不同场景。

如果业务要求全盘的强一致体验，那么我们应当选择分布式事务。
如果业务倾向全盘的最终一致性体验，那么我们选择以MQ为第一入口实现最终一致性。
如果业务存在不同的一致性体验需求，那么我们选择强一致读写DB，以DB binlog实现最终一致性的下游业务。

Lindorm 数据订阅介绍

Lindorm数据订阅是 "DB->Binlog->Kakfa"方案的升级版。

云原生多模数据库Lindorm数据订阅功能支持任何一个表的每一条数据变更，可以在客户端实时有序的查看数据变更记录。当开通某一张表的数据订阅功能后，其变更数据的操作就会被存储。为了确保数据消费的顺序和数据写入的顺序一致，数据订阅功能提供了主键级别保序，对于同一个主键的更新操作，会按照其更新的顺序存储和消费。每次对Lindorm表格的数据执行增删改操作时，数据订阅都会生成一个Stream Record键值对，键值对的键是这一行数据的主键，值是此次操作的详细信息（操作前的值，操作后的值，时间戳，操作类型）。

总结Lindorm数据订阅的特点：

实时订阅
100%兼容Kafka客户端
Key级别保序

原文链接

本文为阿里云原创内容，未经允许不得转载。