RabbitMq

一为什么使用MQ？

使用MQ的场景很多，主要有三个：解耦、异步、削峰

• 解耦：A服务可以将消息放在MQ当中，其他的服务可以直接从MQ当中获取消息并进行处理即可，A服务和B服务没有实际的关联，提高了系统的灵活性和扩展性
• 异步：可以将一些非核心的流程，如日志，短信，右键等通过MQ的方式去异步处理，这样做的好处是缩短主流程的响应时间，提升用户的体验
• 削峰：MQ的本质就是业务排队，所以面对突然到来的高并发，现在MQ中排好队一个一个来。削峰的好处就是避免高并发压垮系统的关键组件（如某个核心的服务或者数据库等）

解耦场景：A系统发送数据到BCD三个系统，通过接口调用发送，如果E系统也要用这个数据呢？那如果C系统现在不需要用这个数据了呢？A系统负责人几乎崩溃…

如果使用MQ，A系统产生一条数据，发送到MQ里面去，如果那个系统需要数据自己去MQ里面取数据，A系统压根不需要考虑消息发给谁，不需要维护这个代码，也不需要考虑人家是调用成功，失败超时等情况

通过一个MQ，Pub/Sub发布订阅消息 这么一个模型，A系统就跟其他系统彻底解耦了
异步场景：A系统接受了一个请求，需要在自己本地写如数据库，还要在BCD三个系统写入数据库，自己本地需要3ms，BCD三个系统分别需要300ms，450ms，200ms，最终请求的总时延时953ms接近1s，用户体验极差，一般互谅网的企业，对于用户的直接操作，一般要求是每个请求必须在200ms以内完成，对用户几乎是无感知的

如果使用MQ，那么A系统连续发送3条消息到MQ队列当中，假如耗时5ms，A系统从接受一个请求到返回最终响应给用户总是尝试8ms，大大减少了响应时间

削峰场景：每天0:00到12:00，A系统风平浪静，每秒并发请求数量就50个，结果每次一道12:00-13:00美妙的并发请求就会突然暴增到5000个，但A服务最大的处理能力是2000个，所以当大量请求时服务器会垮掉
使用MQ，将5000个请求写入MQ，A系统慢慢从MQ中拉取请求，在自己的能力范围内处理请求就可以了，这样下来哪怕是高峰期，系统也可以正常使用，但是会有大量的请求积压在MQ当中（可能有上百个），但是短暂的高峰期挤压是ok的，因为高峰期过了之后，A系统就会很快地将积压的消息处理掉（高峰期过后，MQ每秒进入50个请求，但是A系统仍然会以2000个请求的速度去处理）