#说在前面
IT行业中的运维范畴，除了传统运维再就是互联网运维，这两样，UP楠哥都做过，特别是对互联网运维的那段时间记忆犹新；主要是PAAS层的一些技术，例如使用到rabbitmq、kakfa、zookeeper、redis、flink等。消息队列的集群化部署，通过Grafana做可视化的监控。后来再做云计算如OpenStack以及SDN软件定义网络如VMware NSX这样的方案落地中发现，OpenStack的块存储Cinder 会使用到 RabbitMQ 与各组件的使用、消息的发送和接收；另外，VMware NSX中也会用到RabbitMQ已进程方式寄宿在管理平面中NSX Manager中发送消息到各个ESXi中。
其实咱们的IT行业中，除了RabbitMQ之外还有很多的消息队列的东东， ActiveMQ、Kafka 、ZeroMQ ，阿里捐赠给 Apache 的 RocketMQ以及Redis也支持MQ。但是纵观行业几个大佬，好像都对RabbitMQ情有独钟，把它纳入自己的方案提供消息队列。UP楠哥今天和大伙唠一唠消息队列的概念、RabbitMQ以及与其它不同。Let’s go !
#消息队列概念
消息（Message）是指在应用间传输的数据。消息可以是简单的比如只包含文本字符串，也可以自定义复杂的对象，只要能按设定格式解析出来就可以。
消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。是一种先进先出数据结构，它是存放消息的一个盒子或容器中，消息从队尾入队，从队头出队，入队即发消息的过程，出队即收消息的过程。消息发布者只管把消息发布到消息队列中而不用管谁来取，消息使用者只管从消息队列中取消息而不管是谁发布的。
举个实际点的例子，UP楠哥上大学的时候兼职某快餐店，腌制鸡腿肉的大叔们(我们称作为消息发布者)早上把腌制好的鸡腿肉放到冷冻库(我们成为消息队列的盒子或容器)，冷冻库里一定还有隔天晚上剩余的鸡腿肉，此时大叔们会把它们放到冷冻库架子上的最顶端，新腌制好的鸡腿肉放在第二层或者最下层。这样秉承FIFO(先进先出)的原则，作为厨房小能手的UP楠哥(我们成为消息使用者)会把冷冻库中最顶端的鸡肉拿出来进行处理，完成后再去拿第二层、第三层最顶端的腌制鸡肉，此过程中一旦大叔们把新腌制好的鸡肉拿到冷冻库，都会按照这个逻辑，一直循环下去。
以上的发生在UP楠哥真实的例子，就可以很多好的体现出消息队列的一个过程是怎样的。简单再画个逻辑图，如下：
以上的例子其实就是消息队列中最原始的一个模型，消息按照什么顺序写进去，就按照什么顺序读出来。不过，队列没有 “读” 这个操作，读就是出队(把鸡肉从冷冻库拿出)，从队头中删除(处理)这个消息。
那么我们还需要在思考一个问题，快餐店有没有可能只有一种鸡腿肉可以卖，答案肯定不是，有什么香辣鸡腿肉、不辣的鸡腿肉，还有劲鸡爆米花(额，不对，是劲爆鸡米花-)，所以这个时候我们就要分门别类的区分(我们称作主题Topic)，厨房员工的职责也会再细分(我们称作为订阅者)，例如UP楠哥和助教武教练(订阅者)只负责香辣鸡腿肉(主题Topic) 、我们的张Sir和Wiki老师(订阅者)只负责不辣的鸡腿肉(主题Topic)等。此时，演化出了另外一种消息模型叫做发布->订阅模型，为了将一份消息数据分发给多个消息使用者，并且每个消息使用者都会收到完整的消息。
这种发布->订阅模型，存放鸡腿肉的冷冻库变成了“主题“这个名词，各个订阅者在接收消息之前需要明确自己的负责范围(订阅主题)；每个订阅者都可以收到同一个主题的完整消息。发布->订阅模型和第一种模型不同点在于：一份消息信息可以被多次使用。
#RabbitMQ自身特点
RabbitMQ原生就支持上面提到的两种消息模式，RabbitMQ是一套开源（MPL）的消息队列服务软件，是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，是由以高性能、健壮以及可伸缩性出名的 Erlang 语言写成。它的logo是一只橘色的小兔子，难道是表明自己处理消息会很快还是自己很可爱？？？(此时rapper身份的功底无疑又暴露了-)
RabbitMQ 最初起用于在分布式系统中存储转发消息，具有易用性、扩展性、高可用性等，在金融行业都有很好的表现。
RabbitMQ特点是：
?可伸缩性：集群服务；
?消息持久化：从内存持久化消息到硬盘，再从硬盘加载到内存。
#RabbitMQ几个概念
Producer:生产者
投递消息的一方，就好比刚才提到的腌制鸡肉的大叔，生产者创建消息发布到RabbitMQ中。这其中会包含两个东西：消息体，比如字符串，带有逻辑结构的数据。另外一个就是标签用来描述这条消息。
Consumer:消费方
接受消息一方，就好比刚才提到的厨房处理鸡肉的员工，消费者连接到RabbitMQ服务器，并订阅到队列上。当消费者消费一条消息时，仅仅是消费消息的消息体。在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，消费者也只会消费到消息体。
Broker:服务节点
我们就理解为一台RabbitMQ的Server。
Queue:队列
存储消息的盒子或容器。
##Exchange:交换器
生产者将消息发送到交换器，交换器把消息通过路由的方式放到一个或多个队列中。
##RoutingKey:路由键
生产者将消息发送给交换器的时候，会指定一个路由键RoutingKey，指定消息的路由规则，路由键RoutingKey需要与交换器类型和绑定键（BindingKey）一起使用才可以。
##Connection:连接
生产者还是消费者和RabbitMQ Broker 会建立TCP连接，我们称作connection连接。
##Channel:信道
TCP 连接建立起来后，客户端会创建一个信道的东西，每个信道指定唯一的ID号 。信道是建立在Connection的一种虚拟连接， RabbitMQ 处理的指令由信道完成。
#RabbitMQ和其它不同之处
我也问过之前做大数据的同事，他们也仅仅是对Kakfa比较了解，他们感觉Kafka在吞吐量上要比RabbitMQ要好一些；在可用性上，Kafka支持主备切换，RabbitMQ支持miror队列；我也只是做了Kafka和RabbitMQ的对比，但是开源的消息队列远远不止这两个，时间有限也就没有细看，未来在进行研究和讨论。吞吐量较低的情况下，Kafka和RabbitMQ都可以。会选择Kafka好一些。