简介：本文介绍了双写场景的一致性问题，具体介绍了三种解决方案，并针对 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 级别保序
原文链接
本文为阿里云原创内容，未经容许不得转载。