大家好，开发公司我是卷心菜。开发公司如果您看完这篇文章有所收获，开发公司可以三连支持博主哦~，嘻嘻。
文章目录
🎁作者简介：开发公司在校大学生一枚，Java开发公司领域新星创作者，Java、Python开发公司正在学习中，开发公司期待和大家一起学习一起进步~
💗个人主页：
🔶本文专栏：
📕自我提醒：开发公司多学多练多思考，开发公司编程能力才能节节高！
一、MQ开发公司的基本概念
MQ全称 Message Queue（消息队列），开发公司是在消息的传输过程中开发公司保存消息的容器，开发公司其本质是个队列。开发公司多用于分布式系统之间进行通信。其中，开发公司发送数据的一方称为生产者；开发公司接收数据的一方称为消费者。
二、MQ的优势
1、应用解耦
- 开发公司以电商应用为例，应用中有订单系统、库存系统、物流系统、支付系统。当用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出现了故障，都会造成下单操作异常。
- 当转变为消息队列的方式后，系统间调用的问题会减少很多，比如库存系统因为发生故障，需要几分钟来修复。但并不会影响我们正常下单，因为下单后，可以把订单系统写入消息队列，就不用担心其它的后续操作了，实现了解耦。
2、异步处理
- 以用户注册后，需要发注册邮件和注册短信为例，使用传统方式时，我们会将注册信息写入数据库成功后，发送注册邮件同时发送注册短信。当这些任务完成后，返回给客户端。
- 当我们使用消息队列，可以将不是必须的业务逻辑，进行异步处理。用户的响应时间相当于是注册信息写入数据库的时间，注册邮件、发送短信写入消息队列后，直接返回，因此用户的响应时间非常的快。
3、流量削峰
- 以订单系统为例，如果订单系统在正常时段最多可以处理一万次订单，但到了双十一，有两万次下单操作，这时订单系统就会崩掉。因此可以使用消息队列做缓冲，我们可以把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但总比不能下单的体验感好！
三、MQ的分类
- 目前有很多MQ的产品，例如RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ等，也可以使用Redis充当消息队列，而这些消息队列产品，各有侧重，在实际选型时，需要结合自身需求及MQ产品特征，综合考虑。
四、简介
RabbitMQ是一个消息中间件，采用Erlang语言开发。它接受并转发消息。你可以把它当做一个快递站点，当你要发送一个包裹时，你把你的包裹放到快递站，快递员最终会把你的快递送到收件人那里。RabbitMQ 与快递站的主要区别在于，它不处理快件而是接收，存储和转发消息数据。
- RabbitMQ基础架构如图：
五、四大核心概念
- 生产者：产生数据发送消息的程序是生产者
- 交换机：交换机是 RabbitMQ 非常重要的一个部件，一方面它接收来自生产者的消息，另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接收到的消息，是将这些消息推送到特定队列还是推送到多个队列，亦或者是把消息丢弃，这个得有交换机类型决定
- 队列：队列是 RabbitMQ 内部使用的一种数据结构，尽管消息流经RabbitMQ 和应用程序，但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束，本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列，许多消费者可以尝试从一个队列接收数据。
- 消费者：消费与接收具有相似的含义。消费者大多时候是一个等待接收消息的程序。请注意生产者，消费者和消息中间件很多时候并不在同一机器上。同一个应用程序既可以是生产者又是可以是消费者
六、工作原理
各个名词的介绍：
- Broker：接收和分发消息的应用，RabbitMQ Server 就是 Message Broker
- 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 的分发依据
感谢阅读，一起进步，嘻嘻~