rabbitmq.jpeg
由于最近项目中使用到了消息队列RabbitMQ，所以想总结一下自己的学习过程，一来可以加深下自己对技术的理解，二来也可以分享一下自己学到东西。
什么是消息队列
先引用下维基百科的定义：
消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。
消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中，直到接收者取回它。
这个解释比较官方，通俗的讲消息队列就是基于Pub/Sub发布订阅模型的消息中间件，它具有异步性、高并发，时效性以及数据可靠性等特点。
MQ的应用场景
这也是我们为什么使用MQ的原因。消息对列的使用场景还是蛮多的，但是比较核心的主要有这三个：解耦、削峰和异步通信。
-
应用解耦：
有这么个场景。A系统要发送数据BCD系统，通过接口发送。如果有一天E系统也需要这个数据或者说C系统又不需要数据了，这种情况下每次需求的变动都需要A系统做相应的改动，而且A系统还要考虑处理BCD系统挂了的情况，所以这相对于A系统来说是极其高耦合的。
那么如果使用MQ，A系统产生一条数据，它只管把数据仍到消息队列里去，其他系统如果需要这些数据，自己去MQ里消费。通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。
-
流量削峰：
比如说，有这样一个系统，它大部分情况下流量都是正常的，但是会存在某个高峰期，高峰期下大量的请求过来系统可能就会崩溃，用户无法正常访问系统。
如果使用MQ，所有的请求都发送到MQ，系统慢慢的从MQ中消费数据，这样即使是在高峰期的时候，系统也只会处理它能承受的最大请求量，这样系统就绝不会挂掉了。
所以在高并发，大流量的场景下，rabbitmq可以减少突发访问压力，不会因为突发的超时负荷要求而崩溃
-
异步通信：
再来看一个场景，A系统接收一个请求，不仅需要本地写库，还需要发送数据给其他系统写库，比如说发送日志信息给日志系统，或者其他一些备份数据等一些不是实话的业务处理。如果是同步的话，用户等待这个请求处理完成的时间就会很长，用户体验就会很差。那么如果是异步的话，将数据发送给消息队列就直接返回，后续由其他系统自己消费慢慢处理。这样对于用户来说就是无感知的，用户体验度就会大大提升。
常见的消息队列
当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka等等，而部分数据库像redis这种也能实现消息队列的功能。
既然有这么多消息队列，所以我们要使用一款产品，就需要调用分析各个产品的优缺点，这里借用一张网上分析的表格，我觉得分析对比的很清楚。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，比 RocketMQ、Kafka 低一个数量级 | 同 ActiveMQ | 10 万级，支撑高吞吐 | 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic 数量对吞吐量的影响 | topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic | topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 | ||
| 时效性 | ms 级 | 微秒级，这是 RabbitMQ 的一大特点，延迟最低 | ms 级 | 延迟在 ms 级以内 |
| 可用性 | 高，基于主从架构实现高可用 | 同 ActiveMQ | 非常高，分布式架构 | 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 经过参数优化配置，可以做到 0 丢失 | 同 RocketMQ |
| 功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
综上，各种对比之后，有如下建议：
一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；
不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
我比较推荐使用RabbitMQ或者Kafka，这次呢先学习研究下RabbitMQ。
RabbitMQ安装教程
RabbitMQ 是一个由 Erlang 开发的 AMQP (Advanced Message Queuing Protocol) 的开源实现。
因为RabbitMQ是服务端代码是使用并发式语言Erlang编写的，所以安装RabbitMQ的前提是安装Erlang。
需要注意的点就是Erlang的版本和RabbitMQ的版本要对应。具体可以参考官方版本要求：
-
下载安装Erlang
-
下载安装RabbitMQ
下载安装完成之后，启动RabbitMQ服务，在浏览器访问http://localhost:15672就会出现以下界面：
image-20200626134948968.png
)
默认的账号密码是guest，guest，登录之后就会出现以下界面：
image-20200626235319493.png
RabbitMQ术语解释
RabbitMQ架构模型图：
架构图.png
- Message
消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。
Publisher
消息的生产者，也是一个向交换器发布消息的客户端应用程序。
Exchange
交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
- Routing Key
路由关键字,exchange根据这个关键字进行消息投递。
- Binding
绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。
- Queue
消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
- Connection
网络连接，比如一个TCP连接。
- Channel
信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。
- Consumer
消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。
- Virtual Host
虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。
- Broker
表示消息队列服务器实体。它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输,
RabbitMQ交换机模型
Exchange 分发消息时根据类型的不同分发策略有区别，目前共四种类型：direct、fanout、topic、headers 。headers 匹配 AMQP 消息的 header 而不是路由键，此外 headers 交换器和 direct 交换器完全一致，但性能差很多，目前几乎用不到了，所以直接看另外三种类型：
-
Direct
Direct.png
消息中的路由键（Routing Key）如果和 Binding 中的 Binding Key 一致， 交换器就将消息发到对应的队列中。路由键与队列名完全匹配，如果一个队列绑定到交换机要求路由键为 “key1”，则只转发 Routing Key 标记为 “key1” 的消息，不会转发 “key2”。它是完全匹配、单播的模式。
-
Fanout
Fonout.png
每个发到 fanout 类型交换器的消息都会分到所有绑定的队列上去。fanout 交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。fanout 类型转发消息是最快的。
-
Topic
Topic.png
topic 交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。它同样也会识别两个通配符：符号 “#” 和符号 “*”。# 匹配 0 个或多个单词，匹配不多不少一个单词。
比如说A.#将会匹配到A.B、A.B.C等等，而A.*能匹配到A.B，不能匹配到A.B.C
参考资源
小结
本节主要是从概念的角度出发讲了下消息队列的使用场景，也就是我们为什么要使用消息队列以及对比分析了各个消息队列的优缺点。另外也重点介绍了消息队列的架构模型和基本概率。
下一节呢主要是从代码的角度出发介绍以下我们如何去使用消息队列，以及面对消息丢失了，我们该如何去处理。
网友评论