本文目录：
- 1、有在实际开发中用到过rabbitmq等其他消息队列的仁兄呀，最近学习了rabbitmq的各种用法，
- 2、rabbitmq消息队列介绍
- 3、X-RAY里的mq是起什么作用
- 4、消息队列之zeroMQ、rabbitMQ、kafka
有在实际开发中用到过rabbitmq等其他消息队列的仁兄呀，最近学习了rabbitmq的各种用法，
消息队列的作用：数据分发，缓存数据，一份数据拷贝出N份供别人使用。
适用场景：
常用于一个生产者多个消费者的场景。
也可以是多个消费者一个生产者。
意义：说白了就是产生数据的和消费数据的解耦合。就像是个大鱼塘，放鱼的不用管抓鱼的。抓鱼的也不用管放鱼的。
你的问题：
这种场景通常因业务而产生
这说明你看的知识课本，或者简单的例子。
如果上面的说明还是没有说清楚，那么只能说明你查阅的资料还不够，或者没有专门查他的应用场景。
rabbitmq消息队列介绍
rabbitmq是建立在AMQP上的企业消息系统。
以生产者消费者为模型而存在的一个消息队列.
1、解耦
这是一个天然的解耦，实现了应用程序不再通过接口，你只需要调用消息队列的接口把结果存放在消息队列即可。
2、异步
一个同步的程序执行，通过消息队列，即可实现异步操作，而不必等待结果返回。在应对一些大并发中，起着很重要的作用.
如下图
这里就只有一个队列而已，生产者生产消费，放入到队列中，消费者进行消息消费。
这个能实现多个消费者之间进行消费的公平分发，消息者们可以通过自身的负载进行设置分发频率，比如。a消费者因为一些机器配置等的问题，导致消息没有被立即消费掉，堆积了很多消息，消费者就可以通过设置告诉rabbitmq控制分发频率，别一直发了。这其实就是类似能者多劳的意思。
如下图所示
上面的几种类型，都是消息只能发送到指定的queue中，但是想要类似广播的效果，发给所有消费者，或者像组播的形式，发送给某些特定的消费者。这时候就需要用到exchange了。
1、fanout 所有bind到此exchange的queue都可以接收消息
2、direct: 通过routingKey和exchange决定的那个唯一的queue可以接收消息
3、topic:所有符合routingKey(此时可以是一个表达式)的routingKey所bind的queue可以接收消息
表达式符号说明：
4、headers: 通过headers 来决定把消息发给哪些queue
如下图所示
这其实就是direct组播模式，设置好exchange交换机的类型，转发的时候，会检查队列中的routingkey值，如果和消息的关键字相同则转发，否则丢弃
这是topic模式，这个其实和上面一个转发有点类似，但是这个支持模糊匹配，
X-RAY里的mq是起什么作用
MQ起到消息队列的作用。
举个例子：
淘宝双十一抢单，当很多用户发送抢单请求，基本会造成线程阻塞等等
所以运用MQ，当用户发送请求，就存入MQ中，并没有占用多线程，然后一个一个进行处理。
当用户并发的也就是请求过多的时候，当请求不用第一时间处理的时候可以用MQ。同时MQ也可以持久化。MQ消息中可以是json，string等等，在消费者进行消费的时候要进行解析。MQ的消费者可以写成死循环进行消费。
消息队列之zeroMQ、rabbitMQ、kafka
首先消息是网络通讯的载体，队列可以理解是一种先进先出的数据结构，消息队列是存放消息的容器，是分布式系统中的重要组件。消息队列的优势在于：解耦、异步、削峰，把相关性不
强的模块独立分开视为解耦，异步就是非必要逻辑异步方式处理，加快响应速度，削峰是避免短期高并发导致系统问题进行缓冲队列处理。消息队列的缺点在于：加强系统复杂性、系统可用性降低，使
用了消息队列系统出现问题排查的范围就变大、需要考虑消息队列导致的问题。
本文说明主流的消息队列，针对使用过的zeroMQ和rabbitMQ、Kakfa：
zeroMQ ：C语言开发，号称最快的消息队列，本着命名zero的含义，中油中间架构使用简单，表面上是基于socket的封装套接字API，在多个节点应用场景下非常灵活、架构的可扩展性很强，
实现N到M的协同处理；
zmq的socket模式： req、rep、push、pull、pub、sub、router、dealer。
（1）req和rep：请求回应模型，req和rep都可以请求和回答，不同的只是req是先send再rec，rep是先rec再send。支持N个请求端一个接收端，也支持N个接收端一个请求端。N个接收端采
用rr负载均衡。 哪个是“一”端，哪个就bind端口，“N”端就只能connect，所以，req+rep无论谁bind端口，肯定要有一个是“一”。
（2） router和dealer：随时可以发送和接收的req和rep，看起来router+dealer跟 req+rep属于同类功能。因为router和dealer可以随时发送接收，所以它们可以用来做路由。一个router用来响
应N个req，然后它在响应处理的时候，再通过另一个socket把请求扔出去，接收者是另外的M个rep，这就做到N:M。
（3）pub和sub ：订阅和推送，对应发布者和订阅者。
（4）push和pull：就是管道，一个只推数据，一个只拉数据。
rabbitMQ ：使用erlang语言开发，高并发特点，基于AMQP（即Advanced Message Queuing Protocol）的开源高级消费队列，AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/
订阅）、可靠性、安全），企业级适应性和稳定性，并且有WEB管理界面方便用户查看和管理。以下是rabbitMQ的结构图：
（1）Producer:数据发送方，一般一个Message有两个部分：payload（有效载荷）和label（标签），payload是数据实际载体，label是exchange的名字或者一个tag，决定发给哪个Consumer；
（2）Exchange: 内部 消息交换器,exchange从生产者那收到消息后，一般会指定一个Routing Key，来指定这个消息的路由规则，当然Routing Key需要与Exchange Type及Binding key联合使用
才能最终生效，根据路由规则，匹配查询表中的routing key，分发消息到queue中；
（3）binding：即绑定，绑定（Binding）Exchange与Queue的同时，一般会指定一个Binding key，但不一定会生效，依赖于Exchange Type；
（4）Queue：即队列是rabbitmq内部对象，用于存储消息，一个message可以被同时拷贝到多个queue中，queue对load balance的处理是完美的。对于多个Consumer来说，RabbitMQ 使用循
环的方式（round-robin）的方式均衡的发送给不同的Consumer；
（5）Connection与Channel： Connection 就是一个TCP的连接，Producer和Consumer都是通过TCP连接到RabbitMQ Server， Channel 是为了节省开销建立在上述的TCP连接中的接口，大部
分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等；
（6）Consumer：即数据的接收方，如果有多个消费者同时订阅同一个Queue中的消息，Queue中的消息会被平摊给多个消费者；
（7）Broker: 即RabbitMQ Server，其作用是维护一条从Producer到Consumer的路线，保证数据能够按照指定的方式进行传输；
（8）Virtual host：即虚拟主机，当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue；
rabbitMQ消息转发中的路由转发是重点，生产者Producer在发送消息时，都需要指定一个RoutingKey和Exchange，Exchange收到消息后可以看到消息中指定的RoutingKey，再根据当前
Exchange的ExchangeType,按一定的规则将消息转发到相应的queue中去。三种Exchage type：
（1）Direct exchange ：直接转发路由，原理是通过消息中的routing key，与binding 中的binding-key 进行比对，若二者匹配，则将消息发送到这个消息队列；
比如：消息生成者生成一个message(payload是1，routing key为苹果)，两个binding(binding key分别为苹果、香蕉);exchange比对消息的routing key和binding key后，将消息发给了queue1，消息消费者1获得queue1的消息；
（2）Topic exchange： 通配路由，是direct exchange的通配符模式，
比如：消息生成者生成一个message(payload是1，routing key为quick.orange.rabbit)，两个binding(binding key分别为*.orange. 、 *.*.rabbit)；exchange比对消息的routing key和binding key
后,exchange将消息分发给两个queue，两个消费者获得queue的消息；
（3）Fanout exchange： 复制分发路由，原理是不需要routkey，当exchange收到消息后，将消息复制多份转发给与自己绑定的消息队列，
比如：消息生成者生成一个message(payload是1，routing key为苹果)，两个binding(binding key分别为苹果、香蕉)；exchange将消息分发给两个queue，两个消费者获得queue的消息；
rabbiMQ如何保证消息的可靠性？
（1）Message durability：消息持久化，非持久化消息保存在内存中，持久化消息写入内存同时也写入磁盘；
（2）Message acknowledgment：消息确认机制，可以要求消费者在消费完消息后发送一个回执给RabbitMQ，RabbitMQ收到消息回执（Message acknowledgment）后才将该消息从Queue中移
除。通过ACK。每个Message都要被acknowledged（确认，ACK）。
（3）生产者消息确认机制：AMQP事务机制、生产者消息确认机制（publisher confirm）。
最后， 对比一下zeroMQ、rabbitMQ、kafka主流的消息队列的性能情况：
对比方向 概要
吞吐量 万级 RabbitMQ 的吞吐量要比 十万级甚至是百万级Kafka 低一个数量级。ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。
可用性 都可以实现高可用。RabbitMQ 都是基于主从架构实现高可用性。 kafka 也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
时效性 RabbitMQ 基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他两个个都是 ms 级。
功能支持 Kafka 功能较为简单，主要支持简单的MQ功能，在大数据领域实时计算以及日志采集被大规模使用；ZeroMQ能够 实现RabbitMQ不擅长的高级/复杂 的队列
消息丢失 RabbitMQ有ack模型，也有事务模型，保证至少不会丢数据， Kafka 理论上不会丢失，但不排除批量情况下。
开发环境 RabbitMQ需要erlang支持、kafka基于zookeeper管理部署、zeroMQ程序编译调用即可
封装库 基于c++开发，使用RabbitMQ-C，cppKafka，而zeroMQ基于C语言开发，无需封装
【消息队列作用】的内容来源于互联网，如引用不当，请联系我们修改。
网友留言：