简介： 本文介绍了双写场景的一致性问题，具体介绍了三种解决方案，并针对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级别保序

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