我为什么要选用RabbitMQ 各种MQ选型对比 RabbitMQ简介

前言：

是什么？队列是什么，咱们可以了解为信息队列，队列咱们可以了解为管道。以管道的方式做信息传递。

场景：

1.其实咱们在双11的时刻，当咱们清晨少量的秒杀和抢购商品，而后去结算的时刻，就会发现，界面会提示咱们，让咱们稍等，以及一些友好的图片文字提示。而不是像前几年的时代，动不动就页面卡死，报错等来出现给用户。

在这业务场景中，咱们就可以驳回队列的机制来处置，由于同时结算就只能到达这么多。

2.在咱们往常的超市中购物也是一样，当咱们在结算的时刻，并不会一窝蜂一样涌入收银台，而是排队结算。这也是队列机制。

对，就是排队。一个接着一个的处置，不能插队。

RabbitMQ简介

AMQP，即Advanced Message Queuing Protocol，初级信息队列协定，是运行层协定的一个开通规范，为面向信息的两边件设计。信息两边件关键用于组件之间的解耦，信息的发送者无需知道信息经常使用者的存在，反之亦然。AMQP的关键特色是面向信息、队列、路由（包含点对点和颁布/订阅）、牢靠性、安保。RabbitMQ是一个开源的AMQP成功，主机端用Erlang言语编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在散布式系统中存储转发信息，在易用性、裁减性、高可用性等方面体现不俗。上方将重点引见RabbitMQ中的一些基础概念，了解了这些概念，是经常使用好RabbitMQ的基础。

ConnectionFactory、Connection、Channel

ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的socket链接，它封装了socket协定关系局部逻辑。ConnectionFactory为Connection的制造工厂。Channel是咱们与RabbitMQ打交道的最关键的一个接口，咱们大局部的业务操作是在Channel这个接口中成功的，包含定义Queue、定义Exchange、绑定Queue与Exchange、颁布信息等。

Queue（队列）是RabbitMQ的外部对象，用于存储信息，用下图示意。

RabbitMQ中的信息都只能存储在Queue中，消费者（下图中的P）消费信息并最终投递到Queue中，消费者（下图中的C）可以从Queue中失掉信息并消费。

多个消费者可以订阅同一个Queue，这时Queue中的信息会被平均摊派给多个消费者启动处置，而不是每个消费者都收到一切的信息并处置。

Message acknowledgment

在实践运行中，或许会出现消费者收到Queue中的信息，但没有处置成功就宕机（或出现其余异常）的状况，这种状况下就或许会造成信息失落。为了防止这种状况出现，咱们可以要求消费者在消费完信息后发送一个回执给RabbitMQ，RabbitMQ收到信息回执（Messageacknowledgment）后才将该信息从Queue中移除；假设RabbitMQ没有收到回执并检测到消费者的RabbitMQ衔接断开，则RabbitMQ会将该信息发送给其余消费者（假设存在多个消费者）启动处置。这里不存在timeout概念，一个消费者处置信息期间再长也不会造成该信息被发送给其余消费者，除非它的RabbitMQ衔接断开。这里会发生另外一个疑问，假设咱们的开发人员在处置完业务逻辑后，遗记发送回执给RabbitMQ，这将会造成重大的bug——Queue中沉积的信息会越来越多；消费者重启后会重复消费这些信息偏重复口头业务逻辑…

另外pub message是没有ack的。

Message durability

假设咱们宿愿即使在RabbitMQ服务重启的状况下，也不会失落信息，咱们可以将Queue与Message都设置为可耐久化的（durable），这样可以保障绝大局部状况下咱们的RabbitMQ信息不会失落。但依然处置不了小概率失落事情的出现（比如RabbitMQ主机曾经接纳到消费者的信息，但还没来得及耐久化该信息时RabbitMQ主机就断电了），假设咱们须要对这种小概率事情也要治理起来，那么咱们要用到事务。由于这里仅为RabbitMQ的便捷引见，所以这里将不解说RabbitMQ关系的事务。

Prefetch count

前面咱们讲到假设有多个消费者同时订阅同一个Queue中的信息，Queue中的信息会被平摊给多个消费者。这时假设每个信息的处置期间不同，就有或许会造成某些消费者不时在忙，而另外一些消费者很快就处置完手头上班并不时闲暇的状况。咱们可以经过设置prefetchCount来限度Queue每次发送给每个消费者的信息数，比如咱们设置prefetchCount=1，则Queue每次给每个消费者发送一条信息；消费者处置完这条信息后Queue会再给该消费者发送一条信息。

在上一节咱们看到消费者将信息投递到Queue中，实践上这在RabbitMQ中这种事情永远都不会出现。实践的状况是，消费者将信息发送到Exchange（替换器，下图中的X），由Exchange将信息路由到一个或多个Queue中（或许摈弃）。

Exchange是依照什么逻辑将信息路由到Queue的？这个将在Binding一节引见。RabbitMQ中的Exchange有四种类型，不同的类型有着不同的路由战略，这将在Exchange Types一节引见。

routing key

消费者在将信息发送给Exchange的时刻，普通会指定一个routing key，来指定这个信息的路由规定，而这个routing key须要与Exchange Type及binding key联结经常使用能力最终失效。在Exchange Type与binding key固定的状况下（在反经常常使用时普通这些内容都是固定性能好的），咱们的消费者就可以在发送信息给Exchange时，经过指定routing key来选择信息流向哪里。RabbitMQ为routing key设定的长度限度为255 bytes。

