RabbitMQ

消息队列使用场景：

比如我在淘宝点击下单，中间包含的业务逻辑可能有生成对应订单，扣减库存，支付宝扣款，通知卖家，更新销量，通知买家确认订单等操作。当中有些不需要立即生效的操作可以单独提炼出来，比如更新销量，通知买家确认订单。这种场景就可以使用消息队列，在下单主流程之后，将订单确认发送给MQ ,另外的线程拉取MQ中的消息，发送给买家。

所有的MQ都是执行生产者消费者模式，生产者发布消息到某个队列，消费者订阅某个队列，队列将消息通知给消费者。

RabbitMQ由以下几个部分组成，

1.message，消息：存放在队列中的消息。

2.publisher,消息的生产者，也就向一个交换器发布消息的客户端应用程序。

3.exchange，交换器,接收生产者发来的消息并路由给消费者

4.binding，绑定,用于关联交换器和队列，一个绑定就是基于路由键将交换器和消息队列关联起来的路由规则

5.queue,消息队列，消息的容器，一个消息可存放于多个队列，消息一直在队列里面，等待消费者取走。

6.connection,网络连接，比如一个tcp网络连接

7.channel，信道，信道是建立在真实tcp连接内的虚拟连接，无论是发布消息，订阅队列还是接受消息，这些都是通过信道完成。由于TCP的创建和销毁都是昂贵的开销，故而复用该tcp连接。这点类似于netty，每条IO都开辟一条线程去处理，过于耗费资源，故而我们通过一个线程记录IO流的状态来同时管理多条IO。

8.consumer，消费者，从一个消息队列取得消息的客户端应用程序。

9.virtual host,虚拟主机，每个vhost本质上是一个迷你版的rabbitmq，拥有自己的队列，交换器，绑定，权限机制。rabbitMQ默认的vhost是/

10.broker，表示消息队列服务器实体。

其实像生产者消费者模式很多地方都用到了，比如阻塞队列，消费者线程向队列里取数据，生产者线程向队列里加数据。

如果MQ仅仅是这样功能是不够强大的。MQ的重点是消息队列有多个，统一有交换器管理负责，什么消息发送到什么队列当中。

exchange的路由策略有以下四种

1.direct,如果消息的路由键和binding中的binding key完全匹配，就将消息发到对应的队列当中。

2.fanout,每个发到交换器的数据都会发到所有与交换器绑定的队列当中去。

3.topic，消息的路由键和某个模式进行匹配