分布式消息服务中间价——《RabbitMQ》

liuwangleoooO

已于 2022-06-02 02:29:50 修改

阅读量467

点赞数

分类专栏：高级后端开发工程师文章标签：分布式队列

于 2021-04-29 16:14:33 首次发布

本文链接：https://blog.csdn.net/qq_36581961/article/details/115898633

版权

高级后端开发工程师专栏收录该内容

9 篇文章 2 订阅

订阅专栏

介绍

主要目的

了解消息中间件背景知识、使用场景、发展
掌握RabbitMQ、RocketMQ、Kafka这三款主流的消息中间件的架构，模型，和使用(开发、安装、集群部署、运维、监控)
掌握消息的可靠性、幂等性、顺序消息、延迟消息、事务消息等进阶的知识，以及大规模生产环境中的使用经验，轻松对应各种复杂的业务场景。
掌握顶级开源消息中间价的源码，理解背后的架构设计思想以及在高性能存储系统、网络编程等方面的技巧（会涉及网络通信、操作系统等底层知识）
理解主流消息中间件的优缺点，具备技术选型能力

面试常见的题目
项目中为什么要使用消息中间件
项目中为什么使用RocketMQ而不是RabbitMQ
系统TPS有多少？引入消息中间件之后，系统一定不会被撑爆吗
消息中间件出现大量的消息堆积，会产生什么后果？
如何发现大面积的消息堆积？采取哪些应对措施？问题产生的根源是什么？如何有效的避免？

主要内容

消息中间件概述

分布式系统中如何进行远程通信
为什么使用消息中间件？市场上有哪些产品？有什么优缺点？如何选择
JMS规范和AMQP协议

Rabbit

RabbitMQ架构、环境准备和整合
高级特性如消息的可靠性保障、死信队列、延迟队列
RabbitMQ的集群、运维
源码分析，解析RabbitMQ的启动过程、交换器的实现、队列的实现

消息中间价概述

分布式架构通信

分布式架构通信原理

SOA架构
根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间相互独立。优点：分布式、松耦合、扩展灵活、可重用。SOA架构系统中，使用Dubbo和Zookeeper进行服务间的远程通信。优点：Dubbo使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以减少报文的体积，提高传输效率。

微服务
SpringCloud中使用Feign解决服务之间远程通信的问题。
Feign：轻量级RESTful的HTTP服务客户端，广泛应用于Spring Cloud中。符合面向接口化的编程习惯。
本质：封装了HTTP调用流程，类似Dubbo的服务调用。多用于同步远程调用。

RPC主要基于TCP/UDP协议，HTTP协议是应用层协议，是构建在传输层协议TCP之上的，RPC效率更高，RPC长连接：不必每次通信都像HTTP一样三次握手，减少网络开销；
HTTP服务开发迭代更快：在接口不多，系统与系统之间交互比较少的情况下，HTTP就显得更加方便；相反，在接口比较多，系统与系统之间交互比较多的情况下，HTTP就没有RPC有优势。

分布式同步通信的问题

在电商项目中，如何后台添加商品信息，该信息放到数据库。我们同时，需要更新搜索引擎的倒排索引，同时假如有商品页面的静态化处理，也需要更新该页面信息。
在这里插入图片描述
针对上边的问题，我们该如何解决呢？

方法一：可以在后台添加商品的方法中，如果数据插入数据库成功，就调用更新倒排索引的方法，接着调用更新静态化页面的方法
如果在此过程中更新失败怎么办？这个过程存在同步调用处理不当的问题。在高并发的添加商品下，效率会降低。

方法二：可以先执行添加商品的方法，商品添加成功，将更新索引和更新静态页面的任务缓存到一个公共的位置，然后由相应的服务从该位置获取任务来执行
此时，由于添加商品仅仅是将数据插入数据库，然后将任务信息缓存，调用立刻返回。对于添加商品方法的调用，不会存在线程阻塞，不会存在调用栈崩溃。再考虑远一点。 由于更新倒排索引的的服务和更新静态页面的服务要从公共的缓存或者叫任务池中取出任务并执行，它们也会有执行失败的问题，也需要重试。如果一直更新失败，也需要一个方式来处理。比如如果更新失败，则每隔3秒钟重试一次，重试三次都失败则放弃执行。然后将错误结果放到另一个公共的地方，等待后续的补偿，无论是手工还是自动的。还有问题：

