MQ(Message Queue)消息队列

本文引用于消息队列（MQ）简介_张DD的代码铺的博客-CSDN博客_mq

MQ 介绍

        MQ（Message Queue）消息队列，是基础数据结构中“先进先出”的一种数据结构。指把要传输的数据（消息）放在队列中，用队列机制来实现消息传递——生产者产生消息并把消息放入队列，然后由消费者去处理。消费者可以到指定队列拉取消息，或者订阅相应的队列，由MQ服务端给其推送消息

MQ的功能

        消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。

1.应用解耦：

        一个业务需要多个模块共同实现，或者一条消息有多个系统需要对应处理，只需要主业务完成以后，发送一条MQ，其余模块消费MQ消息，即可实现业务，降低模块之间的耦合。

​

         如上图 未使用mq时 如果用户创建订单，耦合调用子系统，任何一个子系统出现故障，都会造成下单操作异常。

        如下图。而当使用mq后 订单系统和其余系统完成解耦，就不必担心其他系统出现故障，系统间的调用问题会减少很多，比如任何一个子系统发生故障，需要一定的时间修复，发送故障的子系统处理的内存会被缓存在消息队列中，用户的操作可以正常完成，故障子系统恢复后，处理订单即可，消息队列提升了系统的可用性。

​

2.异步处理 ：

        异步：主业务执行结束后从属业务通过MQ，异步执行，减低业务的响应时间，提高用户体验。

        有些服务间的调用并不是同步的，而是异步执行，例如，A调用B，B需要花费很长时间执行，此时A需要知道B什么时间可以执行完成，在未使用MQ时，一般会有两种方法实现，1.A不断地轮询查看B是否完成。2、就是A提供一个调用接口，当B执行完成之后，调用A的回调接口，以此实现。

        如果使用mq，A调用B后，只需要监听B处理完成消息，当B处理完后，会发送一条消息给MQ，MQ会将此消息转发给A服务。这样就省去了A的轮询或者B对A的回调。A也能够即使得到异步处理消息。 

3.流量削峰：

        削峰：高并发情况下，业务异步处理，提供高峰期业务处理能力，避免系统瘫痪。

        比如说，如果订单系统最多能处理一万次订单，这个处理能力应付正常时段的下单时是没有问题的，正常时段我们下单一秒后就能返回结果。但是在高峰期，如果有两万次下单操作系统是处理不了的，只能限制订单超过一万后不允许用户下单。使用MQ做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功，虽然这样会影响一定的体验，但是要比不能下单好的多。

主要的MQ产品

1.ActiveMQ

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

2.Kafka

        适用场景

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

        优点：性能卓越 ，单机写入每秒事务处理量约百万条每秒，时效性毫秒级，可用性非常高，分布式，不会丢失数据，不会导致不可用，有优秀的管理界面，日志领域比较成熟，最大的优点就是吞吐量高。低延迟，持久性，扩展性，容错性，支持多种客户端语言。

        缺点：kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变成，使用短轮询方式，实时性取决于轮询间隔时间，消息失败不支持重试，支持消息顺序，但是一台代理宕机后，就会产生消息乱序，社区更新较慢；

3、RocketMQ

        适应场景

        出自阿里巴巴，天生为金融互联网领域而生,对于可靠性要求很高的场景，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。rocketmq在稳定性上值得信赖。

        优点：单机吞吐量十万级别，可用性非常高，分布式架构，消息可以做到0丢失，扩展性好，支持十亿级别的消息堆积，不会因为堆积导致性能下降。

        缺点：支持的客户端语言不多，java，c++，社区活跃度一般，在c++中不成熟，有些系统要迁移需要修改大量代码。

4.RabbitMQ

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

        适应场景

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

        优点：由于erlang语言的高并发特性，性能较好，吞吐量万级，mq功能比较完善，稳定，易用，跨平台，支持多种语言，社区活跃度高。

        缺点：吞吐量不高，不适用于大项目。

        RabbitMQ工作模式及原理

        启动rabbitmq 

        docker run -d --hostname my-rabbit --name rabbit -p 15672:15672 -p 5672:5672  rabbitmq 

详细访问​​​​​​RabbitMQ的工作模式及原理

SpringBoot集成RabbitMq_Blueeyedboy521的博客-CSDN博客_springboot集成rabbitmq

一、RabbitMQ的5大核心概念

Connection（连接）：

        每个producer（生产者）或者consumer（消费者）要通过RabbitMQ发送与消费消息，首先就要与RabbitMQ建立连接，这个连接就是Connection。Connection是一个TCP长连接。

Channel（信道）：

        Channel是在Connection的基础上建立的虚拟连接，RabbitMQ中大部分的操作都是使用Channel完成的，比如：声明Queue、声明Exchange、发布消息、消费消息等。

Exchange（交换机）：

        Exchange是一个比较重要的概念，它是消息到达RabbitMQ的第一站，主要负责根据不同的分发规则将消息分发到不同的Queue，供订阅了相关Queue的消费者消费到指定的消息。

1.direct：direct的意思是直接的，direct类型的Exchange会将消息转发到指定Routing key的Queue上，Routing key的解析规则为精确匹配。也就是只有当producer发送的消息的Routing key与某个Binding key相等时，消息才会被分发到对应的Queue上。

所以，direct类型的Exchange在分发消息时，必须保证producer发送消息的Routing key与Exchange和Queue绑定的Binding key相等才可以。

2.fanout：fanout是扇形的意思，该类型通常叫作广播类型。fanout类型的Exchange不处理Routing key，而是会将发送给它的消息路由到所有与它绑定的Queue上。

所以，fanout类型的Exchange不管Routing key是什么，它都会将接收到的消息分发给所有与自己绑定了的Queue上。

3、topic：topic的意思是主题，topic类型的Exchange会根据通配符对Routing key进行匹配，只要Routing key满足某个通配符的条件，就会被路由到对应的Queue上。通配符的匹配规则如下：

● Routing key必须是一串字符串，每个单词用“.”分隔；

● 符号“#”表示匹配一个或多个单词；

● 符号“*”表示匹配一个单词。

例如：“*.123” 能够匹配到 “abc.123”，但匹配不到 “abc.def.123”；“#.123” 既能够匹配到 “abc.123”，也能匹配到 “abc.def.123”。

4、headers：headers Exchange中，Exchange与Queue之间的绑定不再通过Binding key绑定，而是通过Arguments绑定。

producer在发送消息时可以添加headers属性，Exchange接收到消息后，会解析headers属性，只要我们上面配置的Argmuents中的所有属性全部被包含在Headers中并且值相等，那么这条消息就会被路由到对应的Queue中。

Queue（队列）：

        Queue是一个用来存放消息的队列，生产者发送的消息会被放到Queue中，消费者消费消息时也是从Queue中取走消息。

Virtual host（虚拟主机）：

        Virtual host是一个虚拟主机的概念，一个Broker中可以有多个Virtual host，每个Virtual host都有一套自己的Exchange和Queue，同一个Virtual host中的Exchange和Queue不能重名，不同的Virtual host中的Exchange和Queue名字可以一样。这样，不同的用户在访问同一个RabbitMQ Broker时，可以创建自己单独的Virtual host，然后在自己的Virtual host中创建Exchange和Queue，很好地做到了不同用户之间相互隔离的效果。