消息中间件介绍(中间件,两种消息模型),分布式系统为什么需要

中间件

帮助 $应用程序$ 与 $其他应用程序/网络/硬件/操作系统$ 交互或通信的软件

也就是将具体业务和底层逻辑解耦的软件

应用程序只需通过中间件提供的接口进行操作,不需要关心如何实现底层的网络协议、数据存储、事务管理等,具体的访问细节由中间件去补足

中间件包含多种类型 -- 数据库中间件 / 消息中间件 / Web中间件(Tomcat,Nginx)

消息中间件

消息中间件指的是一种支持消息传递 的中间件技术，它允许应用程序通过异步的、可靠的消息传递在不同的计算平台和操作系统之间交换数据

消息中间件支持 点对点 （P2P）和 发布/订阅（Pub/Sub）两种通信模式，并能够确保消息的可靠性、顺序和事务性

当下主流的消息中间件有RabbitMQ、Kafka、ActiveMQ、RocketMQ等

是分布式系统中非常重要的组件，主要用来解决应用耦合、异步通信、流量削峰等问题

点对点（P2P）模型

一个生产者发送消息到一个队列，单个消费者从队列中取出并处理消息

消息队列是点对点模式的主要实现形式，生产者与消费者之间通过消息队列解耦，不直接通信，而是通过消息队列进行异步传递

常见实现：RabbitMQ、ActiveMQ、IBM MQ等，支持P2P模式

发布/订阅（Pub/Sub）模型

一个发布者发布消息到一个主题，多个订阅者可以接收这些消息

同一条消息可以被多个消费者（订阅者）同时处理

常见实现：Apache Kafka、RabbitMQ（支持主题的发布/订阅模式）、Google Pub/Sub等

消息队列

消息队列（Message Queue, MQ）是一种数据结构，用于存储消息并按顺序传递消息

在实际开发中，"MQ" 广泛用来代指各种基于消息传递机制的中间件系统

为什么分布式系统需要

为什么分布式系统需要消息中间件？不能用 HTTP/RPC/数据库/共享内存来实现吗？

其他方式可以做通信，但消息中间件能把分布式系统做到更稳、更松耦合、更可扩展
下面先说明一下,为什么其他方式不行

HTTP / RPC 直连通信

介绍

HTTP/RPC 是同步请求---响应的交互模型：Client向Server发起请求并等待响应，调用线程/任务通常会被阻塞直到响应或超时

直连是两端紧紧绑在一起,上游必须等下游

缺点

强耦合

A依赖B,A 必须知道 B 的地址、接口、版本、可用性

若 B 的接口变动或 B 下线,那么A也必须改变

同步阻塞

同步请求会占用A的线程/连接资源

如果 B 处理较慢或网络延迟高，A 的线程池很快被占满(每个请求对应一个线程)

产生级联故障

如果在链式调用A→B→C中,下游卡顿会放大问题,并波及上游

故障传播快

同步依赖使得下游的故障立即影响到上游的业务可用性

数据库轮询

介绍

用数据库表作为"消息总线" -- 生产者向表写记录，消费者定时查询（轮询）表并处理未处理记录

缺点

延迟高

轮询间隔决定了最小可见延时

要实时就需要短间隔轮询，造成高负载；要省资源就必须容忍更长延迟

DB 成为瓶颈

大量轮询请求会加重 DB 负担并影响主业务（可能使事务响应变慢）

竞争 & 顺序问题

多个消费者并发轮询要防止重复处理/抢占（需要锁、行级 update、标记机制），这些操作会涉及到事务与锁竞争，进一步降吞吐

可扩展性差

数据库并不是为消息高并发读写设计（尤其是大并发写+读的模式）

共享内存 / 本地文件

介绍

使用操作系统提供的共享内存、管道、消息队列（POSIX IPC）、或本地文件系统来传递消息

缺点

只限单机

跨机器无法直接共享内存或本地文件

扩展性差

要横向扩展（多台机器）必须引入分布式协调/同步机制，反而比直接用专门的消息系统更难实现

管理复杂性

内存/文件并发访问要做同步（锁、信号量），容易出错

于是,下面来说说,为什么分布式系统需要消息队列

消息中间件

加入MQ后,结构变成了 A -> MQ -> B

它解决了分布式中的 3 个根本矛盾

解耦

A 完成自己的任务，把消息放到队列里就结束

A不需要关心消费者是否在线,新增/减少也不会影响A

异步

A发送消息后,可以立即返回,B可以在自己的节奏下处理消息

削峰

在高并发情况下，消息队列可以作为一个缓冲区，将请求暂时存储在队列中，不会立即推送到下游服务

这样即使在高峰期，系统也不会因为瞬时大量请求而卡死或崩溃