近几年来，消息中间件发展迅速，导致在业务开发中可能不需要也要使用一下，一方面是为了学习和熟悉一种消息中间件技术为自己后续的职业生涯增添一份溢彩，另一方面可以让自己的业务系统得到架构层面上的扩充，有时候有益于系统架构，有时候可能会适得其反，没有起到明显的效果，反而会导致后续的运维变得很复杂，增加排查问题的复杂度。
面试了一些求职者，简历上罗列了不少中间件技术，有的写一种，有的写好几种，也能说出一些具体在哪个业务环节使用到。但是从业务系统的性质上去判断，总感觉大多数为了使用去使用，有的时候就是杀鸡焉用牛刀的感觉。下面列举一些开源的大家使用比较多的消息中间件做一介绍。
一、Apache RocketMQ
厂家：阿里出品，现在属于Apache基金会
简介：一个开源的分布式消息队列系统，具有低延迟、高可用性和可伸缩性
特点：高吞吐量的消息传递、分布式系统的异步通信、顺序消息处理
消息机制：通过持久化消息、消息确认和消费进度管理来确保消息的可靠性和至少一次消费。消息可以被持久化到磁盘，并且消费者可以发送消息确认。RocketMQ 会记录消费者的消费进度，并在发生故障后重新投递未确认的消息。
优点：低延迟、高可用性和可伸缩性，支持分布式部署和大规模消息传递。
缺点：相对较复杂，需要额外的配置和管理。
二、RabbitMQ
厂家：Rabbit Technologies Ltd
简介：一个开源的、高度可靠的消息代理和队列系统，支持多种消息协议。
特点：一个基于Java的开源消息中间件，支持多种传输协议和消息模式
消息机制：通过持久化消息和消息确认机制来确保消息的可靠性。消息可以被持久化到磁盘，以防止在发生故障时丢失。消费者可以发送消息确认（acknowledgment），告知 RabbitMQ 消息已经被正确处理。如果消费者在处理消息后发生故障，RabbitMQ 可以将未确认的消息重新投递给其他消费者。
优点：可靠性高，支持多种消息协议，具有灵活的路由和消息确认机制。
缺点：性能相对较低，特别是在高负载情况下。
三、Apache ActiveMQ
厂家：Apache 软件基金会
简介：一个基于Java的开源消息中间件，支持多种传输协议和消息模式。
特点：需要广泛的消息协议支持、企业应用程序集成、点对点和发布/订阅模式的消息通信
消息机制：通过持久化消息和事务机制来保证消息的可靠性。消息可以被持久化到数据库或文件系统，以防止消息丢失。消费者可以使用事务机制，确保消息在处理后被确认。如果消费者在处理消息后发生故障，ActiveMQ 可以将未确认的消息重新传递给其他消费者。
优点：支持多种传输协议和消息模式，具有良好的可靠性和可用性。
缺点：性能可能受到限制，特别是在高负载情况下。
四、Apache Kafka
厂家：Apache 软件基金会
简介：一个分布式流处理平台，可以处理高吞吐量的实时数据流。
特点：高吞吐量的实时数据流处理、日志收集和分析、构建实时流式处理应用程序
消息机制：使用持久化的日志存储来保证消息的可靠性。消息被写入磁盘中的日志，确保在发生故障时不会丢失。消费者可以根据偏移量（offset）消费消息，Kafka 会追踪每个消费者的偏移量，并在发生故障后重新提供未消费的消息。
优点：具有高吞吐量和低延迟的特性，适用于实时数据流处理，具有良好的可伸缩性和持久性。
缺点：相对较复杂，需要额外的配置和管理。
五、Redis
厂家： Redis Labs
简介：一个高性能的键值存储系统，同时也可以作为消息队列使用。
特点：快速的消息传递和响应、轻量级的发布/订阅模式、简单的消息队列需求
消息机制：作为键值存储系统，并不提供内置的消息持久化机制。但可以通过使用 Redis 的持久化功能来实现消息的持久化。为了确保至少一次消费，消费者可以使用 Redis 的事务机制进行消息确认，并使用 Redis 的原子操作来处理消费逻辑。
优点：高性能的键值存储系统，可以作为消息队列使用，具有低延迟和高吞吐量。
缺点：消息持久性相对较低，不适合需要可靠性保证的场景。
此外还有很多其他的厂家的产品，比如Apache Pulsar、IBM MQ等等，还有基于物联网低延时通讯协议MQTT开发的相关消息产品，个人感觉还是根据业务场景，团队学习成本，后期运维成本等诸多因素去选择吧，入门使用门槛不是很高，无非就是一些api的使用，主要是后期运维，问题排查需要有个技术支撑，否则出问题了，再去学习可能就影响到客户满意度了。
