消息中间件MQ 入门概述

• 这篇笔记，主要是基于尚硅谷的ActiveMQ课程，以及这位大佬的笔记。
• 本人初学，在一边学的基础上，一边加上自己的理解写一些笔记，如果有写得不好的地方，请多担待。

1. 背景

• 在微服务的背景下，项目被拆分成多个模块，模块之间可能需要互相调用。因此，RPC框架（远程调用框架）就应运而生。

1.1 RPC框架的问题

• 然而，在大型的分布式系统中，系统间的RPC交互繁杂，一个功能背后可能有上百个接口，就此就会产生一些问题

1.1.1 系统之间的接口耦合比较严重

• 在使用Dubbo的时候，一个模块A调用另一个模块B的时候，A往往都需要在自己的代码上加上B的接口文件。这导致每次增加新需求的时候，都需要对自己的代码进行改造，开发联调效率很低。

1.1.2 面对大流量并发时，容易被冲垮

1.1.3 等待同步存在性能问题

• 我觉得这两点是一起的，如果多个耦合在一起，整体系统的处理速度取决于最慢的那个系统。处理速度快的系统也容易因为处理速度慢的系统影响性能。面对高并发的情况下，流量的能力明显减弱。
  

1.2 MQ

• 而利用MQ很好地解决了这个问题。

1.2.1 异步

• 调用者无需等待，发送完消息给MQ，就可以撤退，去继续完成自己的业务。

1.2.2 解耦

• 两个系统之间不再是直接耦合在一起，而是中间多了一层消息中间件，实现了解耦

1.2.3 削峰

• 在处理大流量高并发业务的时候，主系统可以直接将大量的请求发给中间件，中间件可以做一个缓冲层，使得即使后面的系统处理速度跟不上，也不至于主系统崩溃。保护了主系统。

2. MQ定义

• 面向消息的中间件（message-oriented middleware）MOM能够很好的解决以上问题。是指利用高效可靠的消息传递机制与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型在分布式环境下提供应用解耦，弹性伸缩，冗余存储、流量削峰，异步通信，数据同步等功能。

2.1 过程

• 发送者将消息发送给消息服务器
• 消息服务器将消息存放在若干个队列Queue/主题Topic中。
• 接受者在合适的时候接受消息
• 此过程，发送者和接受者是异步的。

2.2 特点

2.2.1 采用异步处理模式

• 消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道（主题或者队列）上；
• 消息接收者则订阅或者监听该通道。一条消息可能最终转发给一个或者多个消息接收者，这些消息接收者都无需对消息发送者做出同步回应。整个过程都是异步的。

2.2.2 应用系统之间解耦合

• 发送者和接受者不必了解对方，只需要确认消息。
• 发送者和接受者不必同时在线。

2.2.3 整体架构

2.2.4 MQ的缺点

• 不能同步调用，不能实时回复，不能响应某个调用的回复。