RabbitMQ —— 明白及应用场景
一、MQ相干的概念RabbitMQ 是一种分布式消息中间件，消息中间件也称消息队列MQ，那么什么是MQ呢？请继承阅读下文。
1.1、MQ的基本概念
什么是MQ
MQ(message queue)，从字面意思上看就个 FIFO 先入先出的队列，只不外队列中存放的内容是 message 而已，它是一种具有吸收数据、存储数据、发送数据等功能的技术服务。
https://img-blog.csdnimg.cn/direct/c129484f90d94c1284a5b60a17ab1e6d.png
在互联网架构中，MQ 是一种非经常见的上下游“逻辑解耦+物明白耦”的消息通讯服务，用于上下游转达消息。使用了 MQ 之后，消息发奉上游只需要依靠 MQ，不用依靠其他服务
为啥要用MQ
常见的MQ消息中间件有许多，例如ActiveMQ、RabbitMQ、Kafka、RocketMQ等等。那么为什么我们要使用它呢？由于它能很好的帮我解决一些复杂特殊的场景：
高并发的流量削峰
举个例子，假设某订单系统每秒最多能处理一万次订单，也就是最多承受的10000qps，这个处理能力应付正常时段的下单时绰绰有余，正常时段我们下单一秒后就能返回结果。但是在高峰期，假如有两万次下单操纵系统是处理不了的，只能限制定单高出一万后不答应用户下单。使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户大概在下单十几秒后才能收到下单成功的操纵，但是比不能下单的体验要好。
https://img-blog.csdnimg.cn/direct/f2cbfcde13a045c390a35c52813847ef.png
应用解耦
以电商应用为例，应用中有订单系统、库存系统、物流系统、付出系统。用户创建订单后，假如耦合调用库存系统、物流系统、付出系统，任何一个子系统出了故障，都会造成下单操纵异常。当变化成基于消息队列的方式后，系统间调用的问题会淘汰许多，比如物流系统由于发生故障，需要几分钟来修复。在这几分钟的时间里，物流系统要处理的内存被缓存在消息队列中，用户的下单操纵可以正常完成。当物流系统恢复后，继承处理订单信息即可，中单用户感受不到物流系统的故障，提拔系统的可用性。
https://img-blog.csdnimg.cn/direct/05f8d310f2b244b48fdd139857450277.png
异步处理
有些服务间调用是异步的，例如 A 调用 B，B 需要泯灭很长时间执行，但是 A 需要知道 B 什么时间可以执行完，以前一样寻常有两种方式，A 过一段时间去调用 B 的查询 api 查询。大概 A 提供一个 callback api， B 执行完之后调用 api 关照 A 服务。这两种方式都不是很优雅，使用消息队列，可以很方便解决这个问题，A 调用 B 服务后，只需要监听 B 处理完成的消息，当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api，也不用提供 callback api。同样B 服务也不用做这些操纵。A 服务还能实时的得到异步处理成功的消息。
https://img-blog.csdnimg.cn/direct/e38cb204973e46f39b7fb2c9ed0c64e0.png
分布式事务
以订单服务为例，传统的方式为单体应用，付出、修改订单状态、创建物流订单三个步骤集成在一个服务中，因此这三个步骤可以放在一个jdbc事务中，要么全成功，要么全失败。而在微服务的情况下，会将三个步骤拆分成三个服务，例如：付出服务，订单服务，物流服务。三者各司其职，相互之间进行服务间调用，但这会带来分布式事务的问题，由于三个步骤操纵的不是同一个数据库，导致无法使用jdbc事务管理以达到同等性。而 MQ 能够很好的帮我们解决分布式事务的问题，有一个比力容易明白的方案，就是二次提交。基于MQ的特点，MQ作为二次提交的中间节点，负责存储请求数据，在失败的情况可以进行多次尝试，大概基于MQ中的队列数据进行回滚操纵，是一个既能包管性能，又能包管业务同等性的方案，如下图所示：
https://img-blog.csdnimg.cn/direct/3b3fe1f76bb34f429c3e48f3a3fcc2bb.png
数据分发
MQ 具有发布订阅机制，不仅仅是简单的上游和下游一对一的关系，还有支持一对多大概广播的模式，并且都可以根据规则选择分发的对象。这样一份上游数据，众多下游系统中，可以根据规则选择是否吸收这些数据，能达到很高的拓展性。
https://img-blog.csdnimg.cn/direct/9e0cd77d75ba45e7b11555c0649d152d.png
常用的MQ
ActiveMQ
优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性较低的概率丢失数据
缺点：官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用。
Kafka
大数据的杀手锏，谈到大数据范畴内的消息传输，则绕不开 Kafka，这款为大数据而生的消息中间件，以其百万级 TPS 的吞吐量名声大噪，敏捷成为大数据范畴的宠儿，在数据采集、传输、存储的过程中发挥着举足轻重的作用。现在已经被 LinkedIn，Uber, Twitter, Netflix 等大公司所接纳。
优点：性能杰出，吞吐量高，单机写入 TPS 约在百万条/秒，时效性 ms 级，可用性非常高；其次 kafka 是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据导致服务不可用，消费者采用 Pull 方式获取消息，消息有序，通过控制能够包管全部消息被消费且仅被消费一次。此外 kafka 有优秀的第三方 Kafka Web 管理界面 Kafka-Manager，在日志范畴比力成熟，被多家公司和多个开源项目使用；最后 kafka 在功能支持方便面它功能较为简单，重要支持简单的 MQ 功能，在大数据范畴的实时盘算以及日志采集被大规模使用。
缺点：Kafka 单机高出 64 个队列/分区，Load 会发生显着的飙高征象，队列越多，load 越高，发送消息相应时间变长，使用短轮询方式，实时性取决于轮询间隔时间，消费失败不支持重试；支持消息次序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢；
应用场景：Kafka 重要特点是基于Pull 的模式来处理消息消费，寻求高吞吐量，一开始的目的就是用于日志网络和传输，得当产生大量数据的互联网服务的数据网络业务。大型公司发起可以选用，假如有日志采集功能，肯定是首选 kafka 了。
RocketMQ
RocketMQ 出自阿里巴巴的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。被阿里巴巴广泛应用在订单，交易，充值，流盘算，消息推送，日志流式处理，binglog 分发等场景。
优点：单机吞吐量十万级，可用性非常高，采用分布式架构，消息可以做到 0 丢失，MQ 功能较为美满，扩展性好，支持 10 亿级别的消息堆积，不会由于堆积导致性能下降，采用 java 语言实现。
缺点：支持的客户端语言不多，现在是 java 及 c++，此中 c++不成熟；社区生动度一样寻常,没有在MQ焦点中去实现 JMS 等接口，有些系统要迁徙需要修改大量代码。
应用场景：天生为金融互联网范畴而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端大概无法实时处理的情况。RoketMQ 在稳固性上大概更值得信任，这些业务场景在阿里双 11 已经经历了多次检验，假如你的业务有上述并发场景，发起可以选择 RocketMQ。
RabbitMQ
2007 年发布，是一个在AMQP(高级消息队列协议)底子上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
优点：由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比力完备、健壮、稳固、易用、跨平台、支持多种语言如Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持 AJAX 文档齐备；开源提供的管理界面非常棒，用起来很好用，社区生动度高；更新频率相称高。
缺点：贸易版需要收费，学习成本较高。
应用场景：结合 erlang 语言自己的并发优势，性能好时效性微秒级，社区生动度也比力高，管理界面用起来非常方便，假如你的数据量没有那么大，中小型公司优先选择功能比力完备的 RabbitMQ。
1.2、消息队列协议
什么是协议
协议：是在TCP/IP协议底子之上构建的种约定成的规范和机制，目的是让客户端进行沟通和通讯。并且这种协议下规范必须具有长期性，高可用，高可靠的性能。
为什么不直接采用TCP/IP协议去转达消息？由于TCP/IP协议太过于简单，并不能承载消息的内容和载体，因此在此之上增加一些内容，给消息的转达分发高可用提供底子。
https://img-blog.csdnimg.cn/direct/1a6024c67cbe48219c9532c26a183871.png
我们知道消息中间件负责数据的转达，存储，和分发消费三个部分，数据的存储和分发的过程中肯定要遵循某种约定成俗的规范，是采用底层的TCP/IP，UDP协议照旧在这底子上自己构建等，而这些约定成俗的规范就称之为：协议。
所谓协议是指：
1.盘算机底层操纵系统和应用程序通讯时共同遵守的组约定，只有遵循共同的约定和规范，系统和底层操纵系统之间才能相互交换。
2.和一样寻常的网络应用程序的差别，它重要负责数据的接受和转达，所以性能比力的高。
3.协议对数据格式和盘算机之间交换数据都必须严格遵守规范。
网络协议的三要素
语法：语法是用户数据与控制信息的结构与格式，以及数据出现的次序。
语义：语义是解控制信息每个部分的意义。它规定了需要发出何种控制信息以及完成的动作与做出什么样的相应。
时序：时序是对变乱发生次序的具体说明。
# 类比http请求协议
1. 语法：htp规定了请求报文和相应报文的格式
2. 语义：客户端主动发起请求称之为请求。（这是一种定义，同时你发起的是post/get请求）
3. 时序：一个请求对应个相应。（定先有请求在有相应，这个是时序）
而消息中间件采用的并不是http协议，而常见的消息中间件协议有：OpenWire、AMQP、MQTT、Kafka、OpenMessage协议
面试题：为什么消息中间件不直接使用http协议呢？
1.由于http请求报文头和相应报文头是比力复杂的，包含了cookie、数据的加密解密、状态码、晌应码等附加的功能，但是对于个消息而言，我们并不需要这么复杂，也没有这个必要性，它实在就是负责数据转达，存储，分发就够，要寻求的是高性能。尽量简洁，快速。
2.大部分情况下http大部分都是短链接，在实际的交互过程中，一个请求到相应很有大概会制止，制止以后就不会就行长期化，就会造成请求的丢失。这样就倒霉于消息中间件的业务场景，由于消息中间件大概是一个长期的获取消息的过程，出现问题和故障要对数据或消息就行长期化等，目的是为了包管消息和数据的高可靠和妥当的运行。
常用消息中间件协议
1.AMQP协议（Advanced Message Queuing Protocol—高级消息队列协议）
它由摩根大通集团团结其他公司共同设计。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可转达消息，并不受客户端/中间件差别产品，差别的开发语言等条件的限制。
特性：分布式事务支、消息的长期化支持、高性能和高可靠的消息处理优势
AMQP典型的实现者是RabbitMQ、ACTIVEMQ等，此中RabbitMQ由Erlang开发
https://img-blog.csdnimg.cn/direct/89700ce5f41b4b01bf379d7c9b3dec11.png
2.MQTT协议（Message Queueing Telemetry Transport—消息队列遥测传输协议）
它是一种基于发布/订阅（publish/subscribe）模式的"轻量级"通讯协议，该协议构建于TCP/IP协议上，由IBM在1999年发布。
特点：轻量、结构简单、传输快、不支持事务、没有长期化设计
应用场景：实用于盘算能力有限、低带宽、网络不稳固的场景
支持者：RabbitMQ、ACTIVEMQ（默认情况下关闭，需要打开）
https://img-blog.csdnimg.cn/direct/ff788a8383244f9cb8fab1a29a3fed3d.png
3.OpenMessage协议
是近几年由阿里、雅虎和滴滴出行、 Stremalio等公司共同到场创立的分布式消息中间件、流处理等范畴的应用开发标准。
特点：结构简单、解析速度快、支持事务和长期化设计
4.Kafka协议
基于TCP/IP的二进制协议。消息内部是通过长度来分割，由一些基本数据类型组成。
特点：结构简单、解析速度快、无事务支持、有长期化设计
1.3、消息队列长期化
长期化简单来说就是将数据存入磁盘，而不是存在内存中随服务器重启断开而消失，使数据能够永久保存。
https://img-blog.csdnimg.cn/direct/704db5b9d70c479e99fd99ea1113d409.png
常见的长期化方式和对比：
ActiveMQ RabbitMQ Kafka RocketMQ文件存储 支持 支持 支持 支持数据库 支持 / / / 1.4、消息的分发策略
https://img-blog.csdnimg.cn/direct/9e811c81cac945b5840009dced041ac8.png
MQ消息队列有如下几个角色：
1.Producer：消息生产者。负责产生和发送消息到 Broker
2.Broker：消息处理中央。负责消息存储、确认、重试等，一样寻常此中会包含多个 queue
3.Consumer：消息消费者。负责从 Broker 中获取消息，并进行相应处理
生产者产生消息后，MQ进行存储，消费者怎样得到消息呢？
一样寻常的获取方式无外乎外推（push）大概（pull）两种方式，典型的git就有推拉机制，我们发送的http请求就是一种典型的拉取数据库数据返回的过程。而消息队列MQ是一种推送过程，而这些推机制会实用到许多的业务场景，也有许多对应的推机制策略
场景分析一
https://img-blog.csdnimg.cn/direct/8075bda31cc8473daa7baf0cb3ddd0dc.png
比如我在APP上下了一个订单，我们的系统和服务许多，我们怎样得知这个消息被谁人系统大概那些服务大概系统进行消费，此时就需要一个消费策略，或称为消费的方法论。
场景分析二
https://img-blog.csdnimg.cn/direct/46ec4b1f33774d9dbede3a492234e3e0.png 在发送消息的过程中大概会出现异常，大概网络的抖动，故障等等由于造成消息的无法消费，比如用户在下订单，消费MQ接受，订单系统出现故障，导致用户付出失败，那么这个时间就需要消息中间件就必须支持消息重试机制策略。也就是支持：出现问题和故障的情况下，消息不丢失还可以进行重发
页:
[1]