RabbitMQ几大应用问题

ops/2024/11/1 4:06:36/

目录

1.幂等性保障

2.顺序性保障

3.消息积压


1.幂等性保障

(1)介绍幂等性

幂等性,最早期是数学和计算机科学中某些运算的性质,它们可以被多次应用,而不会改变初始应用的结果

比如说,重复多次调用同一个函数,函数返回的结果也相同。

比如,牛羊吃进去的是草,拉出来的也是

(2)MQ上的幂等性

定义:对于MQ的幂等性,是指同一条消息,进行多次消费,对系统的影响的相同的

为什么会有同一个消息多次消费,是因为可能触发重试等机制

所以对于消息中间件,对消息传输保障分为三个层级:

1)At most once:最多一次。消息可能会丢失,但绝不会重复传输。

2)At least once:最少一次。消息绝不会丢失,但可能会重复传输。

3)Exactly once:恰好一次。每条消息肯定会被传输一次且传输一次。

对于目前的中间件来说,只能支持前面两种,最后一种也无法做到。

(3)MQ如何保障幂等性

为什么要保证幂等性?

比如用户下单一个商品,在支付页面因为网络缘由,多次点击,这个时候就只能认为是一次消费。

所以幂等性保障,就是可以正确的处理相同重复的消息。对于RabbitMQ保障幂等性有两个方面:保证全局ID和代码逻辑判断,主要方法还是需要靠全局唯一ID

1)全局唯一ID

做法:给每条消息分配一个全局唯一的ID。这个ID可以自定义生成,比如UUID,UUID+时间戳等。

当消费者收到消息后,就可以根据唯一ID判断该消息是否已经被消费过,如果已经被消费观过,则可以不做处理,进而可以避免重复消费的问题。

对于未消费过的消息,就可以进行消费;在消费完成后,就需要把该ID进行保存起来,表明该ID的消息已经被消费过。

2)业务逻辑判断

这个方面就考验程序猿的代码能力了。比如通过检查数据库中是否已经存在相关的数据记录;或者在处理消息前,检查相关业务的状态,确保消息对应的操作尚未执行,然后再进行处理。


2.顺序性保障

顺序性保障,是指消费者消费的消息和生产者生产的消息顺序一致。

对于很多的业务场景,对顺序性是没有要求的;但是一些场景下是有要求的,比如对同一个用户的同一个信息进行修改。

(1)会打破顺序性的场景

1)多个消费者

当存在多个消费者的时候,消息被哪一个消费者消费是不确定的,也可能并行处理,就会导致消息的顺序性无法保证

2)网络波动或异常

在消息传递过程中,如果出现网络波动或者异常,可能导致消息会重新入队,进行直接影响顺序性。

3)消息重试

消费者消费完成后没有及时对消息进行确认,或者确认丢失,MQ可能认为消息未发送成功进而重试,也会导致消息处理的顺序性问题。

4)消息路由问题

消息会根据不同的路由规则进入不同的队列,因为每个队列的情况都会不太一样,就无法保证全局的顺序性。

5)死信队列

当消息因为一些原因进入死信队列后,再被消费者消费,就无法保证消息的顺序性和生产者发送消息的顺序一致。


上述的比较常见的场景,如果需要保障顺序性,就需要做出相应的处理。

(2)如何保障顺序性

消息顺序性保障分为:局部顺序性保障和全局顺序性保障。一般都为局部性保障,全局性保障较为困难。

  1. 局部顺序性保障:指的是在单个队列内部保证消息的顺序
  2. 全局顺序性保障:指的是在多个队列或者多个消费者之间的顺序性保障

下面介绍两个常用的顺序性保障策略

1)单个消费者和单个队列

这样的策略下,就能从很大的几个方面下杜绝了一些情况,进而跟容易保障消息的顺序性问题。

2)分区消费

这里的分区指的是将一个队列划分成多个区域,每个区域引入一个消费者进行消费,这个时候保障每个分区内的顺序性即可。

3)消息确认机制

使用手动消息确认机制,消费者在处理完⼀条消息后,显式地发送确认,这样RabbitMQ才会移除并继续发送下⼀条消息.

4)业务逻辑控制

在某些情况下,即使消息乱序到达,也可以在业务逻辑层⾯实现顺序控制,比如通过在消息中嵌入序列号,并在消费时根据这些信息来处理


3.消息积压

消息积压,指的是在消息队列中,待处理的消息数量超过了消费者的处理能力,导致消息在队列中不断堆积的现象。

