RabbitMQ应用场景与实例

• Publisher：是Message的生产者，Publisher这个Clients产生了一些Message。
• Consumer：Message的消费者，Publisher产生的Message，最终要到达Consumer这个Clients，进行消费。
• Exchange： 指定消息按什么规则，路由到哪个Queue，Message消息先要到达Exchange，在Server中承担着从Produce接收Message的责任。
• Queue：到达Exchange的消息，根据制定的规则（Routing key）到达对应的Queue，在Server中承担着装载Message，是Message的容器，等待被消费出去。
• Routing key：在Exchange和Queue之间隐藏有一条黑线，可以将这条黑线看成是Routing key，Exchange就是根据这些定义好的Routing key将Message送到对应的Queue中去，是Exchange和Queue之间的桥梁。
• Broker：之前一直不理解这个Broker，其实Broker就是接收和分发消息的应用，也就是说RabbitMQ Server就是Message Broker。
• VirtualHost： 虚拟主机，一个Broker里可以开有多个VirtualHost，它的作用是用作不同用户的权限分离。
• Connection：是Publisher／Consumer和Broker之间的TCP连接。断开连接的操作只会在Publisher/Consumer端进行，Broker不会断开连接，除非出现网络故障或者Broker服务出现问题，Broker服务宕了。
• Connection: Channel:如果每一次访问RabbitMQ就建立一个Connection，那在消息量大的时候建立TCP Connection的开销就会很大，导致的后果就是效率低下。

左边的Client向右边的Client发送消息，流程：
       第一：获取Conection
       第二：获取Channel
       第三：定义Exchange，Queue
       第四：使用一个RoutingKey将Queue Binding到一个Exchange上
       第五：通过指定一个Exchange和一个RoutingKey来将消息发送到对应的Queue上，
       第六：Consumer在接收时也是获取connection，接着获取channel，然后指定一个Queue，到Queue上取消息，它对Exchange，RoutingKey及如何Binding都不关心，到对应的Queue上去取消息就行了。

应用场景

1、异步处理

场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种1.串行的方式;2.并行的方式
        (1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西.

        (2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。

         假设三个业务节点分别使用50ms,串行方式使用时间150ms,并行使用时间100ms。虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回. 

        (3)消息队列 ：引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理 

        由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。

2 应用解耦

        场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口.