消息中间件概述

傷城~ 2024-04-21 08:06 54阅读 0赞

> #### ✨ 消息中间件概述 ####
> 
>  *  学习消息队列的原因
>  *  消息中间件概述
>  *  消息队列应用场景
>  *   *  消息中间件主要作用
>      *  应用解耦
>      *  异步处理
>      *  流量削峰(削峰填谷)
>      *  QPS,PV,UV,PR概念
>  *  AMQP和JMS
>  *  消息队列产品
>  *  RabbitMQ核心概念 架构原理
> 
>   
> **?个人主页:[不断前进的皮卡丘][Link 1]**  
> **?博客描述:梦想也许遥不可及，但重要的是追梦的过程，用博客记录自己的成长，记录自己一步一步向上攀登的印记**  
> **?个人专栏:[消息中间件专栏][Link 2]**

## 学习消息队列的原因 ##

> ?**在电子商务应用中，我们经常需要对庞大的数据进行监控，MQ的使用与日俱增，特别是RabbitMQ在分布式系统中存储转发消息，可以保证数据不丢失，也可以保证高可用性，即集群的时候部分机器宕机可以继续执行。在大型电子商务类网址，比如京东、淘宝等网址有着深入的应用。  
> ?队列可以消除高并发访问高峰，加快网站的响应速度。  
> ?在不适用消息队列的情况，用户的请求直接写入数据库，在高并发的情况会对数据库造成巨大的压力，同时也会导致系统响应延迟加剧。**

## 消息中间件概述 ##

*  MQ(Message Queue),消息队列(MQ)是一种应用程序对应用程序的通信方法
 *  消息队列是一种先进先出的数据结构
 *  **消息传递:指的是程序直接通过消息发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是拥有远程调用的技术**
 *  ![在这里插入图片描述][9ea8283f99c94e01b43cebfd2ef020e1.png]
 *  **引入消息队列的原因:**
    
     *  不同进程之间传递消息的时候，两个进程之间耦合度过高，一个进程的改变就会引发另外一个进程的改变。为了让它们不会互相干扰，我们需要在两个进程之间抽离出一个模块，两个进程之间传递的消息通过消息队列来传递。单独修改某一个进程不会影响另外一个。
     *  某个进程一下子接受的消息太多了，无法马上处理好，就需要对接受的消息进行排队，所以有了消息队列
     *  我们可以把一些不需要即时返回而且又耗费时间的操作提取出来，进行异步处理，可以节省服务器的请求响应时间，从而提高了系统的吞吐量。

## 消息队列应用场景 ##

### 消息中间件主要作用 ###

*  异步处理
 *  解耦服务
 *  流量削峰

### 应用解耦 ###

*  传统的模式会出现耦合的情况
 *  通过中间件模式，可以进行解耦的作用
 *  ![在这里插入图片描述][a4f8836fdea1492e9af5c0d46cb2015d.png]

### 异步处理 ###

*  场景说明:用户注册以后，需要发送注册邮件和注册短信，传统的方式有两种:串行方式和并行的方式。
 *  串行方式:
    
     *  把注册信息写到数据库中后，发送注册邮件，再发送注册短信，这三个认为全部完成以后才返回给客户端。但是有个地方要注意，邮件和短信并不是必须的，它只是一个通知，这种方式会导致客户端在等一些没有必要等待的东西。
     *  ![在这里插入图片描述][601c1d24decc47adb6a148aa385906c9.png]
 *  并行方式:
    
     *  把注册信息写到数据库中后，发送邮件的同时，发送短信，这三个认为任务完成后返回给客户端，并行的方式可以提高处理的事件时间
     *  ![在这里插入图片描述][dc8699ba3a6e4a07ae4b60d5020553fe.png]
     *  **虽然并行的方式可以提高效率，但是因为短信和邮件对于我们正常使用网站来说是没有影响的，所以客户端并不需要等到它发送完成以后才显示注册成功，应该是写入数据库中后就可以返回。**
 *  消息队列:
    
     *  引入消息队列以后，把发送短信，邮件等不是必须的业务逻辑进行异步处理
     *  ![在这里插入图片描述][59854a55b2cb4b749df0892640d82c54.png]
     *  引入消息队列以后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计)

### 流量削峰(削峰填谷) ###

*  流量削峰一般在秒杀活动中应该广泛，因为秒杀活动一般会因为流量过大，导致应用挂掉，为了解决这个问题，我们一般需要加入消息队列
 *  传统模式:在下单的时候就会往数据库中添加数据，但是如果并发量过高的话，就可能导致宕机。
 *  如果说消息被MQ保存起来，然后系统可以按照自己的消费能力来消费，比如每秒1000个数据，这样慢慢写入到数据库中，就不会导致数据库卡死了
 *  系统慢慢的按照数据库能够处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

