消息队列的持久化、分发策略、高可用和高可靠

原文:消息队列

一、什么是消息的持久化?

简单来说就是将数据存入磁盘,而不是存在内存中随服务器重启断开而消失,使数据能够永久保存。
在这里插入图片描述
常见的持久化方式
在这里插入图片描述

二、消息队列的分发策略

MQ消息队列有如下几个角色
1:生产者
2:存储消息
3:消费者
那么生产者生成消息以后,MQ进行存储,消费者是如何获取消息的呢?一般获取数据的方式无外乎推(push)或者拉(pull)两种方式,典型的git就有推拉机制,我们发送的http请求就是一种典型的拉取数据库数据返回的过程。而消息队列MQ是一种推送的过程,而这些推机制会适用到很多的业务场景也有很多对应推机制策略。
消息分发:
在这里插入图片描述

比如我在APP上下了一个订单,我们的系统和服务很多,我们如何得知这个消息被那个系统或者那些服务或者系统进行消费,那这个时候就需要一个分发的策略。
这就需要消费策略。或者称之为消费的方法论。

失败重试:
在这里插入图片描述

在发送消息的过程中可能会出现异常,或者网络的抖动,故障等等因为造成消息的无法消费,
比如用户在下订单,消费MQ接受,订单系统出现故障,导致用户支付失败,
那么这个时候就需要消息中间件就必须支持消息重试机制策略。
也就是支持:出现问题和故障的情况下,消息不丢失还可以进行重发。

不同消息中间件支持的分发策略:
在这里插入图片描述

三、什么是高可用

所谓高可用:是指产品在规定的条件和规定的时刻或时间内处于可执行规定功能状态的能力。(就是承载能力,承载力越高,可用性越高)
当业务量增加时,请求也过大,一台消息中间件服务器的会触及硬件(CPU,内存,磁盘)的极限,一台消息服务器你已经无法满足业务的需求,所以消息中间件必须支持集群部署。来达到高可用的目的。

消息高可用各种集群的底层逻辑:
1:要么消息共享,
2:要么消息同步
3:要么元数据共享

3.1 Master-slave主从共享数据的部署方式

在这里插入图片描述

解说:生产者将消息发送到Master节点,Master节点负责写入,所有的从节点都连接这个消息队列共享这块数据区域,所有的消息在一块。
Master挂掉,slave节点也可以继续服务。从而形成高可用

缺点:一旦Master节点挂掉,那么生产者就无法写入消息了,这种模式常在小项目中用到
3.2 Master- slave主从同步部署方式

在这里插入图片描述

解释:这种模式写入消息同样在Master主节点上,但是主节点会同步数据到slave节点形成副本,和zookeeper或者redis主从机制很类同。消息被保存在不同节点里。
这样可以达到负载均衡的效果,如果消费者有多个,消费者就可以去不同的节点就行消费。在后续的rabbtmq中会有使用。

缺点:1、消息的拷贝和同步会占用很大的带宽和网络资源,最好是主从节点都部署在同一个机房(局域网)内,加快网速与保证带宽
2、同样的master节点挂了,无法写入
3.3 多主集群同步部署模式

在这里插入图片描述

解释:多写多读,和上面的区别不是特别的大,但是它的写入可以往任意节点去写入。
3.4 多主集群转发部署模式

在这里插入图片描述

解释:如果你插入的数据是broker-1中,元数据信息会存储数据的相关描述和记录存放的位置(队列)。
它会对描述信息也就是元数据信息就行同步,如果消费者在broker-2中进行消费,
发现自己节点没有对应的消息,可以从对应的元数据信息中去查询,然后返回对应的消息信息,
场景:比如买火车票或者黄牛买演唱会门票,比如第一个黄牛有顾客说要买的演唱会门票,但是没有但是他会去联系其他的黄牛询问,如果有就返回。
优点:占用资源较少,比较可靠
3.5 Master-slave与Breoker-cluster组合的方案

在这里插入图片描述

解释:实现多主多从的热备机制来完成消息的高可用以及数据的热备机制,在生产规模达到一定的阶段的时候,这种使用的频率比较高。

四、什么是高可靠机制

