rabbitMQ基本概念

rabbitmq

rabbitmq基本概念

文章目录

一、MQ概述

MQ全称 Message Queue（消息队列），是在消息的传输过程中保存消息的容器。多用于分布式系统之间进行通信。

总结

MQ，消息队列，存储消息的中间件
分布式系统通信两种方式：直接远程调用 和 借助第三方完成间接通信
发送方称为生产者，接收方称为消费者

二、MQ 的优势和劣势

优势：

应用解耦：模块之间的调用十分复杂，为了降低模块与模块之间调用依赖，使用MQ将两系统分开,不直接调用系统接口,减轻两系统依赖关系
异步提速 ：不使用mq的情况下，代码必然耦合在一起，用户发起请求后，依次要通过RPC远程调用多个系统，然后同步等到他们的响应才能返回给用户是否成功的结果。假设每个系统耗时200ms，如果有3个系统，那么就得花费600ms。

但是其实有时候我们发现，有些场景是核心业务，可能压力本来就大，用户也急切想要知道核心业务的结果，但是类似短信验证码，邮件等通知，并不是关键的。那么我们怎么将这些不那么核心的业务设计成不影响核心业务的效率？所以可以设计成异步处理。我们可以当用户请求核心业务后，当其成功后，只需要将对应的请求消息发给MQ，然后立即将结果返回通知客户。这样一来，核心系统只需要告诉你MQ，结果成功了，其他模块收到消息后，该发短信的发短信，发邮件的发邮件。因为本来MQ的性能就很好，所以这个效率一下就提升了。这样子用户感知的请求响应时间也是大大的减少了，提高了用户的体验感的满意度。

削峰填谷：对于突然到来的大量请求，类似高并发的场景，我们可以配置流控规则，以稳定的速度逐步处理这些请求，起到“削峰填谷”的效果，从而避免流量突刺造成系统负载过高。

例如，某应用的处理能力是每秒 1000 个请求。在某一秒，突然到来了10000个请求，而接下来时间内请求都没有。在这种情况下我们可以需要把高并发的请求均摊到一段时间内，将mq中的请求可以分10次给系统，也就是系统每秒从mq中拉取1000个请求，让系统负载保持在请求处理水位之内，同时尽可能地处理更多请求，从而起到“削峰填谷”的效果。

高峰期产生的数据势必会被积压在 MQ 中，高峰就被“削”掉了，但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在1000，直到消费完积压的消息，这就叫做“填谷”。

总结

⚫ 应用解耦：提高系统容错性和可维护性
⚫ 异步提速：提升用户体验和系统吞吐量
⚫ 削峰填谷：提高系统稳定性

劣势：

⚫系统可用性降低
系统引入的外部依赖越多，系统稳定性越差。一旦 MQ 宕机，就会对业务造成影响。如何保证MQ的高可用？
⚫ 系统复杂度提高
MQ 的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过 MQ 进行异步调用。如何保证消息没有被重复消费？怎么处理消息丢失情况？那么保证消息传递的顺序性？
⚫ 一致性问题
A 系统处理完业务，通过 MQ 给B、 C、 D三个系统发消息数据，如果 B 系统、 C 系统处理成功， D 系统处理失败。如何保证消息数据处理的一致性？

总结：

既然 MQ 有优势也有劣势，那么使用 MQ 需要满足什么条件呢？
①生产者不需要从消费者处获得反馈。引入消息队列之前的直接调用，其接口的返回值应该为空，这才让明明下层的动作还没做，上层却当成动作做完了继续往后走，即所谓异步成为了可能。
② 容许短暂的不一致性。
③ 确实是用了有效果。即解耦、提速、削峰这些方面的收益，超过加入MQ，管理MQ的成本。

三、常见的 MQ 产品

目前业界有很多的 MQ 产品，例如 RabbitMQ、 RocketMQ、 ActiveMQ、 Kafka、ZeroMQ、 MetaMq等，也有直接使用 Redis 充当消息队列的案例，而这些消息队列产品，各有侧重，在实际选型时，需要结合自身需求及 MQ 产品特征，综合考虑。

四、RabbitMQ 简介

AMQP， 即 Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。 2006年， AMQP 规范发布。 类比HTTP。

2007年， Rabbit 技术公司基于 AMQP 标准开发的 RabbitMQ 1.0 发布。 RabbitMQ 采用 Erlang 语言开发。
Erlang 语言由 Ericson 设计，专门为开发高并发和分布式系统的一种语言，在电信领域使用广泛。

相关概念
⚫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 提供了 6 种工作模式： 简单模式、 work queues、 Publish/Subscribe 发布与订阅模式、 Routing 路由模式、 Topics 主题模式、 RPC 远程调用模式

五、JMS

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

总结：

1. RabbitMQ 是基于 AMQP 协议使用 Erlang 语言开发的一款消息队列产品。
2. RabbitMQ提供了6种工作模式。
3. AMQP 是协议，类比HTTP。
4. JMS 是 API 规范接口，类比 JDBC。