### QPS,PV,UV,PR概念 ###

*  QPS
    
     *  QPS:每秒查询率,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
     *  因特网经常用每秒查询率来衡量域名系统服务器的机器的性能
     *  QPS=并发量/平均响应时间
 *  ![在这里插入图片描述][9d77d07a17e94566853adea3017c9ec7.png]
 *  PV:Page View，网页浏览量。网页被读者调用浏览的次数。网页每次打开或刷新一次页面，记录一次。用户对同一页面的多次访问，访问量累计。
 *  UV （Unique Visitor，独立访客访问数）  
    统计1天内访问某站点的用户数(以 cookie 为依据)，一台电脑终端为一个访客。
 *  PR：PageRank,网页的级别技术，用来标识网页的等级/重要性。级别从1到10.PR越高，说明这个网页越受欢迎

## AMQP和JMS ##

*  MQ是消息通信的模型，实现MQ大致有两种主流方式:AMQP、JMS
 *  **AMQP是一种高级消息队列协议(Advanced Message Queuing Protocol),更准确的说是一种链接协议。这是和JMS的 本质区别，AMQP不和API层进行限定，而是直接定义网络交换的数据格式**
 *  **JMS即Java消息服务(JavaMessage Service)应用程序接口，是一个Java平台关于面向消息中间件(MOM)的API，用在两个应用程序之间，或者分布式系统中发送消息，进行异步通信。**
 *  **二者的区别**
    
     *  JMS是定义了统一的接口，来对消息进行操作统一；AMQP是通过规定协议来统一数据交互的格式
     *  JMS限定了必须使用Java语言；AMQP只是协议，不规定实现方式，是跨语言的
     *  JMS规定了两种消息模式；二AMQP的消息模式更加丰富。

## 消息队列产品 ##

![在这里插入图片描述][ca9ba1c00f124e69818339bdb91f24d2.png]  
[常用6种消息队列介绍和对比][6]

## RabbitMQ核心概念 架构原理 ##

![在这里插入图片描述][0c220d82256142e9a3afb27ecd459e22.png]

*  **Broker ：接收和分发消息的应用， RabbitMQ Server 就是 Message Broker**
 *  **Virtual host： 出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似 于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出 多个 vhost ，每个用户在自己的 vhost 创建 exchange ／ queue 等**
 *  **Connection： publisher ／ consumer 和 broker 之间的 TCP 连接**
 *  **Channel ：如果每一次访问 RabbitMQ 都建立一个 Connection ，在消息量大的时候建立 TCP连接 的开销将是巨大的，效率也较低。 Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个 thread 创建单独的 channel 进行通讯， AMQP method 包含了 channel id 帮助客 户端和 message broker 识别 channel ，所以 channel 之间是完全隔离的。 Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP 连接 的开销**
 *  **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 的分发依据**  
    ![在这里插入图片描述][8206a7a62df648509bc544b4db5d272f.png]

[Link 1]: https://blog.csdn.net/qq_52797170?spm=1010.2135.3001.5343
[Link 2]: https://blog.csdn.net/qq_52797170/category_12026287.html?spm=1001.2014.3001.5482
[9ea8283f99c94e01b43cebfd2ef020e1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/c815aaeed16945f5bee44c688850fc2d.png
[a4f8836fdea1492e9af5c0d46cb2015d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/dc03b3a699d147a190c085ccf28ece7a.png
[601c1d24decc47adb6a148aa385906c9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/a9c70aff4c7b41a097e5b21559224387.png
[dc8699ba3a6e4a07ae4b60d5020553fe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/350208cd905a4f7e991fb3f04f29efe9.png
[59854a55b2cb4b749df0892640d82c54.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/873dd60aa14e4a18aa61d4819ab99553.png
[9d77d07a17e94566853adea3017c9ec7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/bfd6d873d4924bfcb50d81123fd73386.png
[ca9ba1c00f124e69818339bdb91f24d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/a2011f76de4f4c5a8508169f3d3df859.png
[6]: https://blog.csdn.net/u013521220/article/details/104352365?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166400017316782414950744%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=166400017316782414950744&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-2-104352365-null-null.142%5Ev50%5Econtrol,201%5Ev3%5Eadd_ask&utm_term=%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97%E4%BA%A7%E5%93%81&spm=1018.2226.3001.4187
[0c220d82256142e9a3afb27ecd459e22.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/f2c0e6007fff4b878287c41f47e06560.png
[8206a7a62df648509bc544b4db5d272f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/21/488f74b08c354d8d8ff863872439b5da.png