#说在前面
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好一些。