RabbitMQ、Kafka、RocketMQ 是如何实现高可用的?

本文从高可用的角度观察一下 RabbitMQ、Kafka、RocketMQ,看看它们各自的实现思路。

1. RabbitMQ

RabbitMQ 有 3 种部署模式:

  • 单机模式
  • 普通集群模式
  • 镜像集群模式

单机模式与高可用完全没关系,咱就不说了,直接看看这2种集群模式。

1.1 普通集群模式

某一个 Queue 是在集群中的某一个 Broker 上,各个 Broker 会同步元数据,但不会同步 Queue 的消息数据。

如果某一个 Broker 故障了,其中的 Queue 便无法使用。如果消息没有配置消息持久化,则消息丢失。

可以看到,这种方式并没有实现高可用,只是扩展性比较好,扩充 Broker 可以容纳更多的 Queue,提高吞吐量。

1.2 镜像集群模式

一个 Broker 中 Queue 的元数据和消息数据都会同步到其他 Broker 上,就是做了全量备份,所以称为 “镜像模式”。

实现了高可用,如果一个 Broker 故障了,没关系,可以使用其他 Broker 继续工作,消息数据不会丢失。

可用性上去了,但扩展性没有了。

一个 Queue 的数据是全量存在 Broker 中的,所以 Queue 的消息容量、消息处理能力,都受限于 Broker。

普通集群模式 没有达到高可用,扩展性较好。

镜像集群模式 实现了高可用,但扩展性差。

2. Kafka

Kafka 把 Topic(主题/队列)分为了多个 Partition(分区),Topic 只是逻辑概念,Partition 才是实际的消息存储单元。

一个 Topic 的多个 Partition 分散在多个 Broker 中,每个 Partition 存放 Topic 的一部分数据。

有了 Partition 之后,Topic 就具有了极强的扩展性,可以指定 N 个 Partition。

可以为 Partition 指定多个“副本”,分散在不同的 Broker,从而实现其高可用。

当某个 Broker 故障的时候,其中存放的 Partition 不可用,但没有关系,可以使用其他 Broker 上的副本。

Partition 的多个副本分为两种角色,Leader 和 Follower。

Leader 是由 Kafka 选举出来的,负责处理消息的读写。Leader 收到新消息后,会同步给 Follower。

Follower 的作用是候选人,当 Leader 出事儿之后,Kafka 会从 Follower 中选举出新的 Leader。

可以配置消息写入完成的标准:

  • 写入 Leader 既可 – 速度快,但可能会有消息丢失,例如在同步到 Follower 之前 Broker 故障了,则消息丢失。
  • Follower 同步完成之后才算写入成功 – 消息可靠性极高,但影响写入速度。

3. RocketMQ

这是 RocketMQ 的官方结构图,左右是 Producer 和 Consumer,中间是 RocketMQ,分为两个部分:

  • NameServer 集群 – 存放元数据
  • Broker 集群 – 存放队列数据

这两部分都需要保证高可用。

NameServer 是独立运行的,保存着集群完整的集群元数据,例如路由信息、Broker信息、数据信息。

为了保证其高可用,可以运行多个 NameServer,之间完整的同步数据即可。

这样只要有一个 NameServer 是可用的,就不会影响集群的正常工作。

Broker 集群的部署方式可以分为 3 种。

  • 多 Master

部署多个 Broker,角色都是 Master,Topic 的数据会分散存储在这些 Broker 中。

单个 Master 故障会导致其中数据无法使用,需要等待修复。

如果想保障数据的可靠性,可以使用【RAID10 + 同步刷盘】机制。

  • 多 Master 多 Slave

为 Master 配置了 Slave,Master 会把数据同步到 Slave。

当 Master 故障之后,可以用 Slave 顶上去,数据和服务都不影响,但会有短暂的停顿,需要修改配置并重启才能完成切换动作。

数据同步的方式分为:

1)异步 – Master 写入完成即可,异步同步给 Slave。写入速度快,但同步会有延迟,可能会丢数据。

2)同步 – Master 与 Slave 都写入之后才算成功。不会丢消息,但写入速度降低。

  • Dledger Group

Dledger 模式要求为 Master 配置 2 个 Slave,3 者组成一个 Dledger Group。

Dledger 也是 Master-Slave 同步的方式,好处在于可以实现自动选举 Master,自动切换。

当 Master 故障的时候,RocketMQ 可以从组内选出一个新的 Master,完成自动切换,这样更进一步提高了集群的可用性。

最后小结一下。

推荐阅读

OAuth2 图解

轻松理解 Kubernetes 的核心概念