所谓高可靠是指:是指系统可以无故障低持续运行,比如一个系统突然崩溃,报错,异常等等并不影响线上业务的正常运行,出错的几率极低,就称之为:高可靠。就是一种“容错性”
在高并发的业务场景中,如果不能保证系统的高可靠,那造成的隐患和损失是非常严重的。
如何保证中间件消息的可靠性呢?可以从两个方面考虑:
1:消息的传输:通过协议来保证系统间数据解析的正确性。
2:消息的存储可靠:通过持久化来保证消息的可靠性。

消息队列高可用性是分布式系统设计中的重要部分,确保在发生节点故障或网络问题时,系统依然能够可靠地传递消息。不同的消息队列系统采用不同的机制来实现高可用性,以下是一些主流方案。 ### RabbitMQ高可用性实现 RabbitMQ 通过镜像集群(Mirror Queue)模式来实现高可用性。在这种模式下,每个队列的数据(包括元数据消息内容)会在多个节点上保留完整的副本。每当有新的消息被发布到队列中,这些消息会被自动复制到所有镜像节点上,从而确保即使某个节点宕机,其他节点仍然可以接管服务并继续处理消息 [^2]。 此外,RabbitMQ 使用 Erlang 的分布式特性来管理节点间的通信状态同步。在镜像队列中,主节点负责接收写请求,并将操作同步到从节点。当主节点失效时,系统会自动选举一个新的从节点作为新的主节点,以保证服务的连续性。 ### Kafka 的高可用性实现 Kafka 是一个典型的分布式消息队列系统,其高可用性主要依赖于分区(Partition)副本(Replica)机制 [^1]。每个主题(Topic)被划分为多个分区,每个分区又拥有多个副本,分布在不同的 Broker 上。其中,一个副本被指定为“领导者”(Leader),其余副本为“追随者”(Follower)。生产者消费者只与 Leader 副本进行交互。 为了保证一致性,Kafka 使用 ZooKeeper 来协调各个 Broker,并维护分区的 ISR(In-Sync Replica)列表。只有处于 ISR 中的副本才有资格参与选举成为新的 Leader。这种机制确保了即使某些 Broker 出现故障,也可以快速恢复而不会丢失数据。 ### ActiveMQ 的高可用性实现 ActiveMQ 提供了多种方式来实现高可用性,包括共享文件系统、JDBC 持久化以及基于网络连接器的主从架构等。其中,最常见的是使用共享存储的方式,多个 Broker 共享同一个持久化存储介质(如 SAN 或 NAS),并通过锁机制来决定哪个 Broker 处于活动状态。如果当前活动的 Broker 发生故障,另一个 Broker 会接管其职责并继续提供服务。 ### RocketMQ 的高可用性实现 RocketMQ 的高可用性主要体现在 NameServer Broker 的设计上。NameServer 是无状态的,多个实例之间互不通信,仅提供路由信息查询服务。Broker 则分为 Master Slave 两种角色,Master 负责处理客户端请求,Slave 则通过异步或同步方式从 Master 同步数据。当 Master 故障时,Slave 可以快速切换为主节点继续提供服务。 ### 高可用性通用策略 - **数据冗余**:无论是 RabbitMQ 的镜像队列还是 Kafka 的副本机制,都是通过多副本的方式来防止数据丢失。 - **故障转移(Failover)**:系统需要具备自动检测节点故障并进行切换的能力,确保服务不受影响。 - **一致性协议**:对于需要强一致性的场景,通常会引入一致性算法(如 Paxos、Raft)来确保副本间的数据一致性。 - **负载均衡与路由控制**:合理的消息分发策略客户端重试机制也是提升整体系统可用性的关键因素之一。 综上所述,不同消息队列系统根据自身架构特点采用了多样化的高可用性实现方案,但核心思想都围绕着数据冗余、故障转移一致性保障等方面展开。 ```java // 示例代码:Kafka 生产者配置示例,设置 acks 参数以提高可靠性 Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("acks", "all"); // 确保所有副本都确认收到消息后再认为发送成功 props.put("retries", 5); // 设置重试次数 props.put("retry.backoff.ms", 1000); // 设置重试间隔时间 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值