RabbitMQ中经过Binding将Exchange与Queue关联起来，这样RabbitMQ就知道如何正确地将信息路由到指定的Queue了。

Binding key

在绑定（Binding）Exchange与Queue的同时，普通会指定一个bindingkey；消费者将信息发送给Exchange时，普通会指定一个routing key；当binding key与routingkey相婚配时，信息将会被路由到对应的Queue中。这个将在Exchange Types章节会罗列实践的例子加以说明。在绑定多个Queue到同一个Exchange的时刻，这些Binding准许经常使用相反的binding key。binding key 并不是在一切状况下都失效，它依赖于Exchange Type，比如fanout类型的Exchange就会忽视binding key，而是将信息路由到一切绑定到该Exchange的Queue。

Exchange Types

RabbitMQ罕用的Exchange Type有fanout、direct、topic、headers这四种（AMQP规范里还提到两种Exchange Type，区分为system与自定义，这里不予以形容），上方区分启动引见。

fanout类型的Exchange路由规定十分便捷，它会把一切发送到该Exchange的信息路由到一切与它绑定的Queue中。

上图中，消费者（P）发送到Exchange（X）的一切信息都会路由到图中的两个Queue，并最终被两个消费者（C1与C2）消费。

direct类型的Exchange路由规定也很便捷，它会把信息路由到那些binding key与routing key齐全婚配的Queue中。

以上图的性能为例，咱们以routingKey=”error”发送信息到Exchange，则信息会路由到Queue1（amqp.gen-S9b…，这是由RabbitMQ智能生成的Queue称号）和Queue2（amqp.gen-Agl…）；假设咱们以routingKey=”info”或routingKey=”warning”来发送信息，则信息只会路由到Queue2。假设咱们以其余routingKey发送信息，则信息不会路由到这两个Queue中。

前面讲到direct类型的Exchange路由规定是齐全婚配binding key与routingkey，但这种严厉的婚配方式在很多状况下不能满足实践业务需求。topic类型的Exchange在婚配规定上启动了裁减，它与direct类型的Exchage相似，也是将信息路由到bindingkey与routing key相婚配的Queue中，但这里的婚配规定有些不同，它商定：

以上图中的性能为例，routingKey=”quick.orange.rabbit”的信息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的信息会路由到Q1与Q2，routingKey=”lazy.brown.fox”的信息会路由到Q2，routingKey=”lazy.pink.rabbit”的信息会路由到Q2（只会投递给Q2一次性，只管这个routingKey与Q2的两个bindingKey都婚配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的信息将会被摈弃，由于它们没有婚配任何bindingKey。

headers类型的Exchange不依赖于routing key与binding key的婚配规定去路由信息，而是依据发送的信息内容中的headers属性启动婚配。在绑定Queue与Exchange时指定一组键值对；当信息发送到Exchange时，RabbitMQ会取到该信息的headers（也是一个键值对的方式），对比其中的键值对能否齐全婚配Queue与Exchange绑定时指定的键值对；假设齐全婚配则信息会路由到该Queue，否则不会路由到该Queue。该类型的Exchange没有用到过（不过也应该很有用武之地），所以不做引见。

MQ自身是基于异步的信息处置，前面的示例中一切的消费者（P）将信息发送到RabbitMQ后不会知道消费者（C）处置成功或许失败（甚至连有没有消费者来处置这条信息都不知道）。但实践的运行场景中，咱们很或许须要一些同步处置，须要同步期待服务端将我的信息处置成功后再启动下一步处置。这相当于RPC（Remote Procedure Call，远程环节调用）。在RabbitMQ中也支持RPC。

中成功的机制是：

总结

本文引见了中团体以为最关键的概念，充沛应用提供的这些性能就可以处置咱们绝大局部的异步业务了。

RabbitMQ 选型和对比

1.从社区生动度

依照目前网络上的资料，、、三者中，综合来看，是首选。

不支持，和都支持。耐久化信息关键是指咱们机器在无法抗力要素等状况下挂掉了，信息不会失落的机制。

3.综合技术成功

牢靠性、灵敏的路由、集群、事务、高可用的队列、信息排序、疑问追踪、可视化治理工具、插件系统等等。

/最好，次之，最差。当然也可以做到，不过自己必定手动写代码成功，代码量不小。尤其是牢靠性中的：耐久性、投递确认、颁布者证明和高可用性。

无须置疑，最高，要素是它的成功言语是天生具有高并发高可用的言语。

比成熟，在可用性上，稳固性上，牢靠性上，胜于（实践上）。

另外，的定位关键在日志等方面，由于设计的初衷就是处置日志的，可以看做是一个日志（信息）系对抗个关键组件，针对性很强，所以假设业务方面还是倡导选用。

还有就是，的性能（吞吐量、）比要高出来很多。

假设咱们系统中曾经有选用，或许

，并且齐全可以满足如今的业务，倡导就不用重复去参与和造轮子。

可以在和当选用一个适宜自己团队和业务的，这个才是最关键的。然而无须置疑现阶段，综合思考没有第三选用。

假设本文对你有协助，那么请你资助我，让我更有热情的写下去，协助更多的人。