MQ——RabbitMQ工作模式_rabbitmq有副本吗

作者：凡人多烦事01 | 2024-06-06 11:44:47

踩

rabbitmq有副本吗

摘要

本文主要是主要是的对RabbitMQ的源码进行详细的阅读和理解，同时也是对MQ中源码进行深入的学习和分析，同时这个也是本系列博文的开始，后期将继续推出对MQ源码的理解和学习的博文。

什么是RabbitMQ

AMQP，即 Advanced Message Queuing Protocol(高级消息队列协议)，是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。2006年，AMQP规范发布。类比HTTP。RabbitMQ是一款使用Erlang语言开发的，实现AMQP(高级消息队列协议)的开源消息中间件。其中MQ的主要的作用是:1 削峰填谷:2 系统解耦:3 异步处理:4 数据的最终一致性。

RabbitMQ的架构

RabbitMQ中的相关概念:

Broker:接收和分发消息的应用，RabbitMQ Server就是 Message Broker。
Virtual host:出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ server 提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange / queue等。
Connection: publisher / consumer和broker之间的TCP连接。
Channel:如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP ，Connection的开销将是巨大的，效率也较低。Channel是在connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别 channel，所以 channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
Exchange: message到达 broker的第一站，根据分发规则，匹配查询表中的 routing key，分发消息到queue 中去。常用的类型有: direct (point-to-point), topic (publish-subscribe) and fanout(multicast)
Queue:消息最终被送到这里等待consumer取走
Binding: exchange和queue之间的虚拟连接，binding 中可以包含 routing key。Binding 信息被保存到exchange 中的查询表中，用于message的分发依据

RabbitMQ工作模式

RabbitMQ提供了6种工作模式:简单模式、 work queues、Publish/Subscribe发布与订阅模式、Routing路由模式、Topics主题模式、RPC远程调用模式（远程调用，不太算MQ;暂不作介绍)。
官网对应模式介绍: RabbitMQ Tutorials — RabbitMQ

RabbitMQ的JMS

JMS即Java消息服务(JavaMessage Service)应用程序接口，是一个Java平台中关于面向消息中间件的API。
JMS是 JavaEE规范中的一种，类比JDBC。
很多消息中间件都实现了JMS规范，例如: ActiveMQ。RabbitMQ官方没有提供JMS的实现包，但是开源社区有。

RabbitMQ的作用

系统解耦

如图所示。假设有系统B、C、D都需要系统A的数据，于是系统A调用三个方法发送数据到B、C、D。这时，系统D不需要了，那就需要在系统A把相关的代码删掉。假设这时有个新的系统E需要数据，这时系统A又要增加调用系统E的代码。为了降低这种强耦合，就可以使用MQ，系统A只需要把数据发送到MQ，其他系统如果需要数据，则从MQ中获取即可。

数据异步处理

如图所示。一个客户端请求发送进来，系统A会调用系统B、C、D三个系统，同步请求的话，响应时间就是系统A、B、C、D的总和，也就是800ms。如果使用MQ，系统A发送数据到MQ，然后就可以返回响应给客户端，不需要再等待系统B、C、D的响应，可以大大地提高性能。对于一些非必要的业务，比如发送短信，发送邮件等等，就可以采用MQ。

系统削峰

如图所示。这其实是MQ一个很重要的应用。假设系统A在某一段时间请求数暴增，有5000个请求发送过来，系统A这时就会发送5000条SQL进入MySQL进行执行，MySQL对于如此庞大的请求当然处理不过来，MySQL就会崩溃，导致系统瘫痪。如果使用MQ，系统A不再是直接发送SQL到数据库，而是把数据发送到MQ，MQ短时间积压数据是可以接受的，然后由消费者每次拉取2000条进行处理，防止在请求峰值时期大量的请求直接发送到MySQL导致系统崩溃。

RabbitMQ构建实战

学习安装推荐使用Docker拉一个RabbitMQ的镜像下来：实际的操作看：https://blog.csdn.net/weixin_41605937/article/details/120329102?spm=1001.2014.3001.5502

或者你自己在window上进行安装学习最后打开的页面是这样。

实操MQ的发送数据和消费数据

该网址提供了简单的MQ的操作。帮助你快速的学习和了解MQ的使用.

Docker——RabbitMQ与python的连接_庄小焱-CSDN博客

RabbitMQ集群的构建实践

Docker——RabbitMQ集群构建_庄小焱-CSDN博客

RabbitMQ对比其他kafka以及应用场景

	RabbitMQ	kafka
消费方式	RabbitMQ在吞吐量方面略有逊色，但支持更多的消息队列功能。Kafka采用拉取（Pull）方式消费消息，吞吐量相对更高，适用于海量数据收集与传递场景，例如日志采集和集中分析。
性能	消息中间件的性能主要衡量吞吐量，Kafka的吞吐量比RabbitMQ要高出1~2个数量级，RabbitMQ的单机QPS在万级别，Kafka的单机QPS能够达到百万级别。RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节，Kafka如果开启幂等、事务等功能，性能也会有所降低。
数据可靠性	Kafka与RabbitMQ都具备多副本机制，数据可靠性较高。RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication。
服务可用性	Kafka采用集群部署，分区与多副本的设计，使得单节点宕机对服务无影响，且支持消息容量的线性提升。RabbitMQ支持集群部署，集群节点数量有多种规格。RocketMQ是分布式架构，可用性高。
功能	Kafka与RabbitMQ都是比较主流的两款消息中间件，具备消息传递的基本功能，但在一些特殊的功能方面存在差异，RocketMQ在阿里集团内部有大量的应用在使用

RabbitMQ项目的源码以及说明


broker：存放RocketMQ的Broker相关的代码，这里的代码可以用来启动Broker进程；
 
client：存放RocketMQ的Producer、Consumer这些客户端的代码，生产消息、消费消息的代码都在里面；
 
common：存放公共代码；
 
dev：存放开发相关的一些信息；
 
distribution：存放用来部署RocketMQ的一些东西，比如bin目录 、conf目录等等；
 
example：存放RocketMQ的一些例子；
 
filter：存放RocketMQ的与过滤器相关的代码；
 
logappender和logging：存放RocketMQ的日志打印相关的东西；
 
namesvr：存放NameServer的源码；
 
openmessaging：这是开放消息标准，先忽略；
 
remoting：存放RocketMQ的远程网络通信模块的代码，基于netty实现；
 
srvutil：存放一些工具类；
 
store：存放Broker上存储相关的一些源码；
 
style、test、tools：存放checkstyle代码检查的东西，一些测试相关的类，还有就是tools里放的一些命令行监控工具类。