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

用户福利

阿里云最新发布业界首款云原生多模数据库Lindorm，新用户可申请首月免费试用，获取产品技术支持，请加入钉钉群：35977898，更多内容请参考链接

双写问题介绍

双写问题（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失败怎么处理？

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

基于业务场景决策

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

1. 如果业务要求全盘的强一致体验，那么我们应当选择分布式事务。

2. 如果业务倾向全盘的最终一致性体验，那么我们选择以MQ为第一入口实现最终一致性。

3. 如果业务存在不同的一致性体验需求，那么我们选择强一致读写DB，以DB binlog实现最终一致性的下游业务。

Lindorm 数据订阅介绍

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

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

总结Lindorm数据订阅的特点：

1. 实时订阅

2. 100%兼容Kafka客户端

3. Key级别保序

Lindorm产品链接：https://www.aliyun.com/product/apsaradb/lindorm