1. 初始 RabbitMQ 消息队列

1. 初始 RabbitMQ 消息队列

@
目录

• 1. 初始 RabbitMQ 消息队列
  
• 1. MQ 的相关概念
  
• 2. MQ 的分类
  
• 3. MQ 的选择
  
• 4. RabbitMQ
  
  
  
  • 4.1 RabbitMQ 的概念
    
  • 4.2 RabbitMQ 的四大核心概念
    
  • 4.3 RabbitMQ 六大核心部门
    
  • 4.4 RabbitMQ 的常见名词表明
    
  
  
• 5. 最后：
  

1. MQ 的相关概念

什么是 MQ
MQ(message queue)，从字面意思上看，本质是个队列，FIFO 先入先出，只不过队列中存放的内容是 message 而已，还是一种跨进程的通信机制，用于上鄙俚通报消息。在互联网架构中，MQ 是一种非经常 见的上鄙俚“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不 用依赖其他服务。
简单来说，消息中间件就是指生存数据的一个容器（服务器），可以用于两个体系之间的数据通报。
消息中间件一样平常有三个主要脚色：生产者、消费者、消息署理(消息队列、消息服务器)；

生产者发送消息到消息服务器，然后消费者从消息署理（消息队列）中获取数据并举行处理；
为什么要使用 MQ

• 流量消峰：
  

举个例子，如果订单体系最多能处理一万次订单，这个处理能力应付正常时段的下单时绰绰有余，正 常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操纵体系是处理不了的，只能限 制定单凌驾一万后不答应用户下单。使用消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分 散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单乐成的操纵，但是比不能下单的体 验要好。
高负载请求/使命的缓冲处理；

• 应用解耦：
  

以电商应用为例，应用中有订单体系、库存体系、物流体系、支付体系。用户创建订单后，如果耦合 调用库存体系、物流体系、支付体系，任何一个子体系出了故障，都会造成下单操纵非常。当变化成基于 消息队列的方式后，体系间调用的题目会镌汰许多，比如物流体系因为发生故障，需要几分钟来修复。在 这几分钟的时间里，物流体系要处理的内存被缓存在消息队列中，用户的下单操纵可以正常完成。当物流 体系规复后，继续处理订单信息即可，中单用户感受不到物流体系的故障，提拔体系的可用性。

多个体系之间，不需要直接交互，通过消息举行业务流转；

• 异步处理：
  

有些服务间调用是异步的，比方 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 服务还能及时的得到异步处理乐成的消息。

下订单：下订单--》加积分--》发红包--》发手机短信
下订单---向MQ 发消息--》积分体系，红包体系，手机短信体系吸取消息

同步是阻塞的（会造成等候），异步是非阻塞的（不会等候）；
大流量高并发请求、批量数据通报，就可以接纳异步处理，提拔体系吞吐量；

• 日志处理：
  

主要是用 kafka 这个服务器来做；
日志处理是指将消息队列用于在日志处理中，比如Kafka办理大量日志传输的题目；loger.info(.....)
ELK 日志处理办理方案：loger.error(.....) -->logstash收集消息--> 发送消息的kafka --> elastic search (es) -->Kibana ELK日志处理平台
2. MQ 的分类

• ActiveMQ：
  

• 长处： 单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性较 低的概率丢失数据。
  
• 缺点： 官方社区现在对 ActiveMQ 5.x 维护越来越少，高吞吐量场景较少使用。
  

• Kafka：
  

大数据的杀手锏，谈到大数据领域内的消息传输，则绕不开 Kafka，这款为大数据而生的消息中间件， 以其百万级 TPS 的吞吐量名声大噪，迅速成为大数据领域的宠儿，在数据采集、传输、存储的过程中发挥 着举足轻重的作用。目前已经被 LinkedIn，Uber, Twitter, Netflix 等大公司所采纳。

• 长处： 性能杰出，单机写入 TPS 约在百万条/秒，最大的长处，就是吞吐量高。时效性 ms 级可用性非 常高，kafka 是分布式的，一个数据多个副本，少数呆板宕机，不会丢失数据，不会导致不可用,消费者采 用 Pull 方式获取消息, 消息有序, 通过控制可以或许包管所有消息被消费且仅被消费一次;有良好的第三方 Kafka Web 管理界面 Kafka-Manager；在日志领域比力成熟，被多家公司和多个开源项目使用；功能支持： 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的及时计算以及日志采集被大规模使用。
  
• 缺点： Kafka 单机凌驾 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消 息响应时间变长，使用短轮询方式，及时性取决于轮询间隔时间，消费失败不支持重试；支持消息次序， 但是一台署理宕机后，就会产生消息乱序，社区更新较慢；
  

• RocketMQ：
  

RocketMQ 出自阿里巴巴的开源产物，用 Java 语言实现，在计划时参考了 Kafka，并做出了自己的一 些改进。被阿里巴巴广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场 景。