(1)产生的原因

  • 消息生产过快

在高流量或者高负载的情况下,生产者以极高的速率发送消息,超过了消费者的处理能力,这也就是本质原因

  • 消费者处理能力不足
  1. 消费端业务逻辑复杂,耗时长
  2. 消费端代码性能低
  3. 系统资源限制,如CPU、内存、磁盘I/O等也会限制消费者处理消息的效率
  4. 异常处理不当。比如消费者在处理消息时出现异常,导致消息无法被正确处理和确认
  • 网络问题

比如网络延迟或不稳定,消费者无法及时接收或者确认消息,最终导致消息积压

  • RabbitMQ服务器配置偏低

消息积压会导致系统性能下降,影响用户体验,甚至导致系统崩溃

(2)解决方案

  • 提高消费者效率
  1. 增加消费者实例数量,比如多引入新的机器
  2. 优化业务逻辑,比如使用多线程来处理业务
  3. 设置prefetchCount,当一个消费者阻塞时,消息转发到其他未阻塞的消费者中
  4. 消息发送异常时,设置合适的重试策略,或者转入死信队列
  • 限制生产者速率
  1. 流量控制:在消息生产者中实现流量控制逻辑,根据消费者处理能力动态调整发送速率
  2. 限流:使用限流工具,为消息发送速率设置一个上限
  3. 设置过期时间:如果消息过期未消费,可以配置死信队列,以避免消息丢失,并减少对主队列的压力
  • 资源与配置优化

比如升级RabbitMQ服务器的硬件,调整RabbitMQ的配置参数等


http://www.ppmy.cn/ops/130029.html

相关文章

深度学习:交叉熵损失(Cross Entropy Loss)

交叉熵损失(Cross Entropy Loss) 定义和数学表达 交叉熵损失是一种常用于评估概率分类模型性能的损失函数。它衡量的是模型预测的概率分布与真实分布之间的差异。交叉熵损失特别适用于分类任务中,尤其是多类分类问题。 数学上,…

【K8S】kubernetes-dashboard.yaml

https://raw.githubusercontent.com/kubernetes/dashboard/v3.0.0-alpha0/charts/kubernetes-dashboard.yaml 以下链接的内容: 由于国内访问不了,找到一些方法下载了这个文件内容, 部署是mages 对象的镜像 WEB docker.io/kubernetesui/dash…

智能护栏碰撞监测终端:内蒙古高速的安全守护者

​ ​一、引言 ​ ​在内蒙古那辽阔的大地上,高速公路如动脉般纵横交错,是经济发展与人员流动的重要通道。而保障这些公路安全运行的关键因素之一,便是智能护栏碰撞监测终端。它以其卓越的性能,实时为公路安全保驾护航&…

vue封装信号强度

图标下载链接: https://pan.baidu.com/s/1828AidkCKU1KTkw1SvBwQg?pwd4k7n 共五格信号 信号5为绿色,信号4为绿色,信号3为黄色,信号2为黄色,信号1为红色,信号0为灰色。 子组件 /components/SignalStrength/index.vu…

SpringMVC实战(3):拓展

四、RESTFul风格设计和实战 4.1 RESTFul风格概述 4.1.1 RESTFul风格简介 RESTful(Representational State Transfer)是一种软件架构风格,用于设计网络应用程序和服务之间的通信。它是一种基于标准 HTTP 方法的简单和轻量级的通信协议&…

安全研究 | 不同编程语言中 IP 地址分类的不一致性

作为一名安全研究人员,我分析了不同编程语言中 IP 地址分类 的行为。最近,我注意到一些有趣的不一致性,特别是在循环地址和私有 IP 地址的处理上。在这篇文章中,我将分享我对此问题的观察和见解。 设置 我检查了多种编程语言&am…

如何应对PDF无法转换成其他格式?常见原因与解决方法解析

在日常工作中,PDF文件的格式转换是非常常见的操作,无论是转换为Word、Excel,还是其他格式,都会有一些方便的工具支持。然而,有时在转换PDF时可能会遇到无法转换的问题。这个时候,可以看看是不是以下几个原因…

vue3项目中引入阿里图标库

开篇 本篇的主题是在vue3项目中引入阿里图标库 步骤 注册阿里图标库账号(阿里图标),并创建项目 将图标加入项目中 将需要的图标先加入购物车,随后加入到项目中 生成项目代码 在项目中生成项目代码,便于后续复制到vue项目中 ## 在vue3项目…