如何保证MQ的高可用

最新推荐文章于 2024-05-11 17:58:57 发布

向前齐步走

最新推荐文章于 2024-05-11 17:58:57 发布

阅读量1.8k

点赞数

文章标签： java 开发语言

本文链接：https://blog.csdn.net/2301_78021017/article/details/130884305

版权

高可用这个话题是所有中间件避免不了的话题。面试当中会有各式各样的关于高可用的提问，比如Redis怎么保证高可用，注册中心怎么保证高可用，程序怎么保证高可用。这一讲我们就来详细聊聊MQ如何保证。这里我以RocketMQ举例：

聊MQ之前我们先聊聊一个话题，到底什么样的系统算是高可用系统呢？业内有没有相关的评估标准呢？

系统可用性(Availability)是信息工业界用来衡量一个信息系统提供持续服务的能力，它表示的是在给定时间区间内系统或者系统某一能力在特定环境中能够正常工作的概率。

简单地说，可用性是平均故障间隔时间(MTBF)除以平均故障间隔时间(MTBF)和平均故障修复时间(MTTR)之和所得的结果，即：

看公式可能不够直观对吧，过于理论了，这里再和大家说一种业内用的比较多的方式，用N个9来表示系统的可用性。比如说：

年内可用	不可用	解释
99.9%	8.76小时	99.9%代表3个9的可用性，意味着全年不可用时间在8.76小时以内，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时；
99.99%	52.6分钟	99.99%代表4个9的可用性，意味着全年不可用时间在52.6分钟以内,表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟；
99.999%	5.26分钟	99.999%代表5个9的可用性，意味着全年不可用时间必须保证在5.26分钟以内，缺少故障自动恢复机制的系统将很难达到5个9的高可用性。

一般来说我们会把4个9的系统称之为高可用系统，而3个9称为较高可用，2个9只能叫做基本可用。像淘宝、京东一类的网站是能达到4个9的。刚提到的这种算法还只能算是简单的计算公式，但是不够全面。

为什么这么说呢？我们刚是按照停机时间来计算，大致一看没什么问题，但是我们仔细想想我们在双十一停机10分钟和某一个平淡的深夜停机10分钟造成的影响完全是不同的。所以在计算高可用的时候我们也要把这个关键变量含括进来。对于高可用我们就说到这个地方，我们主要看的还是MQ如何去保证高可用性。

我们聊高可用，我们是不是得先知道RocketMQ里面到底有哪些组件对吧。RocketMQ 是由阿里巴巴开发的一款高性能、低延迟、高可靠、可扩展的分布式消息中间件。它的架构可以分为四个部分：NameServer、Broker、Producer 和 Consumer。

NameServer
NameServer 负责管理所有的 Broker，它维护了 Broker 集群的信息，包括 Broker 的地址、主题（Topic）和队列（Queue）等元数据信息。当 Producer 或 Consumer 需要发送或者消费消息时，它们会先从 NameServer 获取 Broker 的信息，然后再与 Broker 进行通信。
Broker
Broker 是 RocketMQ 的核心组件，负责存储和转发消息。每个 Broker 都有自己的消息存储区（Message Store），它是一个高性能的消息存储系统，支持顺序写入和随机读取。消息在存储时会被划分为若干个队列，每个队列只会被一个消费者消费。Broker 还负责消息的路由和负载均衡，它会根据消息的主题和队列数将消息分配到不同的队列中。
Producer
Producer 负责向 Broker 发送消息。在发送消息前，Producer 首先需要从 NameServer 中获取 Broker 的地址信息，然后将消息发送到对应的 Broker 中。RocketMQ 的 Producer 支持同步发送和异步发送，还支持批量发送和顺序发送等特性。
Consumer
Consumer 负责从 Broker 中消费消息。消费者可以以广播模式或者集群模式消费消息。在广播模式下，每个消费者都会接收到相同的消息；在集群模式下，一组消费者共同消费一组队列中的消息，每个消息只会被一个消费者消费。RocketMQ 的 Consumer 支持顺序消费和消息过滤等特性。

对于生产者和消费者前面讲过如何保证消息不丢失在这里就不再展开来讨论了，这里我们就着重来看看NameServer和Broker的几种部署方式。

单机模式

单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式，没啥好讲的。

集群模式

在集群模式里面也存在两种不同的部署方式，多节点单副本集群和多节点多副本集群

多节点单副本集群

一个集群内全部部署 Master 角色，不部署Slave 副本，例如2个Master或者3个Master，这种模式的优缺点如下：

优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；

缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。

多节点（集群）多副本模式-异步复制

每个Master配置一个Slave，有多组 Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：

优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；

缺点：Master宕机，磁盘损坏情况下会丢失少量消息。

多节点（集群）多副本模式-同步双写

每个Master配置一个Slave，有多对 Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：

优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；

缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

关注