消息队列中间件
消息队列就是Message Queue，本质就是一个保存消息的队列。
如下图所示：
图片
消息队列通常由一个中间件组件提供，它作为消息的中转站，负责接收、存储和转发消息。发送者将消息发送到消息队列中，接收者则从队列中获取消息进行处理。
消息中间件应用场景
消息队列的应用场景，主要包含：异步、解耦、削峰等，如下图所示：
图片
1.异步通信
发送方和接收方不需要直接进行实时的通信，而是通过消息队列中间件进行异步的消息传递
2.解耦和解偶
消息队列可以将发送方和接收方解耦，使得它们可以独立地进行开发、部署和维护
图片
3.削峰填谷
消息队列可以缓冲和平衡消息的流量，当发送方发送大量的消息时，消息队列可以将消息暂存起来，并按照接收方的处理能力逐渐进行消费。
4.可靠性和持久化
消息队列通常具有可靠的消息传递机制，可以确保消息在发送和接收过程中的可靠性。
一些消息队列还支持消息的持久化，即将消息存储到持久化存储介质中，以防止消息丢失。
消息队列原理
消息队列中间件的原理，如下图所示：
图片
主要会包含：生产者、Broker、消费者...等。
1.生产者
生产者，主要负责发送消息，生产者将消息发送到消息队列。
生产者根据业务逻辑生成消息，这些消息包含各种数据，例如：用户请求、系统事件、日志记录...等。
消费的类型：消息可以是文本、JSON、XML、或其他格式的......数据。
2.消息存储(Broker)
Broker：主要负责接收、存储和转发消息，通常具有持久化机制，确保消息不丢失。
Broker还将消息分发给合适的消费者，可以通过轮询、负载均衡...等方式进行调度。
以及，Broker需要等待消费者确认消息已被成功处理，然后才会将该消息从队列中移除，确保消息不被丢失。
3.消费者接收消息
消费者是消息的接收者和处理者，它从消息队列中读取消息，并执行相应的业务逻辑。
消费者从Broker中读取消息，可以是主动拉取（Pull）、或被动推送（Push）模式。
处理完成后，消费者需要向Broker发送确认信息，通知Broker该消息已被成功处理。
如果没有确认，消息可以重新投递，确保处理的可靠性。
消息队列类型
消息队列主要包含两种：一个是点对点，一个是发布订阅模型。
1.点对点
图片
点对点的特点：每个消息只有一个消费者（Consumer），即一旦被消费，消息就不再在消息队列中。
2.发布订阅
发布订阅模型包含三个角色：主题（Topic）、发布者（Publisher）、订阅者（Subscriber）。
如下图所示：
图片
消息协议
消息协议是消息队列中间件的重要组成部分，决定了消息的格式、传输方式、和通信规则。
1.JMS
Java Message Service（JMS）是Java平台上用于消息通信的标准API，提供了一种通用的方式来创建、发送、接收和读取消息。
比如：老牌的ActiveMQ，就是典型的JMS实现。
2.AMQP
AMQP，全程是“Advanced Message Queuing Protocol”，是一种开放标准的应用层协议。
特点是：
- AMQP协议设计为与平台无关，支持多种编程语言；
- 通过交换机（Exchange），实现复杂的消息路由机制，包括：直接交换（Direct）、主题交换（Topic）...等。
- 支持消息确认、持久化、事务、死信队列...等功能，确保消息的可靠传递和处理。
rabbitmq，就是典型的AMQP的实现。
3.MQTT
Message Queuing Telemetry Transport（MQTT），是一种轻量级的发布/订阅消息协议，设计用于低带宽、高延迟、或不可靠的网络环境。
消息队列有哪些
常见的消息队列有：ActiveMQ、RocketMQ、Kafka、Pulsar、RabbitMQ等等。
如下图所示：
图片
- RabbitMQ：RabbitMQ是一个开源的消息队列系统，它实现了AMQP（Advanced Message Queuing Protocol）协议，并提供了丰富的功能，如消息持久化、消息确认、灵活的路由和绑定等。
- Apache Kafka：Apache Kafka是一个分布式的流式平台，它可以处理大规模的实时数据流。Kafka基于发布-订阅模型，具有高吞吐量和持久性，适用于处理大量实时数据的场景。
- ActiveMQ：ActiveMQ是Apache基金会的一个开源消息中间件，支持JMS（Java Message Service）规范。它提供了多种通信模式，如点对点（P2P）和发布-订阅（Pub/Sub），并具有可靠性、可扩展性和高可用性。
- Redis：Redis是一个内存数据库，但也可以用作消息队列。Redis提供了List、Pub/Sub等数据结构和命令，可以实现简单的消息队列功能。
- Apache Pulsar：Apache Pulsar是一个开源的分布式消息和流处理平台，具有高性能、可扩展性和持久化特性。Pulsar支持多租户、多数据中心部署和动态扩展，适用于大规模和复杂的消息队列和流处理场景。
选型比较
ActiveMQ | JMS，多协议支持 | 成熟稳定，功能丰富，多语言支持 | 性能有限，管理复杂 | 中小规模企业应用，需要JMS功能支持的场景 |
RocketMQ | 高性能，强事务消息，分布式架构 | 高吞吐量低延迟，分布式，强一致性 | 社区支持少，运维复杂 | 互联网和金融系统，高吞吐量和严格一致性场景 |
Kafka | 高吞吐量，日志式存储，分区和复制 | 高性能，可扩展，生态系统丰富 | 延迟较高，不支持事务消息 | 大数据处理，实时流处理，需要高吞吐和扩展性场景 |
Pulsar | 多租户，分层架构，原生流处理 | 高性能，持久化存储，灵活扩展 | 学习曲线陡，社区和生态系统较小 | 云环境和企业系统，多租户和高性能消息传递场 |
RabbitMQ | 基于AMQP，灵活路由，丰富插件 | 易于使用，功能丰富，多语言支持 | 性能有限，集群管理复杂 | 中小规模企业应用，复杂路由和消息确认场景 |
总的来说
互联网和金融系统，高吞吐量和严格一致性场景，可以选择：RocketMQ;
中小规模企业应用，复杂路由、和消息确认场景，可以选择：RabbitMQ;
大数据处理，实时流处理，需要高吞吐、和扩展性场景，可以选择Kafka。
