写点什么

消息队列(二)如何保证消息队列的高可用?

用户头像
奈何花开
关注
发布于: 2020 年 06 月 28 日

在上一篇笔记 【MQ 学习笔记】为什么要使用消息队列? 中,介绍了消息队列的应用场景和可能导致的问题,其中高可用问题是引入 MQ 的第一个问题。

一、什么是高可用性?

对于高可用性,维基百科上是这么描述的:高可用性(英语:high availability,缩写为 HA),IT术语,指系统无中断地执行其功能的能力,代表系统的可用性程度。

也就是说,我们不可能做到 100% 的可用性,所以用可用性度来表示高可用性,通常我们会用多少个 9 来表示高可用的目标,比如 99.99% 表示系统的年停机时间为 8.76 个小时,也就是 99.99% 的时间都是可用的。要做到高可用,我们至少要实现下面两点:

  • 对软硬件的冗余备份,以消除单点故障。

  • 对故障的检测和恢复。

二、如何保证消息队列的高可用

不同的消息队列,保证高可用的方式有一些区别,这里分别记录下各种消息队列的高可用实现方式。

1、RocketMQ 高可用

RocketMQ 进程我们一般称为 Broker,Broker 通常是集群部署的,每个 Broker 需要注册到 NameServer 中。从这里我们可以知道高可用有两个地方需要解决,一是 Broker 挂了怎么办,二是 NameServer 挂了怎么办。

对于 NameServer,它的高可用保障是集群化部署,各个 NameServer 之间互不通信,每个 NameServer 都有一份完整的 Broker 路由信息。当某一个 NameServer 挂掉后,对集群没有任何影响,只要还有一个 NameServer 存活,就能提供完整的服务。

对于 Broker,它高可用保障是主从架构和多副本策略。Broker 有 Master 和 Slave 两种角色,Master 和 Salve 上的数据是一模一样的,Master Broker 收到消息后会同步给 Slave Broker。每个 Master Broker 和 Slave Broker 都会向所有 NameServer 注册。Master 宕机了,会重新选举一个 Slave 作为 Master 继续提供写服务,对读服务无影响,每个 Slave 都可以读但是不可以写;Slave 宕机了,对服务无影响。

RocketMQ 的高可用保障如下图:

2、RabbitMQ 高可用

RabbitMQ 不是分布式的,它有三种模式:单机模式、普通集群模式、镜像集群模式。其中只有镜像集群模式是能够保障高可用的,而生产环境不会使用单机模式。

  • 普通集群模式:集群中所有节点都存储队列元数据,但是只有一个节点存队列内容,此节点宕机则数据会丢失

  • 镜像集群模式:集群中每个节点都存储完整的队列元数据和队列内容,是一份完整的镜像数据。某个节点宕机,对整体服务没有影响。缺点是不支持分布式,每台机器都有一份完整的数据。

3、Kafka 高可用

Kafka 高可用与 RocketMQ 类似,都是通过主从多备份架构实现的。如下图,每个 leader broker 可以有多个 follower broker,生产者生产和消费者消费均操作 leader broker 节点,当 leader broker 宕机后自动切换 follower 为 leader。

三、总结

本文先是描述了什么是高可用,以及不同 MQ 是怎么实现高可用的。要做到高可用,就要考虑容灾问题,如单点故障和数据丢失。单点故障我们通过集群来实现,如 RabbitMQ 的镜像集群模式,RocketMQ 的 NameServer 集群和 Master Broker 集群,Kafka 的 Zookeeper 集群和 Leader Broker 集群,这些集群每个节点都有一份完整的数据;数据丢失则只能通过数据镜像来实现了,如 RocketMQ 的 Master-Slave,Kafka 的 Leader-Follower,一般工业界认为比较安全的备份数应该是 3 份,所以一般至少会1主2从。

用户头像

奈何花开

关注

还未添加个人签名 2019.05.14 加入

还未添加个人简介

评论

发布
暂无评论
消息队列(二)如何保证消息队列的高可用?