RabbitMQ简介&在分布式微服务中的使用场景_rabbitmq可以在分布式使用吗

1.MQ简介

MQ：Message Queen 消息队列

• FIFO先进先出队列，从入口进入，又出口取数据
• 先进后出队列（栈结构），从入口进入，又从入口取数据
• 双端队列：两头都可以存和取

java中的API，queen是基于内存级别的，一个微服务，即使创建出queen来保存消息，最多只能在它的机器中来使用。但是在分布式系统下，需要一个公共的中间件，能保存这些消息，也能将他们有序的取出来，A服务存进去，B服务来取，C服务存进去，D服务来取，而且他们用的队列还有很多各个还不一样。

在分布式业务场景中，需要消息中间件，中间件是安装在服务器中的，消息全部保存在服务器中，别的微服务可以从这一块来取消息。

2.消息中间件在分布式微服务中的使用场景

场景1 异步处理

用户注册为例

• 同步模式，1方法执行完，执行2方法，再执行3方法
• 异步模式，new Thread() start 开两个异步，发送短信和邮件，两个异步任务，只用等最长的那个时间
• 实际上异步也是不需要的，用户注册成功的消息，让后台慢慢发，成功与否，不需要知道，只要它做了通知就行，经常会有收不到消息的情况。如果我们注册信息写入数据库成功，将注册成功的消息放入消息队列（保存在消息中间件服务器中），假如存入1号用户注册成功，直接给用户返回，给消息中间件写入消息的耗时非常短5ms，数据库插入数据持久化可能很慢，需要50ms，写消息像直接操作redis一样。消息既然存入了消息队列，那么别的服务就可以从消息队列服务器中拿到消息（拿到1号注册成功的消息，由后台去发短息、发邮件，不管他什么时候发），这可以提升异步处理能力，比以前异步更快，异步需要等待返回，消息队列，只用向队列中存入消息，发送消息由后台慢慢做

场景2 应用解耦

• 下订单为例，下完订单，库存要进行出库操作，以前：下完订单，调用库存系统，减库存。下订单API3个参数，减库存API5个参数，假如库存系统不升级，API参数5不变还好，假如库存系统经常升级，减库存的接口参数经常发生变化。以前的方法，库存系统升级，订单系统就必须来修改源代码，重新部署，会很麻烦
• 将用户下订单消息放到消息队列，不用关心库存系统的接口怎么样，要5个参数还是8个参数，只需要将消息写入消息队列，库存系统订阅消息队列，只要有内容，库存系统就会收到这个消息，然后分析这个消息，都有哪个用户下了订单，自己去减库存
• 订单系统不用关心别的系统接口设计怎么样，因为我们根本就不调用别的系统只用订阅消息队列就可以，

场景3 流量控制（流量削峰）

• 秒杀业务，瞬间业务流量非常大，瞬间100个请求都要进来秒杀一个商品，秒杀完要下订单，整个流程会非常慢，后台会一直阻塞，可能会导致资源耗尽，机器宕机
• 我们要怎么做，将大并发的请求，存放到消息队列里面，我们就不用管怎么处理，直接给用户响应秒杀结果，后台下订单、减库业务订阅消息队列，后台下订单、减库存不着急马上调用消息队列处理，接下来，挨个处理下订单，不管后台处理能力如何，1秒一个，花100万秒就好，但永远都不会导致资源耗尽机器宕机。将请求存入消息队列，后台根据自己的能力去消费。