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

Posted 阿里云云栖号

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了拒绝双写:巧用Lindorm数据订阅相关的知识,希望对你有一定的参考价值。

简介: 本文介绍了双写场景的一致性问题,详细介绍了三种解决方案,并针对DB->Binlog->Kafka方案给出了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失败怎么处理?

此时我们会想到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数据订阅的主要内容,如果未能解决你的问题,请参考以下文章

拒绝加班:巧用前端电子表格中构建公式树

宜搭小技巧|巧用审批按钮,流程随心流转

JavaScript巧学巧用

巧用PropertyInfo简化和改善代码

巧用SimpleDateFormat将Date类型数据按照规定类型转换。

巧用weui.topTips验证数据