拒绝双写:巧用Lindorm数据订阅-阿里云开发者社区

开发者社区> 云原生多模数据库Lindorm> 正文
登录阅读全文

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

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

用户福利

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

双写问题介绍

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

1111.jpg

以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"方案的升级版。

2222.jpg

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

总结Lindorm数据订阅的特点:

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

Lindorm产品链接

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云原生多模数据库Lindorm
使用钉钉扫一扫加入圈子
+ 订阅

Lindorm是适用于任何规模、多种类型的云原生数据库服务,支持海量数据的低成本存储处理和弹性按需付费,兼容HBase、Solr、SQL、OpenTSDB等多种开源标准接口,是互联网、IoT、车联网、广告、社交、监控、游戏、风控等场景首选数据库,也是为阿里巴巴核心业务提供支撑的数据库之一。

官方博客
最新文章
相关文章
链接