摘要 :
文章目录 1. 背景 方案1 单写双消费 方案2：单写单消费 方案3:Mirrormaker 迁移 方案4:停机 2.方案对比 3. 总结 本文主要讲解关于如何实现数据库事务和消息的一致性方……
文
章
目
录
- 1. 背景
- 方案1 单写双消费
- 方案2：单写单消费
- 方案3:Mirrormaker 迁移
- 方案4:停机
- 2.方案对比
- 3. 总结
本文主要讲解关于如何实现数据库事务和消息的一致性方案相关内容，让我们来一起学习下吧！
1. 背景
由于历史原因，公司部分系统使用基于ECS自建 kafka消息队列，造成运维成本浪费、项目稳定性差等问题。
方案1 单写双消费
方案思路：
- 完成Topic元数据的迁移。
- 自建 Kafka 集群中原有的消费者保持不动。
- 阿里云Kafka 消费端新起消费者，配置新的阿里云Kafka 集群的 bootstrap-server，消费新的阿里云Kafka 集群。
- 等待所有消费端都已经监听了新的阿里云Kafka 集群。
- 将自建集群的生产切到 阿里云Kafka 新集群上（配置新的阿里云Kafka集群的 bootstrap-server）。
- 自建 Kafka 集群中原有的消费者继续消费自建 Kafka 集群中剩余的数据，直到消费干净后方可下线原消费者。
方案2：单写单消费
方案思路：
- 完成Topic元数据的迁移。
- 将自建 Kafka 集群的生产切到阿里云Kafka 新集群上 (配置新的阿里云Kafka 集群的 bootstrap-server)。
- 等待自建集群中的消费者消费完剩余数据。
- 将老的消费者切到阿里云Kafka 新集群消费（配置新的阿里云Kafka 集群的 bootstrap-server）。
方案3:Mirrormaker 迁移
方案思路：
- 完成Topic元数据的迁移。
- 自建 Kafka 集群中原有的消费者保持不动。
- 启动 Mirrormaker 工具的数据同步功能。
- 等待数据同步完成，修改消费者配置并切换消费者。
- 等待数据同步完成，修改生产者配置并切换生产者。
- 迁移完成，去掉 Mirrormaker 工具。
方案4:停机
略
2.方案对比
| 方案 | 是否平滑迁移 | 代码开发 | 是否要再次发布 |
|---|---|---|---|
| 1.单写双消费 | 是 | 除了KafKa迁移代码改造点，需要再一起套消费者，但是这个成本并不大 | 短期不需要 |
| 2.单写单消费 | 是 | KafKa迁移代码改造点(由于原有Topic和阿里云Topic映射的原因，在切换消费者时可能在代码中，要修改topic名） | 旧消费切到 阿里云Kafka集群之前， 阿里云Kafka集群会存在一定量的堆积（我们业务量并不大，堆积并不会太多）；因此需要即时观察旧消费者消费完，然后再次发布。 |
| 3.Mirrormaker 迁移 | 是 | 除了KafKa迁移代码改造点，Mirrormaker 工具开发熟悉使用新消费者从头开始消费，要保证所有消息幂等 | 短期需要 |
| 4.停机，等旧消费者消费完，然后切换新的生产者和消费者 | 否，且需要屏蔽所有操作入口 | KafKa迁移代码改造点 | 不需要 |
3. 总结
以上就是关于如何实现数据库事务和消息的一致性方案相关的全部内容，希望对你有帮助。欢迎持续关注潘子夜个人博客（www.panziye.com），学习愉快哦！
还没有评论呢，快来抢沙发~