• 长处：  单机吞吐量十万级,可用性非常高，分布式架构，消息可以做到 0 丢失,MQ 功能较为美满，还是分 布式的，扩展性好,支持 10 亿级别的消息堆积，不会因为堆积导致性能降落,源码是 java 我们可以自己阅 读源码，定制自己公司的 MQ
  
• 缺点： 支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；社区活跃度一样平常,没有在 MQ 核心中去实现 JMS 等接口,有些体系要迁移需要修改大量代码
  

• RabbitMQ：
  

2007 年发布，是一个在 AMQP(高级消息队列协议)基础上完成的，可复用的企业消息体系，是当前最 主流的消息中间件之一。

• 长处： 由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比力完备,健壮、稳定、易 用、跨平台、支持多种语言 如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX 文档齐全；开源提供的管理界面非常棒，用起来很好用,社区活跃度高；更新频率相当高。
  
• 缺点： 商业版需要收费,学习本钱较高
  

3. MQ 的选择

• Kafka：
  

Kafka 主要特点是基于 Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集 和传输，得当产生大量数据的互联网服务的数据收集业务。大型公司发起可以选用，如果有日志采集功能， 肯定是首选 kafka 了。

• RocketMQ：
  

天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削 峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信任，这些业务 场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，发起可以选择 RocketMQ。

• RabbitMQ：
  

结合 erlang 语言自己的并发优势，性能好时效性微秒级，社区活跃度也比力高，管理界面用起来十分 方便，如果你的数据量没有那么大，中小型公司优先选择功能比力完备的 RabbitMQ。
4. RabbitMQ

4.1 RabbitMQ 的概念

RabbitMQ 是一个消息中间件：它接受并转发消息。你可以把它当做一个快递站点，当你要发送一个包 裹时，你把你的包裹放到快递站，快递员最终会把你的快递送到收件人那里，按照这种逻辑 RabbitMQ 是 一个快递站，一个快递员帮你通报快件。RabbitMQ 与快递站的主要区别在于，它不处理快件而是吸取， 存储和转发消息数据。
RabbitMQ 消息队列的官方地址： https://www.rabbitmq.com/

4.2 RabbitMQ 的四大核心概念

• 生产者：
  

生产者：产生数据发送消息的程序是生产者。

• 交换机：
  

交换机是 RabbitMQ 非常重要的一个部件，一方面它吸取来自生产者的消息，另一方面它将消息推送到队列中。交换机必须确切知道怎样处理它吸取到的消息，是将这些消息推送到特定队列还是推送到多个队列，亦或者是把消息丢弃，这个得有交换机类型决定。

• 队列：
  

队列是 RabbitMQ 内部使用的一种数据结构，尽管消息流经 RabbitMQ 和应用程序，但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束，本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列，许多消费者可以实验从一个队列吸取数据。这就是我们使用队列的方式。

• 消费者：
  

消费者与接受具有相似的含义。消费者大多时间是一个等候吸取消息的程序。请注意生产者，消费者和消息中间件许多时间并不在同一个呆板上，而可能是分布在不同地区的服务器当中。同一个应用程序既可以是生产者又可以是消费者。
4.3 RabbitMQ 六大核心部门

4.4 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 connectiion 的开销 。
  
• 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 的分发依据。
  

broker 相当于mysql服务器，virtual host相当于数据库（可以有多个数据库）queue相当于表，消息相当于记录。
消息队列有三个核心要素： 消息生产者、消息队列、消息消费者；
生产者（Producer）：发送消息的应用；（java程序，也可能是别的语言写的程序）
消费者（Consumer）：吸取消息的应用；（java程序，也可能是别的语言写的程序）
署理（Broker）：就是消息服务器，RabbitMQ Server就是Message Broker；
毗连（Connection）：毗连RabbitMQ服务器的TCP长毗连；
信道（Channel）：毗连中的一个虚拟通道，消息队列发送或者吸取消息时，都是通过信道举行的；
虚拟主机（Virtual host）：一个虚拟分组，在代码中就是一个字符串，当多个不同的用户使用同一个RabbitMQ服务时，可以分别出多个Virtual host，每个用户在自己的Virtual host创建exchange/queue等；（分类比力清晰、相互隔离）
交换机（Exchange）：交换机负责从生产者吸取消息，并根据交换机类型分发到对应的消息队列中，起到一个路由的作用；
路由键（Routing Key）：交换机根据路由键来决定消息分发到哪个队列，路由键是消息的目的地址；
绑定（Binding）：绑定是队列和交换机的一个关联毗连（关联关系）；
队列（Queue）：存储消息的缓存；
消息（Message）：由生产者通过RabbitMQ发送给消费者的信息；（消息可以任何数据，字符串、user对象，json串等等）

5. 最后：

“在这个最后的篇章中，我要表达我对每一位读者的感激之情。你们的关注和回复是我创作的动力源泉，我从你们身上吸取了无尽的灵感与勇气。我会将你们的鼓励留在心底，继续在其他的领域奋斗。感谢你们，我们总会在某个时间再次相遇。”

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。