RabbitMQ应用场景

    在大多数应用中，可通过消息服务中间件来提升系统异步通信，扩展解耦能力。比如，异步处理：以用户注册为例：首先将用户的注册信息写入数据库，然后给用户发送邮件，并且发一封短信。第一种方法：按照以前的同步方式，写入数据库调发邮件方法，发完邮件调发短信方法，每个需要50毫秒，算上写入数据库，就需要150毫秒，也就是150毫秒之后响应用户请求，这样就很慢了。我们可以用第二种方法：写入数据库之后，采用多线程的方式，同时发送邮件和发送短信，这样只需要100毫秒就行。这样也还是太慢了。我们思考第三种方法：消息队列模式，当用户将注册信息写进数据库之后，给中间件（消息队列）发送一个消息，只要写入消息队列，就立即响应用户。如果写入消息队列只需要5毫秒的话，这样就只需要55毫秒用户就能获得响应，远远比第一第二种方法节省很多时间。待消息写入队列之后，发邮件和发短信采用异步读取消息并处理消息的方式，自己去后台处理消息就行了。

场景二：应用解耦：

          比如现在，有订单系统和库存系统，用户下了一个订单，如果这两个系统在一个服务中，每个订单都去调用库存系统，会瞬间积压大量的互相调用和连接数，很容易造成服务挂掉或卡死。那么，如果引入消息队列就很方便了。用户下完订单之后，然后给消息队列发送一个消息，然后库存系统去消息队列读取并处理消息，不用等库存系统处理完就响应用户，这样就变得快多了。（备注，后面会介绍边界情况，比如，对库存系统校验某一个商品还有没有等等）。

场景三：流量x削峰：

            我们常见的秒杀，如果瞬间有100万个用户请求，给消息列表设置定长，比如设置10万个请求。就看哪10万个请求先进入消息队列，后面90万个请求进入消息队列之后，立即驳回，告诉用户秒杀失败。10万个最先进入队列的响应用户，秒杀成功。后台业务处理系统，就只需要读取并处理这10万个请求。这样就完美的实现了秒杀的需求。