RabbitMQ消息队列

一、消息队列简介

1.主流的消息队列

        目前主流的几大消息队列有:RabitMQ、ActiveMQ、RocketMQ、Kafka、ZeroMQ 等也有一些小众的比如 Beanstalk, Redis 也可以实现消息队列的功能。

(1)ActiveMQ

        基于 JAVA 语言开发，其社区算是比较成熟，但是目前来说，ActiveMQ的性能比较差而且版本迭代很慢，不推荐使用。

(2)RocketMQ

        阿里出品，Java 系开源项目,源代码可以直接阅读，可以定制自己公司的MQ并且 RocketMQ 有阿里巴巴的实际业务场景的实战经验。RocketMQ社区活跃度相对较为般，不过也还可以，文档相对来说简单，接口不是按照标准 JMS 规范,有些系统要迁移需要修改大量代码。

(3)Kafka

        由 Scala 和 Java编写，其特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。Kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。 

(4)RabbitMQ

        虽然稍逊于 Kafka和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为RabbitMQ基于 erlang 开发，所以国内很少有公司有实力做 erlang 源码级别的研究和定制。如果业务场景对并发量要求不是太高(十万级、百万级)，那这四种消息队列中，RabbitMQ 一定是首选。如果是大数据领域的实时计算、日志采集等场景，用Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

(5)ZeroMQ

        只是一个网络编程的Pattern库，将常见的网络请求形式(分组管理，链接管理，发布订阅等)模式化、组件化，简而言之 socket 之上、MQ之下。对于 MQ来说，网络传输只是它的一部分，更多需要处理的是消息存储、路由、Broker 服务发现和查找、事务、消费模式(ack、重投等)、集群服务等。

2.各种不同消息队列的对比

        在面向服务架构中通过消息代理(比如 RabbitMo /Kafka 等)，使用生产者/消费者模式在服务间进行异步通信是一种比较好的思想。
        ZeroMQ 和 RabbitMQ/Kafka 不同,它只是一个异步消息库,在套接字的基础上提供了类似于消息代理的机制。使用 ZeroMQ 的话，需要对自己的业务代码进行改造，不利于服务解耦。
        RabbitMQ 支持 AMQP(二进制)，STOMP(文本)，MQTT(二进制)，HTTP(里面包装其他协议)等协议。而Kafka 使用自己的协议。
        Kafka 自身服务和消费者都需要依赖 Zookeeper。
        RabbitMQ 在有大量消息堆积的情况下性能会下降，Kafka不会，毕竟 AMQP 设计的初衷不是用来持久化海量消息的，而Kafka一开始是用来处理海量日志的。
        总的来说,RabbitMQ 和 Kafka 都是十分优秀的分布式的消息代理服务,只要合理部署不作，基本上可以满足生产条件下的任何需求。

3.消息队列中角色/名词

        Broker：消息服务器，作为server 提供消息核心服务
        Producer：消息生产者，业务的发起方，负责生产消息传输给broker
        Consumer：消息消费者，业务的处理方，负责从broker 获取消息并进行业务逻辑处理
        Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向 topic 发送消息，由 MQ服务器分发到不同的订阅者，实现消息的广播
        Queue：队列，PTP 模式下，特定生产者向特定 queue 发送消息，消费者订阅特定的 queue 完成指定消息的接收
        Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

4.消息队列中两种工作模式

(1)Point-to-Point

        其实就是点对点，其过程理解起来比较简单。它好比是两个人打电话，这两个人是独享
这一条通信链路的。一方发送消息，另外一方接收，就这么简单。在点对点模式下，消息被保留在队列中。 一个或多个消费者可以消耗队列中的消息，但是特定消息只能由最多一个消费者消费。一旦消费者读取队列中的消息，它就从该队列中消失。该模式的典型示例，如订单处理系统，其中每个订单将由一个订单处理器处理,但多个订单处理器也可以同时工作。

(2)Pub/sub

        即发布/订阅模式，该模式有点类似于我们日常生活中订阅报纸。对于每一个订阅者来说，可以选择一份或者多份报纸。那么这些我们订阅的报纸，就相当于发布订阅模式里的topic。有很多个人订阅报纸，也有人可能和我订阅了相同的报纸。多人订阅了相同的报纸相当于多人在同一个 topic 里注册了。对于一份报纸发行方来说，它和所有的订阅者就构成了一个1对多的关系。在这种模式下，消息被保留在主题中。 与点对点模式不同，消费者可以订阅一个或多个主题并使用该主题中的所有消息。该模式下消息生产者称为发布者消息使用者称为订阅者。

5.消息队列缺点

        由于消息队列的异步特性，直接提升了整个架构的处理效率，提升了用户体验。但凡事都有两面性，消息队列在带来性能提升的同时也伴随着缺陷。

(1)系统可用性降低

        毕竟在整个架构中，我们单独加了一个消息队列中间件，所以增加了风险，如果消息队列服务挂掉，势必会影响到整个架构。

(2)系统复杂性提高

        本来非常简单的一个逻辑设计，但偏偏要在中间插入一个消息队列，所以这增加了程序员的工作量，需要考虑如何保证消息没有被重复消费、消息有没有丢失、消息顺序等细节问题。

(3)数据一致性无法保证

        消息如果没有正确写入到消息队列里，或者说读取消息的服务并没有正确读取到消息，这都会影响到数据的一致性。

二、RabbitMQ介绍

        RabbitMQ 是一款在全球范围内使用非常广泛的开源消息队列中间件。它轻量级、易部署、并支持多种协议。它基于 Erlang 开发，天生拥有高并发的能力。

1.RabbitMQ 相关术语

生产者：产生消息的进程或服务
消费者：接收消息的进程或服务
队列：RabbitMQ 是消息队列中间件，而真正储存消息数据的就是队列，队列可以有很多。
交换器：类似于网络设备交换机，它可以根据不同的关键字，将消息发送到不同的队列。
虚拟主机：
        虚拟主机类似于 Apache 的虚拟主机，如果没有虚拟主机，当 RabbitMQ 中的数据越来越庞大，队列越来越多，随之而来的是令人头痛的管理问题，比如队列、交换器命名冲突,它们相互影响等等。虚拟主机能够解决这些问题，而不需要我们部署多个 RabbitMQ 来负责不同的业务。
        虚拟主机提供了资源的逻辑分组和分隔,每一个虚拟主机本质上是mini版的RabbitMo服务器，他们有用自己的连接、队列、绑定、交换器，更重要的是有用自己的权限机制，这有点类似服务器和运行在服务器上的虚拟机一样。 

2.RabbitMQ的拓扑结构