RabbitMQ 基本概念
上面只是最简单抽象的描述，具体到 RabbitMQ 则有更详细的概念需要解释。 RabbitMQ 是 AMQP 协议的一个开源实现，所以其内部实际上也是 AMQP 中的基本概念：
AMQP（Advanced Message Queuing Protocol，高级消息队列协议）是一个进程间传递异步消息的网络协议。
AMQP模型
RabbitMQ 内部结构
- Message
消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。 - Publisher
消息的生产者，也是一个向交换器发布消息的客户端应用程序。 - Exchange
交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。 - Binding
绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。 - Queue
消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。 - Connection
网络连接，比如一个TCP连接。 - Channel
信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。 - Consumer
消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。 - Virtual Host
虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。 - Broker
表示消息队列服务器实体
作者：预流
链接：https://www.jianshu.com/p/79ca08116d57
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
一.消息队列常用的场景
1.削峰
例如我们做得考试系统中，用户通过人脸识别登录系统，考虑到考试系统的特殊性，三万名考生参加考试，需要记录人脸识别登录照片。从考试完结果上看，用户最大并发数在4000，于是我们采用rocketMq来进行异步消费用户人脸识别图片，当时统计rocketMq每秒1000消费消息。及时反馈了考生人脸识别登录成功，对数据库写操作也起到很大的缓冲功能。
2.解耦
如常用ABCD系统中，BCD系统都需要从A系统中调用接口返回数据，这时候突然来了E系统，也需要A系统数，又或者C系统不想要用这个接口数据了，而且A系统还得考虑，如果BCD接收不到数据，接收失败咋整之类的问题。
如果基于消息队列，这些问题就迎刃而解了。
A系统直接把数据扔到Mq中，BCDE系统直接从Mq中消费，如果消费失败，则重试消费。
3.异步
比如下订单系统中，会调用库存系统，会调用仓库系统，积分系统等，用户订单操作会直接返回给用户信息，提示订单完成，至于库存减少，或者仓库发货又或者积分的增加等，都是异步完成。极大的提高用户响应速度。
针对我的项目cloudos系统，消息队列用在实例的创建之后，操作日志更新、租期授权等的更新，以及普通用户申请之后，流程处理完毕通知各个组件进行实例创建。达到异步解耦的目的，避免复杂的多处接口调用及修改。（解耦）同时创建大量实例，提高响应速度（异步削峰）
二.各种消息队列优缺点
1.rabbitMq
rabbitMq 几万级数据量，基于erlang语言开发，因此响应速度快些，并且社区活跃度比较活跃，可视化界面。缺点就是数据吞吐量相对与小一些，并且是基于erlang语言开发，比较重的问题难以维护。
2.rocketMq
rocketMq几十万级别数据量，基于Java开发，应对了淘宝双十一考验，并且文档十分的完善，拥有一些其他消息队列不具备的高级特性，如定时推送，其他消息队列是延迟推送，如rabbitMq通过设置expire字段设置延迟推送时间。又比如rocketmq实现分布式事务，比较可靠的。
3.kafka
kafka真正的大规模分布式消息队列，提供的核心功能比较少。基于zookeeper实现的分布式消息订阅。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 开发语言 | java | erlang | java | scala |
| 单机吞吐量 | 万级 | 万级 | 10万级 | 10万级 |
| 时效性 | ms级 | us级 | ms级 | ms级以内 |
| 可用性 | 高(主从架构) | 高(主从架构) | 非常高(分布式架构) | 非常高(分布式架构) |
| 功能特性 | 成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好 缺点：现在社区版本更新很慢 | 基于erlang开发，所以并发能力很强，性能极其好，延时很低;管理界面较丰富 社区更新活跃 | MQ功能比较完备，扩展性佳 阿里的 | 只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广。 |
三.消息队列常使用的注意事项或者面试时候经常问道的功能点
引入消息队列的缺点：是系统复杂度变高、可用性降低，一旦MQ发生故障，会影响整个系统；一致性顺序性问题，一部分消费失败了怎么办
1.如何保证系统的高可用
就rabbitMq而言，有镜像集群模式概念，就是用户在发送数据时候，发送到mq机器上，并且持久化磁盘，然后通过设置镜像的queue，把数的持久化地址对应表同步到另外mq机器上。这种就有效防止一台mq挂了以后，另外的mq可以直接对外提供消费功能。
(同步镜像到其他节点上，非分布式)
就rocketMq而言，分为多主集群结构，多主多备异步复制结构，多主多备同步复制结构。
2、消息可靠性传输
消息重复消费：
（消息重复消费的产生：记录offsetMQ顺序的时候重启了，没有记录下来已消费的对应顺序MQ序列）
接口幂等。
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现.
通俗了讲就是你同样的参数调用我这个接口，调用多少次结果都是一个
记录唯一id（消费了之后记录它的id,放在redis或其他地方。若收到数据，先查一下消费了没有）
数据丢失问题：
消息丢失的原因？
生产者、MQ、消费者都有可能造成消息丢失
如何保证消息的可靠性？
- 发送方采取发送者确认模式
- MQ进行队列及消息的持久化
-
消费者消费成功后手动确认消息
生产者丢失：
解决方法1：事务机制，如果发送异常则重发（问题：是同步的，会等待成功失败，导致吞吐量受影响）
解决方法2（常用的，异步，吞吐量较高）：发送方确认机制。channel设置成confirm模式，rabbitMQ收到消息后会回调生产者接口，告诉生产者已经收到；若接收消息的时候报错了，就回调告诉失败，重新发送
MQ丢失：
需要将队列和消息都进行持久化。持久化异常几率很小
消费者丢失：关闭自动确认AutoAck，手动确认已收到
消费顺序：使用队列Queue，同一个订单的放到一个队列里（即不同的消费者对应不同的queue）
生产故障：MQ数据大量积压：
把原来的消费者停掉，申请使用更多的资源，新建大量的临时消费者，快速的处理数据
不设置MQ消息的过期时间
rabbitMQ Exechange的种类
四种ExchangeType分别是Direct exchange，Fanout exchange，Topic exchange和Headers exchange
| ExchangeType | Fanout exchange | Topic exchange | Direct exchange | Headers exchange |
| 名称 | 订阅模式 | 通配符模式 | 路由模式 | |
| 发布方式 | 忽略routing key的存在, 广播 | message发送到一个或者多个Queue中 模糊匹配routing key | 添加了一个路由键routing key routing key一般同Queue同名 | 根据header,而不是routing key |
链接：https://www.jianshu.com/p/3d5870410f55
链接：https://www.jianshu.com/p/6efbe69e9c00
1468
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