这个公共的任务池，会不会宕机？会不会服务不可用？如何解决？
你一定确信消息发送到任务池了吗？
如果在向任务池发送任务失败该如何处理？
如果重试的时候发送成功了，但是实际上发送了多次，更新倒排索引服务和更新静态页面服务
会不会重复执行？
如果重复执行，最终结果会不会不一样？
。。。

看来真是解决了一个问题，引进来三个问题。如果上述的问题都由我们从0开始解决，开发难度可想而知。分布式服务中，由于业务拆分，应用也需要拆分，甚至数据库分库分表。但是完成一个业务处理，往往要设计到多个模块之间的协调处理。此时模块之间，服务与服务之间以及客户端与服务端之间的通信将变得非常复杂。

分布式异步通信模式

在这里插入图片描述
比较典型的“生产者消费者模式”，可以跨平台、支持异构系统，通常借助消息中间件来完成。

优点：系统间解耦，并具有一定的可恢复性，支持异构系统，下游通常可并发执行，系统具备弹性。服务解耦、流量削峰填谷等
缺点：消息中间件存在一些瓶颈和一致性问题，对于开发来讲不直观且不易调试，有额外成本。

使用异步消息模式需要注意的问题：

哪些业务需要同步处理，哪些业务可以异步处理？
如何保证消息的安全？消息是否会丢失，是否会重复？
请求的延迟如何能够减少？
消息接收的顺序是否会影响到业务流程的正常执行？
消息处理失败后是否需要重发？如果重发如何保证幂等性？

消息中间件简介

概述

面向消息的系统（消息中间件）是在分布式系统中完成消息的发送和接收的基础软件。消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。消息中间件就是在通信的上下游之间截断：break it，Broker然后利用中间件解耦、异步的特性，构建弹性、可靠、稳定的系统。体会一下：“必有歹人从中作梗”，”定有贵人从中相助“。异步处理、流量削峰、限流、缓冲、排队、最终一致性、消息驱动等需求的场景都可以使用消息中间件。

自定义消息中间件

并发编程领域经典面试题：请使用java代码来实现“生产者消费者模式”。BlockingQueue（阻塞队列）是java中常见的容器，在多线程编程中被广泛使用。当队列容器已满时生产者线程被阻塞，直到队列未满后才可以继续put；当队列容器为空时，消费者线程被阻塞，直至队列非空时才可以继续take
kouzhao.py

package com.lagou.demo;
	public class KouZhao {
	private String id;
	private String type;
	public KouZhao(String id, String type) {
		this.id = id;
		this.type = type;
	}
	public String getId() {
		return id;
	}
	public void setId(String id) {
		this.id = id;
	}
	public String getType() {
		return type;
	}
	public void setType(String type) {
		this.type = type;
	}
	@Override
	public String toString() {
		return "KouZhao{" +
		"id='" + id + '\'' +
		", type='" + type + '\'' +
		'}';
	}
}

Producer.java

