消息中间件RocketM高可用容灾设计架构
RocketMq容灾部署方案
一、RocketMQ部署模式
1. 单机模式
-- 不可靠,一旦Broker 重启或者宕机时,服务将不可用。
2. 多主模式
-- 全部由 Broker Master 节点组成(即可能部署两个或者更多 Broker),生产者发送的数据会分别存入不同的 Broker 中,这样能够避免某个 Broker 一直接收处理数据从而负载过高。
3. 双主双从/多主多从模式(异步复制)
-- 同时部署多个master及slave节点,Master 、Slave 间采用"异步复制数据"方式进行数据同步。
4. 双主双从/多主多从模式(同步双写)
-- 集群中同时部署多个master及slave节点,且 Master 和 Slave 之间采用"同步复制数据"方式进行数据同步,这样在生产者将消息发送到 Broker Master 后需要等待数据同步到 Slave 节点成功后,才返回成功。
5. Dledger 集群模式
-- 由多个maser-slave broker小集群组成。每个小集群内至少需要 3 个节点,通过 Raft 自动选举出一个 Leader,其余节点 作为 Follower,并在 Leader 和 Follower 之间复制数据以保证高可用。
以上各个集群部署模式各有优缺点及使用场景。
在 RocketMQ 4.5 之前的版本中,部署 RocketMQ 高可用方案一般都会采用多主多从方式,这种方式需要master节点实时同步数据给相应的slave节点,slave节点可以采用同步或者异步的方式去同步master数据。缺乏自动化的故障转移能力。
因此,如果需要主从节点具有自动切换能力,那么就需要采用基于Ledger的方式进行rocketMQ方式部署。在不使用zookeeper等第三方协调组件的情况下,在一组 broker 中如果 Master 挂了,能够依靠 DLedger 自动选主能力重新选出一个 leader,然后通过角色透传变成新的 Master。
二、跨越rocketMQ 集群容灾部署方案。
采用基于Dledger 集群模式来部署rockerMq集群。其部署架构图如下。
2、如果广州4区或者广州6区所在的master节点出现异常,那么会出现raft选举,从而产生新的master节点,继续提供消息的读写服务。这个故障切换是自动的。
3、该模式也支持 Broker 节点水平扩展来增加吞吐量。所以该模式将会是部署 RocketMQ 常用模式之一。
相关文章
- Flink 实践教程-入门(6):读取 PG 数据写入 ClickHouse
- [GPIO]推荐一种超简单的硬件位带bitband操作方法,让变量,寄存器控制,IO访问更便捷,无需用户计算位置
- MySQL必知必会汇总
- 基于天河超级计算机的新冠药物筛选成果入围国际戈登贝尔奖评选
- Nucleic Acids Research | 药物转运体三维结构可变性信息分析
- 问题解决:C++ 读取MySQL数据库中文乱码问题
- Flink 实践教程-入门(7):消费 Kafka 数据写入 PG
- 张青林:云原生数据库TDSQL-C在关键技术的多维突破
- 多类型数据库统一管理,腾讯云数据库DBhouse工具重磅发布
- 针对EasyNVR开发的EasyStreamClientTool调试工具如何使用?
- 64最小路径和----动态规划
- 向量类模板的声明和实现---扩充版本
- 62 leetcode 不同路径---动态规划
- leetcode 53. 最大子序和
- leetcode 面试题 17.16. 按摩师
- c++之iostream迭代器用法超详细整理!!!
- Spark性能优化和故障处理
- c++IO库之string流超详细整理,建议赶紧收藏! ! !
- ClickHouse深度解析,收藏这一篇就够了~
- 消除业务跨国数据传输隐患,APISIX 在网关层的解法