消息中间件 —— 简介

什么是消息中间件？

上面提到过消息中间件，那么什么是消息中间件呢？

    消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行 分布式系统 的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信

消息中间件引出产生背景

一、系统之间接口耦合比较严重

系统之间直接调用实际工程落地和存在问题

    微服务架构后，链式调用是我们在写程序时候的一般流程，为了完成一个整体功能会将其拆分成多个函数（或子模块），比如模块 A 调用模块 B，模块 B 调用模块 C，模块 C 调用模块 D。但在大型分布式应用中，系统间的 RPC 交互繁杂，一个功能背后要调用上百个接口并非不可能，从单机架构过渡到分布式服务架构的通例，这种架构会有哪些问题？

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

每新增一个下游功能，都要对上有相关接口进行改造；

举个例子：假如系统 A 要发送数据给系统 B 和 C，发送给每个系统的数据可能有差异，因此系统 A 对要发送给每个系统的数据进行了组装，然后逐一发送；

当代码上线后又新增了一个需求：

把数据也发送给 D，新上了一个 D 系统也要接受 A 系统的数据，此时需要修改 A 系统，让它感知到 D 的存在，同时把数据处理好 A 再给 D。在这个过程中你会发现，每接入一个下游系统，都要对 A 系统进行代码改造，开发联调的效率很低。其整体架构如下图

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

每个接口模块的吞吐量能力是有限的，这个上限能力如果堤坝，当大流量（洪水）来临时，容易被冲垮

举个例子秒杀业务：

上游系统发起下单购买操作，就是下单一个操作

下游系统完成秒杀业务逻辑
（读取订单、库存检查、库存冻结、余额检查、余额冻结、订单生成、余额扣减、库存扣减、生成流水、余额解冻、库存解冻）

三、等待同步存在性能问题

RPC 接口基本上是 同步调用，整体服务性能遵循 “木桶理论”，即 整体系统的耗时取决于链路中 最慢的 那个接口

比如 A 调用 B/C/D 都是 50ms，但此时 B 又调用了 B1，花费 2000 ms，那么直接就拖累了整个服务性能

如何解决？

• 要做到系统解耦，当新的模块接进来时，可以做到代码改动最小；能够解耦
• 设置流量缓冲池，可以让后端系统按照自身吞吐能力进行消费，不被冲垮；能够削峰
• 强弱依赖梳理能将非关键调用链路的操作异步化并提升整体系统的吞吐能力；能够异步

消息中间件的定义

面向消息的中间件（Message-Oriented Middleware）MOM 能够很好的解决以上问题

    是指利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供 消息传递 和 消息排队 模型在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等功能

大致的过程是这样的：

    发送者把消息发送给消息服务器，消息服务器将消息存放在若干个 队列 / 主题 中，在合适的时候，消息服务器会将消息转发给接收者。在这个过程中，发送和接收是异步的，也就是发送无需等待，而且发送者和接收者的生命周期也没有必然关系；尤其在发布 pub / 订阅 sub 模式下，也可以完成一对多的通信，即让一个消息有多个接收者

特点

采用异步处理模式

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

案例：
    也就是说，一个系统跟另一个系统之间进行通信的时候，假如系统 A 希望发送一个消息给系统 B，让它去处理
    但是系统 A 不关注系统 B 到底怎么处理或者有没有处理好，所以系统 A 把消息发送给 MQ，然后就不管这条消息了，接着系统 B 从 MQ 里消费出来处理即可。至于怎么处理，是否处理完毕，什么时候处理，都是系统 B 的事，与系统 A 无关

    这样的一种通信方式，就是所谓的 “异步” 通信方式对于系统 A 来说，只要把消息发送给 MQ，然后系统 B 就会异步的去进行处理了，系统 A 不需要 “同步” 的等待系统 B 处理完。这样的好处是什么呢？两个字：解耦

应用系统之间解耦合

常用的消息中间件有哪些？

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	等同 ActiveMQ	10 万级，支持高吞吐量	10 万级，高吞吐量，一般配合大数据类的系统进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百 / 几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	毫秒级	微秒级，这是 RabbitMQ 的一大特点，延迟最低	毫秒级	延迟在毫秒级以内
可用性	高，基于主从架构实现高可用	等同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率会丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	等同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 Erlang 开发，并发能力很强，性能极好，延时较低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用