发布网友
发布时间：2024-10-24 11:27
共1个回答
热心网友
时间：2024-11-01 19:44
简介：本文介绍了双写场景的一致性问题，详细介绍了三种解决方案，并针对DB->Binlog->Kafka方案给出了Lindorm数据订阅的最佳实践。
双写问题介绍双写问题（DualWriteProblem）是指：需要同时修改两个独立系统的场景，比如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，以DBbinlog实现最终一致性的下游业务。
Lindorm数据订阅介绍Lindorm数据订阅是"DB->Binlog->Kakfa"方案的升级版。
云原生多模数据库Lindorm数据订阅功能支持任何一个表的每一条数据变更，可以在客户端实时有序的查看数据变更记录。当开通某一张表的数据订阅功能后，其变更数据的操作就会被存储。为了确保数据消费的顺序和数据写入的顺序一致，数据订阅功能提供了主键级别保序，对于同一个主键的更新操作，会按照其更新的顺序存储和消费。
每次对Lindorm表格的数据执行增删改操作时，数据订阅都会生成一个StreamRecord键值对，键值对的键是这一行数据的主键，值是此次操作的详细信息（操作前的值，操作后的值，时间戳，操作类型）。
总结Lindorm数据订阅的特点：
实时订阅
100%兼容Kafka客户端
Key级别保序
作者：阿里云云栖号特别提示：本站信息仅供参考，不能作为诊断及医疗的依据；请谨慎参阅，本站不承担由此引起的法律责任。本网站敬告网民：身体若有不适，请及时到医院就诊。
网站备案号：赣ICP备2023002352号-14Copyright © 2006-2018 All rights reserved所有权归属：华佗医网 版权所有
视频许可证编号：（湘）字第00637号 本站由北京市万商天勤律师事务所王兴未律师提供法律服务
