记得有次公司搞促销活动，流量增加，但是系统一直很平稳（我们开发的系统真牛），大家很开心的去聚餐，谈笑风声，气氛融洽，突然电话响起....
前端售卖系统，生成订单后，推送订单消息到rabbitmq，订单履约系统作为消费者，消费订单消息落库，做后续操作
很多同学都在使用 RocketMQ 时，经常会遇到消息堆积的问题。这篇文章，我们聊聊消息堆积的概念，以及如何应对消息堆积。
消费者在消费的过程中，消费的速度跟不上服务端的发送速度，未处理的消息会越来越多，消息出现堆积进而会造成消息消费延迟。
亲爱的读者朋友，今天我将为您带来一个极具挑战性的技术问题，这是一道来自字节跳动的面试题。问题是关于在生产环境中处理消息堆积问题，而不需要发布代码或扩容的情况下，如何迅速解决问题，以确保线上系统的正常运行。
这一篇我们要说的话题是消息的堆积处理，其实这个话题还是挺大的，因为消息堆积还是真的很令人头疼的，当堆积的量很大的时候，这真的是个很暴躁的问题，不过这时候真考验大家冷静的处理问题的能力了
以上方法可以根据实际应用场景进行选择和组合，以有效地处理RabbitMQ消息堆积问题。
要分析这个问题，首先我们得估算下在队列消息堆积的情况下进行生产消费，RabbitMQ的内存占用情况。
本文首先引出消息中间件通常需要解决哪些问题，在解决这些问题当中会遇到什么困难，Apache RocketMQ作为阿里开源的一款高性能、高吞吐量的分布式消息中间件否可以解决，规范中如何定义这些问题。然后本文将介绍RocketMQ的架构设计，以期让读者快速了解RocketMQ。 消息中间件需要解决哪些问题？ Publish/Subscribe 发布订阅是消息中间件的最基本功能，也是相对于传统RPC通信而言。在此不再详述。 Message Priority 规范中描述的优先级是指在一个消息队列中，每条消息都有不同
这篇文章就谈谈对mq各种问题的思考，以及不同的mq业务方案的解决，注意这篇文章为了解决在学习三大mq的一些问题，和不同mq差异导致的出现的不同的消息解决方案，这往往是很多人所忽视的，我教你！
Shovel能够可靠、持续地从一个Broker中的队列(作为源端，即source)拉取数据并转发至另一个Broker中的交换器(作为目的端，即destination)。作为源端的队列和作为目的端的交换器可以位于同一个Broker上，也可以位于不同的Broker上。
Apache RocketMQ在4.3.0版中已经支持分布式事务消息，这里RocketMQ采用了2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示。
如果架构中有用到mq，那就不可避免会遇到消息堆积的问题，因为我们没办法保证自己生产和消费永远都是正确的。像我们系统就遇到过很多次消息堆积情况，最严重的一次直接导致mq内存溢出，服务宕机，导致所有的mq消费全部出现异常，下面我就这个问题和童靴们唠叨唠叨。
PS：对于架构来说rocketMq的性能至关重要，只要用到消息队列的都是比较核心的应用，所以很多东西需要处理。
前面我们讲到了使用消息队列解决了我们电商系统的各种问题，削峰填谷、异步处理以及系统间解耦合，同时也对其重复消息问题进行了详细方案讲解（你的消息队列如何保证消息不丢失，且只被消费一次，这篇就教会你，秒杀系统每秒上万次下单请求，我们该怎么去设计）。那我们在消息队列的使用过程中还有没有需要注意的地方呢？
近期遇到了两个线上服务的问题，一个后端应用和一个前端项目，它们存在一些 bug 和历史遗留问题。为了不影响用户的使用体验，决定对它们进行一次优化。
我去DB查了一下近期的邮件发送情况，表示：“看着都挺正常的，线上没有异常的情况。可能邮件在redis里边堆积了，还没消费”
RocketMQ 的读写分离机制又跟上述描写的不太一致，RocketMQ 有属于自己的一套读写分离逻辑，它会判断主服务器的消息堆积量来决定消费者是否向从服务器拉取消息消费。
前面几篇文章讲述了rabbitmq消息存储的相关原理，也提到了有些参数可以进行配置。这些配置参数的微调在不同的场景中会有不同的效果。本文对其中一些参数进行说明，同时以实测数据结合性能分析工具进行剖析。
1、前言 在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止
当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积问题。
消息队列在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在消息队列的使用和原理方面对小伙伴们进行360°的刁难。
最近mq越来越火，很多公司在用，很多人在用，其重要性不言而喻。但是如果我让你回答下面的这些问题：
消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。
来源：https://www.jianshu.com/p/8f7ebbcbeee5
如果一个Topic堆积了大量的消息，可能会对RocketMQ的性能产生一定影响，但不是直接导致RocketMQ宕机的原因。主要影响包括：
根据RabbitMQ官方文档描述，可以通过“预取数量”来限制未被确认的消息个数，本质上这也是一种对消费者进行流控的方法。 详见：https://www.rabbitmq.com/consumer-prefetch.html#independent-consumers 。
我们在上篇已经说明了如何解决消息丢失的问题，也就是保证了消息的可靠性，那么其余两个问题同样重要，这篇我们将讲述其余两个问题的解决方式~！
（1）NameServer是一个几乎无状态的节点，可集群部署，节点之间无任何信息同步
分布式缓存方面，redis勇夺花魁。但对于消息队列mq来说，还处于百花齐放的年代。
本文介绍了腾讯云分布式消息队列服务CMQ的高可靠、强一致、高可用的架构设计、原理和关键技术。通过使用消息队列服务，应用可以解耦和异步化，提高系统的可扩展性和健壮性。CMQ在腾讯内部包括充值、红包、广告投放等场景广泛使用，对外服务时延敏感，支持全路径消息追踪，确保消息有序、可靠传输。
消息队列使用比较多的产品kafka，在各个领域都发挥了很大的作用，但是在以下的几种场景是无法满足需求。
MQ是消息服务中间件，基于高可用分布式集群技术，是消费模式基于发布订阅模式的消息系统。支持Java，C++以及.NET，PHP，Python，为分布式应用系统提供异步解耦、削峰填谷的能力，具备海量消息堆积、高吞吐、可靠重试等特性。具有消息查询，消息回溯(不是消息撤回，也不支持消息撤回)，消息轨迹查询，堆积监控报警功能。 MQ协议支持接入方式 : TCP、HTTP(RESTful 风格)、MQTT。MQ支持公网访问，但可用性较低。 MQ应用场景 : 分布式事务，物联网应用，实时计算(将产生的数据实时流入到实时计算引擎来实现)，同步大规模缓存。 实时计算引擎一般有 : Spark / Storm / EMR / ARMS / BeamRunner。 MQ拥有管理工具 : Web控制台，Open API，mqadmin命令集。拥有微消息队列(LMQ)，RocketMQ消息队列，Kafka消息队列，跨域中继服务(CRS)等组件。 Web控制台提供消息查询、消息轨迹查询、重置消费位点、资源统计、监控报警等操作。消息查询有三种方式 :** 根据Message ID(精确查询)，Message Key(模糊查询)以及Topic查询(范围查询)，HTTP消息目前只支持Message ID和Topic两种查询方式。** 消息轨迹查询只支持TCP和HTTP协议，可追踪消息从生产者发出到消费者消费的整个链路中各个相关节点的时间地点。 重置消费位点可跳过堆积的消息，即不想消费这部分消息，或者只想消费某个时间点后的消息（这些消息不论之前是否消费过）。 资源报表可对消息发送和消息消费的数据进行统计，暂不支持HTTP消费数据的统计查询。 监控报警一般用在消息堆积数或者延迟时间超过阈值之后，对报警接收人发送短信，如果发现消息堆积很多，可检查阈值是否设置过小导致消息堆积，可调整业务代码或者对消费者进行扩容，可使用jstack查看是否消费线程阻塞。 微消息队列(LMQ)基于MQTT(Message Queuing Telemetry Transport 消息队列遥测传输)协议，标准协议端口为1883，支持加密SSL，WebSocket，Flash接入方式。协议重要部分主要分为 : MQ Core Service(负责底层的消息存储和分发)，MQ私有协议服务器以及MQTT协议网关服务器(负责对客户端提供服务和协议转换)。主要使用场景有 : 直播互动、车联网、金融支付、即时聊天等。协议相关 : QoS(Quality of Service)指代消息传输的服务质量。它包括QoS0(最多分发一次)、QoS1(至少达到一次)和QoS2(仅分发一次)三种级别。cleanSession标识客户端建立TCP连接后是否关心之前状态(true or false)。 MQTT可进行实例管理(查看消息收发TPS、同时在线连接数、订阅关系数等信息，可设置实例报警)，可申请MQTT Topic，可为Topic申请MQTT Group ID(一组逻辑功能完全一致的节点共用的组名，代表一类相同功能的设备，必须拥有Topic的读写权限)。可进行签名计算和签名生成。 MQTT可获取离线消息，可主动拉取离线消息，客户端每次拉取消息数量最多为30条，拉取请求的最大频率限制为5次/秒。离线消息优先级低，对其进行有限和最终能处理即可，要求比较实时。 MQTT可获取客户端上下线事件(上下线事件触发时，会向后端MQ推送一条上下线消息，通过订阅这条消息获取)，上下线事件类型一般放在MQ的Tag中，有三种状态 : connect(客户端上线)，disconnect(客户端主动断开连接)，tcpclean(实际的TCP连接断开)。tcpclean代表客户端网络层连接的真实断开，判断客户端下线请使用tcpclean事件。 MQTT通过Token鉴权服务向客户端提供访问权限。客户端需要采用MQTT控制报文以同步发送模式并且QoS必须为1，来上传Token。客户端应该对Token做好持久化，监听Proxy下推的Token失效的通知消息，Token失效必须重新申请。 LMQ的Topic，ClientId长度最大为64个字符，消息大小最大为64K，消息保存时间最长为3天，单个客户端订阅Topic数量最大为30个(超过该限制数量的Topic会被丢弃)，消息顺序性为上行顺序。 跨域中继服务(CRS，跨域哦，实现服务发布与订阅，实现不同网络的服务互通)提供三种MQ消息发送方式 :可靠同步发送(发出消息响应后才能发下一个消息，应用场景广，如重要通知邮件、报名短信通知、营销短信系统)，可靠异步发送(不需要等待响应即可发下一个消息，应用场景一般是耗时长，对RT响应敏感的业务，如视频上传后通知转码服务，转码后通知推送转码结果)，One Way(单向发送，不需要响应的方式，耗时超短，对可靠性要求不高的场
pulsar版本是2.8.0，部署在openjdk11上，具体版本号是：11.0.12。 在aws海外部署，使用机型是c5a.2xlarge（8c16g），一共是3台，每台部署一个broker、bookie、zk。启动命令的参数没有修改都是默认值。
RocketMQ作为一款高性能消息中间件，其核心优势是可靠的消息存储、消息发送的高性能与低延迟、强大的消息堆积能力与消息处理能力、严格的顺序消息模式等。RocketMQ的另一个核心思想是懂得取舍。软件设计不可能做到面面俱到，消息中间件的理想状态是一条消息能且只能被消费一次，但要做到这一点，必然需要牺牲性能。RocketMQ的设计者解决这一难题的办法是不去解决，即保证消息至少被消费一次，但不承诺消息不会被消费者多次消费，其消费的幂等由消费者实现，从而极大地简化了其实现内核，提高了RocketMQ的整体性能。
Rabbitmq大体上可以分为两部分（Exchange和MQ），所有发送给RabbitMQ的消息都会先交给Exchange， Exchange的功能类似于路由器，它会根据自身类型（fanout、direct、topic）以及binding信息决定一个消息该被放到哪一个MQ， 而MQ的功能在于暂时存储消息，并将MQ中的消息以订阅或者poll的方式交给接收方。
ckafka消费慢是用户经常遇到的问题，消费慢直接体现为消息堆积数上升，消息堆积数上升意味这消费者没有及时消费到消息，依赖消费者的下游应用就可能堵塞。因此，在观测到ckafka消费慢后及时进行有效排查、定位问题，用于降低消费慢对业务的影响，是很有必要的。
RocketMQ作为一款分布式的消息中间件（阿里的说法是不遵循任何规范的，所以不能完全用JMS的那一套东西来看它），经历了Metaq1.x、Metaq2.x的发展和淘宝双十一的洗礼，在功能和性能上远超ActiveMQ。
在IM这种讲究高并发、高消息吞吐的互联网场景下，MQ消息中间件是个很重要的基础设施，它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色，当然MQ消息中间件的作用远不止于此，它的价值不仅仅存在于技术上，更重要的是改变了以往同步处理消息的思路（比如进行IM消息历史存储时，传统的信息系统作法可能是收到一条消息就马上同步存入数据库，这种作法在小并发量的情况下可以很好的工作，但互联网大并发环境下就是灾难）。
导语 | 消息队列是分布式系统中重要的中间件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。本文对Kafka、Pulsar、RocketMQ、RabbitMQ、NSQ这几个消息队列组件进行了一些调研，并整理了相关资料，为业务对MQ中间件选型提供参考。 一、概述 消息队列是分布式系统中重要的中间件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。分布式系统可以借助消息队列的能力，轻松实现以下功能： 解耦，将一个流程的上游和下游拆开，上游专注生产消息，下游专注处理消息。 广播，一个上游生产的消息轻松被
转自：https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafka 淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用MySQL作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订
根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。
对于rabbitmq的queue来说，是可以设置下面三个参数的，x-max-length，x-max-length-bytes， x-overflow。一旦x-max-length（这里是设置的queue最大容纳的消息数量），x-max-length-bytes（这里是queue中的消息数量与消息大小乘积的总量）超过了限制之后，就会根据x-overflow里面设置的模式开始处理，对于x-overflow有一个reject-publish模式，打开之后，生产者通过confrim生产的消息，在rabbitmq就会被拒绝，回复message unacked.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
