面试官：说说你对 RabbitMQ 的理解以及使用它的场景.docxVIP

面试官：说说你对 RabbitMQ 的理解以及使用它的场景 MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需公用连接来链接它们。 消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如近程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 RabbitMQ是使用Erlang言语开发的开源消息队列系统，基于AMQP协议来实现。AMQP的次要特征是面对消息、队列、路由(包括点对点和发布/订阅)、牢靠性、 平安。AMQP协议更多用在企业系统内，对数据全都性、稳定性和牢靠性要求很高的场景，对功能和吞吐量的要求还在其次。 二. RabbitMQ 使用场景 1. 解耦（为面对服务的架构（SOA）供应基本的最终全都性实现） 场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。 图片 传统模式的缺点： 假如库存系统无法访问，则订单减库存将失败，从而导致订单失败 订单系统与库存系统耦合 引入消息队列 图片 订单系统：用户下单后，订单系统完成长久化处理，将消息写入消息队列，前往用户订单下单成功 库存系统：订阅下单的消息，接受拉/推的方式，猎取下单信息，库存系统依据下单信息，进行库存操作 假如：在下单时库存系统不能正常使用。也不影响正常下单，由于下单后，订单系统写入消息队列就不再关怀其他的后续操作了。实现订单系统与库存系统的应用解耦 为了保证库存确定有，可以将队列大小设置成库存数量，或者接受其他方式处理。 基于消息的模型，关怀的是“通知”，而非“处理”。 短信、 邮件通知、缓存刷新等操作使用消息队列进行通知。 图片 消息队列和RPC的区分与比较： RPC: 异步调用，准时获得调用结果，具有强全都性结果，关怀业务调用处理结果。 消息队列：两次异步RPC调用，将调用内容在队列中进行转储，并选择合适的时机进行投递（错峰流控） 2. 异步提升效率 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种?1.串行的方式；2.并行方式 扩展： 异步并发利器：实际项目中使用CompletionService提升系统功能的一次实践 （1）串行方式：?将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，前往给客户端 图片 （2）并行方式：?将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，前往给客户端。与串行的差别是，并行的方式可以提高处理的时间 图片 引入消息队列，将不是必需的业务规律，异步处理。改造后的架构如下： 图片 3. 流量削峰 流量削峰也是消息队列中的常用场景，一般在秒宰或团抢活动中使用广泛 应用场景：?系统其他时间A系统每秒恳求量就100个，系统可以稳定运转。系统每天晚间八点有秒宰活动，每秒并发恳求量增至1万条，但是系统最大的处理力量只能每秒处理1000个恳求，于是系统崩溃，服务器宕机。 之前架构：?大量用户（100万用户）通过扫瞄器在晚上八点高峰期同时参与秒宰活动。大量的恳求涌入我们的系统中，高峰期达到每秒钟5000个恳求，大量的恳求打到MySQL上，每秒钟估计执行3000条SQL。但是一般的MySQL每秒钟扛住2000个恳求就不错了，假如达到3000个恳求的话可能MySQL直接就瘫痪了，从而系统无法被使用。但是高峰期过了之后，就成了低峰期，可能也就1万用户访问系统，每秒的恳求数量也就50个左右，整个系统几乎没有任何压力。 引入MQ：?100万用户在高峰期的时候，每秒恳求有5000个恳求左右，将这5000恳求写入MQ里面，系统A每秒最多只能处理2000恳求，由于MySQL每秒只能处理2000个恳求。系统A从MQ中渐渐拉取恳求，每秒就拉取2000个恳求，不要超过本人每秒能处理的恳求数量即可。MQ，每秒5000个恳求进来，结果只要2000个恳求出去，所以在秒宰期间（将近一小时）可能会有几十万或者几百万的恳求积压在MQ中。 关于流量削峰：秒宰系统流量削峰这事儿应当怎样做？ 这个短暂的高峰期积压是没问题的，由于高峰期过了之后，每秒就只要50个恳求进入MQ了，但是系统还是依据每秒2000个恳求的速度在处理，所以说，只需高峰期一过，系统就会快速将积压的消息消费掉。我们在此计算一下，每秒在MQ积压3000条消息，1分钟会积压18万，1小时积压1000万条消息，高峰期过后，1个多小时就可以将积压的1000万消息消费掉。 图片 三. 引入消息队列的优缺点 优点 优点就是以上的那些场景应用，就是在特殊场景下有其对应的好处，解耦、异步、削峰。 缺点 系统