package com.lagou.demo;
import java.util.UUID;
import java.util.concurrent.BlockingQueue;
public class Producer implements Runnable {
	private final BlockingQueue<KouZhao> blockingQueue;
	public Producer(BlockingQueue<KouZhao> blockingQueue) {
		this.blockingQueue = blockingQueue;
	}
	@Override
	public void run() {
		while (true) {
			try {
				Thread.sleep(200);
				if (blockingQueue.remainingCapacity() > 0) {
					KouZhao kouZhao = new
					KouZhao(UUID.randomUUID().toString(), "N95");
					blockingQueue.add(kouZhao);
					System.out.println("我在生产口罩，当前库存是：" +
					blockingQueue.size());
				} else {
					System.out.println("我的仓库已经堆满了" +
					blockingQueue.size() + "个口罩，快来买口罩啊！");
				}
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}
}

Consumer.java

package com.lagou.demo;
import java.util.concurrent.BlockingQueue;
public class Consumer implements Runnable {
	private final BlockingQueue<KouZhao> blockingQueue;
	public Consumer(BlockingQueue<KouZhao> blockingQueue) {
		this.blockingQueue = blockingQueue;
	}
	@Override
	public void run() {
		while (true) {
			try {
				Thread.sleep(100);
				long startTime = System.currentTimeMillis(); // 获取开始时间
				KouZhao kouZhao = blockingQueue.take();
				long endTime = System.currentTimeMillis(); // 获取结束时间
				System.out.println("我消费了口罩：" + kouZhao + ", 等到货时我阻
				塞了" + (endTime - startTime) + "ms");
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}
}

app.java

package com.lagou.demo;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
public class App {
	public static void main(String[] args) throws InterruptedException {
		BlockingQueue<KouZhao> queue = new ArrayBlockingQueue<>(20);
		Producer producer = new Producer(queue);
		Consumer consumer = new Consumer(queue);
		new Thread(producer).start();
		Thread.sleep(20000);
		new Thread(consumer).start();
	}
}

上述代码放到生产环境显然是不行的，比如没有集群，没有分布式，玩儿法太单一，不能满足企业级应用的要求。。。
比如：消息有没有持久化？怎么确定消息一定能发送成功？怎么确定消息一定能被消费成功？高并发下的性能怎么样？系统可靠吗？
有没有Pub/Sub模式？有没有考虑过限流？。。。

主流消息中间件及选型

在传统金融机构、银行、政府机构等有一些老系统还在使用IBM等厂商提供的商用MQ产品。当前业界比较流行的开源消息中间件包括：ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等，其中应用最为广泛的要数RabbitMQ、RocketMQ、Kafka这三款。Redis在某种程度上也可以是实现类似“Queue”和“Pub/Sub”的机制，严格意义上不算消息中间件。

选取原则

首先，产品应该是开源的。开源意味着如果队列使用中遇到bug，可以很快修改，而不用等待开发者的更新。其次，产品必须是近几年比较流行的，要有一个活跃的社区。这样遇到问题很快就可以找到解决方法。同时流行也意味着bug较少。流行的产品一般跟周边系统兼容性比较好。最后，作为消息队列，要具备以下几个特性：

消息传输的可靠性：保证消息不会丢失。
支持集群，包括横向扩展，单点故障都可以解决。
性能要好，要能够满足业务的性能需求。

RabbitMQ

RabbitMQ开始是用在电信业务的可靠通信的，也是少有的几款支持AMQP协议的产品之一。
优点：

轻量级，快速，部署使用方便
支持灵活的路由配置。RabbitMQ中，在生产者和队列之间有一个交换器模块。根据配置的路由规则，生产者发送的消息可以发送到不同的队列中。路由规则很灵活，还可以自己实现。
RabbitMQ的客户端支持大多数的编程语言。

缺点：

如果有大量消息堆积在队列中，性能会急剧下降
RabbitMQ的性能在Kafka和RocketMQ中是最差的，每秒处理几万到几十万的消息。如果应用要求高的性能，不要选择RabbitMQ。
RabbitMQ是Erlang开发的，功能扩展和二次开发代价很高。

RocketMQ

RocketMQ是一个开源的消息队列，使用java实现。借鉴了Kafka的设计并做了很多改进。RocketMQ主要用于有序，事务，流计算，消息推送，日志流处理，binlog分发等场景。经过了历次的双11考验，性能，稳定性可可靠性没的说。
RocketMQ几乎具备了消息队列应该具备的所有特性和功能。

java开发，阅读源代码、扩展、二次开发很方便。
对电商领域的响应延迟做了很多优化。在大多数情况下，响应在毫秒级。如果应用很关注响应时间，可以使用RocketMQ。
性能比RabbitMQ高一个数量级，每秒处理几十万的消息。

缺点：跟周边系统的整合和兼容不是很好。

Kafka

Kafka的可靠性，稳定性和功能特性基本满足大多数的应用场景。跟周边系统的兼容性是数一数二的，尤其是大数据和流计算领域，几乎所有相关的开源软件都支持Kafka。Kafka高效，可伸缩，消息持久化。支持分区、副本和容错。Kafka是Scala和Java开发的，对批处理和异步处理做了大量的设计，因此Kafka可以得到非常高的性能。它的异步消息的发送和接收是三个中最好的，但是跟RocketMQ拉不开数量级，每秒处理几十万的消息。如果是异步消息，并且开启了压缩，Kafka最终可以达到每秒处理2000w消息的级别。但是由于是异步的和批处理的，延迟也会高，不适合电商场景。

	RabbitMQ	RocketMQ	Kafka
单机吞吐量	1w量级	10w量级	10w量级
开发语言	Erlang	Java	Java和Scala
消息延迟	微妙	毫秒	毫秒
消息丢失	可能性很低	参数优化后可以0丢失	参数优化后可以0丢失
消费模式	推拉	推拉	拉取
主题数量对吞吐量影响	\	几百上千个主题会对吞吐量有一个小的影响	几十上百个主题会极大影响吞吐量
可用性	高(主从)	很高(主从)	很高(分布式)

消息中间件应用场景

消息中间件的使用场景非常广泛，比如，12306购票的排队锁座，电商秒杀，大数据实时计算等。

电商秒杀案例：
比如6.18，活动从0:00开始，仅限前 200 名，秒杀即将开始时，用户会疯狂刷新 APP或者浏览器来保证自己能够尽早的看到商品。

当秒杀开始前，用户在不断的刷新页面，系统应该如何应对高并发的读请求呢？
在秒杀开始时，大量并发用户瞬间向系统请求生成订单，扣减库存，系统应该如何应对高并发的写请求呢？

系统应该如何应对高并发的读请求

使用缓存策略将请求挡在上层中的缓存中
能静态化的数据尽量做到静态化
加入限流（比如对短时间之内来自某一个用户，某一个IP、某个设备的重复请求做丢弃处理）

系统应该如何应对高并发的写请求
生成订单，扣减库存，用户这些操作不经过缓存直达数据库。如果在 1s内，有 1 万个数据连接同时到达，系统的数据库会濒临崩溃。如何解决这个问题呢？我们可以使用 消息队列。
消息队列的作用：

削去秒杀场景下的峰值写流量——流量削峰
通过异步处理简化秒杀请求中的业务流程——异步处理
解耦，实现秒杀系统模块之间松耦合——解耦

削去秒杀场景下的峰值写流量
将秒杀请求暂存于消息队列，业务服务器响应用户“秒杀结果正在处理中。。。”，释放系统资源去处理其它用户的请求。
削峰填谷，削平短暂的流量高峰，消息堆积会造成请求延迟处理，但秒杀用户对于短暂延迟有一定容忍度。

秒杀商品有 1000 件，处理一次购买请求的时间是 500ms，那么总共就需要 500s 的时间。这时你部署 10 个队列处理程序，那么秒杀请求的处理时间就是 50s，也就是说用户需要等待 50s 才可以看到秒杀的结果，这是可以接受的。这时会并发 10 个请求到达数据库，并不会对数据库造成很大的压力。

通过异步处理简化秒杀请求中的业务流程：先处理主要的业务，异步处理次要的业务。如主要流程是生成订单、扣减库存；次要流程比如购买成功之后会给用户发优惠券，增加用户的积分。此时秒杀只要处理生成订单，扣减库存的耗时，发放优惠券、增加用户积分异步去处理了。解耦，实现秒杀系统模块之间松耦合

将秒杀数据同步给数据团队，有两种思路：

使用 HTTP 或者 RPC 同步调用，即提供一个接口，实时将数据推送给数据服务。系统的耦合度高，如果其中一个服务有问题，可能会导致另一个服务不可用。
使用消息队列
将数据全部发送给消息队列，然后数据服务订阅这个消息队列，接收数据进行处理。

拉勾B端C端数据同步案例：

拉勾网站分B端和C端，B端面向企业用户，C端面向求职者。这两个模块业务处理逻辑不同，数据库表结构不同，实际上是处于解耦的状态。但是各自又需要对方的数据，需要共享：如

当C端求职者在更新简历之后，B端企业用户如何尽早看到该简历更新？
当B端企业用户发布新的职位需求后，C端用户如何尽早看到该职位信息？

无论是B端还是C端，都有各自的搜索引擎和缓存，B端需要获取C端的更新以更新搜索引擎和缓
存；C端需要获取B端的更新以更新C端的搜索引擎与缓存。

如何解决B端C端数据共享的问题？解决方式：

同步方式：B端和C端通过RPC或WebService的方式发布服务，让对方来调用，以获取对方的
信息。求职者每更新一次简历，就调用一次B端的服务，进行数据的同步；B端企业用户每更
新职位需求，就调用C端的服务，进行数据的同步。
异步方式：使用消息队列，B端将更新的数据发布到消息队列，C端将更新的数据发布到消息
队列，B端订阅C端的消息队列，C端订阅B端的消息队列。

使用同步方式，B端和C端耦合比较紧密，如果其中一个服务有问题，可能会导致另一个服务不可用。比如C端的RPC挂掉，企业用户有可能无法发布新的职位信息，因为发布了对方也看不到；B端的RPC挂掉，求职者可能无法更新简历，因为即使简历更新了，对方也看不到。

你可能会想，可以让B端或C端在对方RPC挂掉的时候，先将该通知消息缓存起来，等对方服务恢复之后再进行同步。这正是引入异步方式，使用消息队列的目的。使用消息队列的异步方式，对B端C端进行解耦，只要消息队列可用，双方都可以将需要同步的信息发送到消息队列，对方在收到消息队列推送来的消息的时候，各自更新自己的搜索引擎，更新自己的缓存数据。

支付宝购买电影票
在这里插入图片描述

如上图，用户在支付宝购买了一张电影票后很快就收到消息推送和短信（电影院地址、几号厅、座位号、场次时间等），同时用户会积累一定的会员积分。这里，交易系统并不需要一直等待消息送达等动作都完成后才返回成功，允许一定延迟和瞬时不一致（最终一致性），而且后面两个动作通常可以并发执行。如果后期监控大盘想要获取实时交易数据，只需要新增个消费者程序并订阅该消息即可，交易系统对此并不感知，松耦合。

JMS规范和AMQP协议

RabbitMQ

RabbitMQ架构与实战

RabbitMQ介绍、概念、基础架构

RabbitMQ介绍

RabbitMQ，俗称“兔子MQ”（可见其轻巧，敏捷），是目前非常热门的一款开源消息中间件，不管是互联网行业还是传统行业都广泛使用（最早是为了解决电信行业系统之间的可靠通信而设计）。

高可靠性、易扩展、高可用、功能丰富
支持大多数（甚至冷门）的编程语言客户端。
RabbitMQ遵循AMQP协议，自身采用Erlang（一种由爱立信开发的通用面向并发编程的语言）编写。
RabbitMQ也支持MQTT等其他协议。

RabbitMQ具有很强大的插件扩展能力，官方和社区提供了非常丰富的插件可供选择：https://www.rabbitmq.com/community-plugins.html

RabbitMQ整体逻辑架构

在这里插入图片描述

RabbitMQ Exchange类型

RabbitMQ常用的交换器类型有： fanout 、 direct 、 topic 、 headers 四种。
fanout
会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中
在这里插入图片描述
Direct
direct类型的交换器路由规则很简单，它会把消息路由到那些BindingKey和RoutingKey完全匹配的队列中，如下图：

Topic
topic类型的交换器在direct匹配规则上进行了扩展，也是将消息路由到BindingKey和RoutingKey相匹配的队列中，这里的匹配规则稍微不同，它约定：BindingKey和RoutingKey一样都是由"."分隔的字符串；BindingKey中可以存在两种特殊字符*和#，用于模糊匹配，其中*用于匹配一个单词，#用于匹配多个单词（可以是0个）。
在这里插入图片描述
Headers
headers类型的交换器不依赖于路由键的匹配规则来路由信息，而是根据发送的消息内容中的headers属性进行匹配。在绑定队列和交换器时指定一组键值对，当发送的消息到交换器时，RabbitMQ会获取到该消息的headers，对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果匹配，消息就会路由到该队列。headers类型的交换器性能很差，不实用。

RabbitMQ数据存储

存储机制
RabbitMQ消息有两种类型

持久化消息和非持久化消息
这两种消息都会被写入磁盘

持久化消息在到达队列时写入磁盘，同时会内存中保存一份备份，当内存吃紧时，消息从内存中清除。这会提高一定的性能。
非持久化消息一般只存于内存中，当内存压力大时数据刷盘处理，以节省内存空间。
RabbitMQ存储层包含两个部分：队列索引和消息存储
在这里插入图片描述
队列索引：rabbit_queue_index
索引维护队列的落盘消息的信息，如存储地点、是否已被给消费者接收、是否已被消费者ack等。每个队列都有相对应的索引。

索引使用顺序的段文件来存储，后缀为.idx，文件名从0开始累加，每个段文件中包含固定的segment_entry_count 条记录，默认值是16384。每个index从磁盘中读取消息的时候，至少要在内存中维护一个段文件，所以设置 queue_index_embed_msgs_below 值得时候要格外谨慎，一点点增大也可能会引起内存爆炸式增长。

消息存储：rabbit_msg_store
消息以键值对的形式存储到文件中，一个虚拟主机上的所有队列使用同一块存储，每个节点只有一个。存储分为持久化存储（msg_store_persistent）和短暂存储（msg_store_transient）。持久化存储的内容在broker重启后不会丢失，短暂存储的内容在broker重启后丢失。

store使用文件来存储，后缀为.rdq，经过store处理的所有消息都会以追加的方式写入到该文件中，当该文件的大小超过指定的限制（file_size_limit）后，将会关闭该文件并创建一个新的文件以供新的消息写入。文件名从0开始进行累加。在进行消息的存储时，RabbitMQ会在ETS（Erlang TermStorage）表中记录消息在文件中的位置映射和文件的相关信息。

消息（包括消息头、消息体、属性）可以直接存储在index中，也可以存储在store中。最佳的方式是较小的消息存在index中，而较大的消息存在store中。这个消息大小的界定可以通过queue_index_embed_msgs_below 来配置，默认值为4096B。当一个消息小于设定的大小阈值时，就可以存储在index中，这样性能上可以得到优化。一个完整的消息大小小于这个值，就放到索引中，否则放到持久化消息文件中.

如果消息小于这个值，就在索引中存储，如果消息大于这个值就在store中存储
大于这个值的消息存储于msg_store_persistent目录中的.rdq文件中
小于这个值的消息存储于.idx索引文件中：

读取消息时，先根据消息的ID（msg_id）找到对应存储的文件，如果文件存在并且未被锁住，则直接打开文件，从指定位置读取消息内容。如果文件不存在或者被锁住了，则发送请求由store进行处理。

删除消息时，只是从ETS表删除指定消息的相关信息，同时更新消息对应的存储文件和相关信息。在执行消息删除操作时，并不立即对文件中的消息进行删除，也就是说消息依然在文件中，仅仅是标记为垃圾数据而已。当一个文件中都是垃圾数据时可以将这个文件删除。当检测到前后两个文件中的有效数据可以合并成一个文件，并且所有的垃圾数据的大小和所有文件（至少有3个文件存在的情况下）的数据大小的比值超过设置的阈值garbage_fraction（默认值0.5）时，才会触发垃圾回收，将这两个文件合并，执行合并的两个文件一定是逻辑上相邻的两个文件。合并逻辑：

锁定这两个文件
先整理前面的文件的有效数据，再整理后面的文件的有效数据
将后面文件的有效数据写入到前面的文件中
更新消息在ETS表中的记录
删除后面文件

队列结构
通常队列由rabbit_amqqueue_process和backing_queue这两部分组成，rabbit_amqqueue_process负责协议相关的消息处理，即接收生产者发布的消息、向消费者交付消息、处理消息的确认（包括生产端的confirm和消费端的ack）等。backing_queue是消息存储的具体形式和引擎，并向rabbit_amqqueue_process提供相关的接口以供调用。

如果消息投递的目的队列是空的，并且有消费者订阅了这个队列，那么该消息会直接发送给消费者，不会经过队列这一步。当消息无法直接投递给消费者时，需要暂时将消息存入队列，以便重新投递。
rabbit_variable_queue.erl 源码中定义了RabbitMQ队列的4种状态：

alpha：消息索引和消息内容都存内存，最耗内存，很少消耗CPU
beta：消息索引存内存，消息内存存磁盘
gama：消息索引内存和磁盘都有，消息内容存磁盘
delta：消息索引和内容都存磁盘，基本不消耗内存，消耗更多CPU和I/O操作

消息存入队列后，不是固定不变的，它会随着系统的负载在队列中不断流动，消息的状态会不断发送变化。持久化的消息，索引和内容都必须先保存在磁盘上，才会处于上述状态中的一种gama状态只有持久化消息才会有的状态。

在运行时，RabbitMQ会根据消息传递的速度定期计算一个当前内存中能够保存的最大消息数量（target_ram_count），如果alpha状态的消息数量大于此值，则会引起消息的状态转换，多余的消息可能会转换到beta、gama或者delta状态。区分这4种状态的主要作用是满足不同的内存和CPU需求。

对于普通没有设置优先级和镜像的队列来说，backing_queue的默认实现是rabbit_variable_queue，其内部通过5个子队列Q1、Q2、delta、Q3、Q4来体现消息的各个状态。
在这里插入图片描述
消费者获取消息也会引起消息的状态转换, 当消费者获取消息时

首先会从Q4中获取消息，如果获取成功则返回。
如果Q4为空，则尝试从Q3中获取消息，系统首先会判断Q3是否为空，如果为空则返回队列为空，即此时队列中无消息。
如果Q3不为空，则取出Q3中的消息；进而再判断此时Q3和Delta中的长度，如果都为空，则可以认为 Q2、Delta、 Q3、Q4 全部为空，此时将Q1中的消息直接转移至Q4，下次直接从Q4 中获取消息。
如果Q3为空，Delta不为空，则将Delta的消息转移至Q3中，下次可以直接从Q3中获取消息。在将消息从Delta转移到Q3的过程中，是按照索引分段读取的，首先读取某一段，然后判断读取的消息的个数与Delta中消息的个数是否相等，如果相等，则可以判定此时Delta中己无消息，则直接将Q2和刚读取到的消息一并放入到Q3中，如果不相等，仅将此次读取到的消息转移到Q3。

其实这一番论述也解释了另一个问题：为什么Q3和Delta都为空时，则可以认为 Q2、Delta、Q3、Q4全部为空？
通常在负载正常时，如果消费速度大于生产速度，对于不需要保证可靠不丢失的消息来说，极有可能只会处于alpha状态。
对于持久化消息，它一定会进入gamma状态，在开启publisher confirm机制时，只有到了gamma 状态时才会确认该消息己被接收，若消息消费速度足够快、内存也充足，这些消息也不会继续走到下一个状态。

为什么消息的堆积导致性能下降？
在系统负载较高时，消息若不能很快被消费掉，这些消息就会进入到很深的队列中去，这样会增加处理每个消息的平均开销。因为要花更多的时间和资源处理“堆积”的消息，如此用来处理新流入的消息的能力就会降低，使得后流入的消息又被积压到很深的队列中，继续增大处理每个消息的平均开销，继而情况变得越来越恶化，使得系统的处理能力大大降低。应对这一问题一般有3种措施：

增加prefetch_count的值，即一次发送多条消息给消费者，加快消息被消费的速度。
采用multiple ack，降低处理 ack 带来的开销
流量控制

RabbitMQ安装和配置

搭建环境

虚拟机软件：VMWare 15.1.0
操作系统：CentOS Linux release 7.7.1908
Erlang：erlang-23.0.2-1.el7.x86_64
RabbitMQ：rabbitmq-server-3.8.4-1.el7.noarch

RabbitMQ的安装需要首先安装Erlang，因为它是基于Erlang的VM运行的。RabbitMQ需要的依赖：socat和logrotate，logrotate操作系统中已经存在了，只需要安装socat就可以了。RabbitMQ与Erlang的兼容关系详见：https://www.rabbitmq.com/which-erlang.html

1、安装依赖：

yum install socat -y

2、安装Erlang：

# erlang-23.0.2-1.el7.x86_64.rpm下载地址： https://github.com/rabbitmq/erlang-rpm/releases/download/v23.0.2/erlang-23.0.2-1.el7.x86_64.rpm
rpm -ivh erlang-23.0.2-1.el7.x86_64.rpm

3、安装RabbitMQ

# rabbitmq-server-3.8.4-1.el7.noarch.rpm下载地址：https://github-releases.githubusercontent.com/924551/4d168f00-af2b-11ea-8054-f6727855202a?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210426%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210426T075238Z&X-Amz-Expires=300&X-Amz-Signature=7f5673c0965cd8c43d92defddd8811c3dd3d569c94915e44dfbd4ec4b09cab8d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=924551&response-content-disposition=attachment%3B%20filename%3Drabbitmq-server-3.8.5-1.el7.noarch.rpm&response-content-type=application%2Foctet-stream
rpm -ivh rabbitmq-server-3.8.4-1.el7.noarch.rpm

在这里插入图片描述

RabbitMQ常用操作命令

# 前台启动Erlang VM和RabbitMQ
rabbitmq-server
# 后台启动
rabbitmq-server -detached
# 停止RabbitMQ和Erlang VM
rabbitmqctl stop
# 查看所有队列
rabbitmqctl list_queues
# 查看所有虚拟主机
rabbitmqctl list_vhosts
# 在Erlang VM运行的情况下启动RabbitMQ应用
rabbitmqctl start_app
rabbitmqctl stop_app
# 查看节点状态
rabbitmqctl status
# 查看所有可用的插件
rabbitmq-plugins list
# 启用插件
rabbitmq-plugins enable <plugin-name>
# 停用插件
rabbitmq-plugins disable <plugin-name>
# 添加用户
rabbitmqctl add_user username password
# 列出所有用户：
rabbitmqctl list_users
# 删除用户：
rabbitmqctl delete_user username
# 清除用户权限：
rabbitmqctl clear_permissions -p vhostpath username
# 列出用户权限：
rabbitmqctl list_user_permissions username
# 修改密码：
rabbitmqctl change_password username newpassword
# 设置用户权限：
rabbitmqctl set_permissions -p vhostpath username ".*" ".*" ".*"
# 创建虚拟主机:
rabbitmqctl add_vhost vhostpath
# 列出所以虚拟主机:
rabbitmqctl list_vhosts
# 列出虚拟主机上的所有权限:
rabbitmqctl list_permissions -p vhostpath
# 删除虚拟主机:
rabbitmqctl delete_vhost vhost vhostpath
# 移除所有数据，要在 rabbitmqctl stop_app 之后使用:
rabbitmqctl reset

RabbitMQ工作流程详解

生产者发送消息的流程

生产者连接RabbitMQ，建立TCP连接( Connection)，开启信道（Channel）
生产者声明一个Exchange（交换器），并设置相关属性，比如交换器类型、是否持久化等
生产者声明一个队列井设置相关属性，比如是否排他、是否持久化、是否自动删除等
生产者通过 bindingKey （绑定Key）将交换器和队列绑定（ binding ）起来
生产者发送消息至RabbitMQ Broker，其中包含 routingKey （路由键）、交换器等信息
相应的交换器根据接收到的 routingKey 查找相匹配的队列。
如果找到，则将从生产者发送过来的消息存入相应的队列中。
如果没有找到，则根据生产者配置的属性选择丢弃还是回退给生产者
关闭信道。
关闭连接。

消费者接收消息的过程

消费者连接到RabbitMQ Broker ，建立一个连接(Connection ) ，开启一个信道(Channel) 。
消费者向RabbitMQ Broker 请求消费相应队列中的消息，可能会设置相应的回调函数，以及做一些准备工作
等待RabbitMQ Broker 回应并投递相应队列中的消息，消费者接收消息。
消费者确认( ack) 接收到的消息。
RabbitMQ 从队列中删除相应己经被确认的消息。
关闭信道。
关闭连接。

RabbitMQ工作模式详解

Spring和SpringBOOT整合RabbitMQ

liuwangleoooO

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分布式消息服务中间价——《RabbitMQ》

文章目录介绍主要目的主要内容消息中间价概述分布式架构通信分布式架构通信原理分布式同步通信的问题分布式异步通信模式消息中间件简介概述自定义消息中间件主流消息中间件及选型选取原则RabbitMQRocketMQKafka消息中间件应用场景JMS规范和AMQP协议介绍主要目的了解消息中间件背景知识、使用场景、发展掌握RabbitMQ、RocketMQ、Kafka这三款主流的消息中间件的架构，模型，和使用(开发、安装、集群部署、运维、监控)掌握消息的可靠性、幂等性、顺序消息、延迟消息、事务消息等进阶的知
复制链接

扫一扫