开发者必须要了解的架构技术趋势:Service Mesh

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: RabbitMQ, Kafka, 和 RocketMQ 是三种不同的消息队列系统,它们各有特点。 RabbitMQ是一种面向消息的中间件,支持高可用性和分布式部署。 Kafka是一种高吞吐量的分布式流式数据平台,适用于实时数据处理和分析。 RocketMQ是一种分布式消息系统,支持高吞吐量和高可靠性。 总的来说,选择哪种系统取决于你的特定需求,如吞吐量,可靠性,实时性等。 ### 回答2: RabbitMQKafkaRocketMQ 都是当前比较常用的消息中间件,它们都有着优秀的可靠性、可扩展性、性能和高可用性。但是它们在一些功能和设计上还是有所不同的。 1. 消息传输方式 RabbitMQ 是 AMQP(Advanced Message Queuing Protocol)的实现,使用的是消息推送方式。AMQP 协议适用于面向传输层(TCP/IP)的异步通信,实现可靠的消息传输。 Kafka 是基于 publish-subscribe 模式的消息传递,使用的是 pull-based 方式。Kafka 使用了分区机制,将每个主题按照分区策略分成多个分区存储在不同的节点上,每个分区对应一个消费者组。 RocketMQ 也是基于 publish-subscribe 模式的消息传递,使用的是 push-based 方式。RocketMQ 同样支持分区机制,并且支持单播(点对点)和广播两种消息模式。 2. 可靠性和事务支持 RabbitMQ 是 AMQP 协议的实现,其可靠性方面比较出色,支持事务机制,能够保证消息的可靠传输。同时 RabbitMQ 支持主从和镜像队列,能够确保高可用性。 Kafka 也是一个高可靠的消息系统,使用 ZooKeeper 进行协调管理,可用性好。Kafka 对消息的可靠性保证基于以分区为单位的消息复制机制。但是 Kafka 不支持事务,需要自己实现RocketMQ 的可靠性、事务方面都做得很好。RocketMQ 支持可靠异步传输和可靠同步传输两种模式,并且支持事务消息。 3. 性能 Kafka 在性能方面表现非常出色,每秒可以处理数百万条消息。Kafka 将消息存储在磁盘上,通过批量写入、零拷贝、多线程等技术实现了非常高的性能。 RocketMQ 在性能方面也表现出色,读写效率都非常高。RocketMQ 采用的是 Zero-Copy 技术和消息内存映射机制,能够极大地提高性能。 RabbitMQ 的性能不如 KafkaRocketMQ,但实现比较简单,开发和维护相对容易。 4. 社区贡献和生态系统 Kafka 的社区非常活跃,生态系统比较完善,能够实现很多基于 Kafka 的周边产品,如 Kafka Connect、Kafka Streams、KSQL 等。 RabbitMQ 在可插拔性和高可靠性方面做得比较好。RabbitMQ 有大量的插件可以集成各种不同的业务场景,但是生态系统相对较小。 RocketMQ 的社区相对于 Kafka 来说比较年轻,但已有很多用户在生产环境中使用,并且生态系统正在逐渐完善。 综上所述,RabbitMQKafkaRocketMQ 都是优秀的消息中间件,用户应根据具体业务场景需求来选择适合自己的消息中间件。如果需要可靠性和事务支持,可以选择 RabbitMQRocketMQ;如果追求高性能和数据的实时处理、大数据场景下的数据传输和存储,可以选择 Kafka。 ### 回答3: RabbitMQKafkaRocketMQ都是当前非常热门的消息中间件。它们在一定程度上有相似之处,但也有很大的不同。下面就从多个维度来比较它们。 1. 引入背景 RabbitMQKafka都是在2007年左右诞生的,它们出现的时候,主要解决的是MQ的技术难题。RabbitMQ最早是由LShift公司的一群开发人员开发,主要是基于AMQP协议,用Erlang语言编写;Kafka则是由LinkedIn公司开发,最初将其用于处理LinkedIn的大量数据,后来成为了Apache的开源项目。而RocketMQ则是在2012年左右开始开发的,主要是由阿里巴巴开发,也是基于Apache RocketMQ的开源项目。 2. 架构设计 RabbitMQ的架构设计是基于AMQP协议的,采用Erlang语言实现,因此具有较高的可靠性和扩展性,也有很多 plugins 可以使用。RabbitMQ 的架构包含 Exchange(交换机)、Queue(队列)、Binding(绑定)和 Virtual Host(虚拟主机)4个主要部分。 Kafka的架构设计则是基于Pub/Sub模式,它以专门存储消息的Topic为核心,而且Kafka只提供了一小部分的API,主要是向 Producer 和 Consumer 暴露API,并利用 ZooKeeper 进行协调管理。 RocketMQ的架构设计是基于分布式的架构设计,通过 Name Server 管理 Topic 信息和 Broker 状态,Broker 通过实现 Master-Slave 备份机制来保证高可用性。 3. 性能比较 在性能方面,Kafka相对而言,吞吐能力最强,支持每秒数百万级别的消息处理,非常适合高吞吐量且处理逻辑简单的场景。而RabbitMQRocketMQ相对而言则处理能力较低,并发高负载会导致性能下降。同时在可扩展性方面,RabbitMQRocketMQ相对而言更加灵活,可根据实际需求动态调整集群规模,而Kafka则稍微有些麻烦。 4. 支持性比较 在支持的消息协议方面,KafkaRocketMQ同时支持自定义协议,而RabbitMQ则主要支持AMQP协议。同时在支持的编程语言方面,Kafka支持Java、Scala、Python、.NET等语言,RocketMQ主要支持Java语言,而RabbitMQ同样支持Java、C#、JavaScript等多种编程语言。 总体来看,每个消息中间件都有自己的优势和局限性,选择哪种消息中间件主要取决于实际的业务需求、架构设计和数据规模等因素。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值