为什么要学习消息队列

为什么要学习消息队列

消息队列作为使用最广泛、生命力最旺盛的中间件，无论技术如何发展，都离不开分布式系统的最基本需求：通信。它涉及的底层技术是非常全面的，比如：高性能通信、海量数据存储、高并发等。并且，消息队列具有功能简洁、结构清晰的特点，入门简单但具有足够的深度，适合用来进行深入地分析和学习

学好消息队列，不应该仅仅停留在使用层面上，还需要深入了解它的设计思路、实现原理和使用的底层技术。但是要注意循序渐进，由浅入深地去学习。

消息队列处理的问题

一、异步任务

二、流量控制

三、服务解耦

选择消息队列的基本标准

1. 开源
2. 社区活跃度高
3. 消息的可靠传递：确保不丢消息
4. Cluster：支持集群，确保不会因为某个节点宕机导致服务不可用，当然也不能丢消息；
5. 性能：具备足够好的性能，能满足绝大多数场景的性能要求。

可供选择的消息队列

一、RabbitMQ

​ 轻量级、迅捷，它的 Slogan，也就是宣传口号，也很明确地表明了 RabbitMQ 的特点：Messaging that just works，“开箱即用的消息队列”。也就是说，RabbitMQ 是一个相当轻量级的消息队列，非常容易部署和使用。

优点

1. 轻量
2. 使用方便
3. 客户端支持的语言很多
4. Exchange功能强大

缺点

1. 对消息堆积的支持不好
2. 性能很差
3. 编写的语言难度大且冷门

二、RocketMQ

RocketMQ 是阿里巴巴在 2012 年开源的消息队列产品，后来捐赠给 Apache 软件基金会，2017 正式毕业，成为 Apache 的顶级项目。阿里内部也是使用 RocketMQ 作为支撑其业务的消息队列，经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的。作为优秀的国产消息队列，近年来越来越多的被国内众多大厂使用。

RocketMQ 就像一个品学兼优的好学生，有着不错的性能，稳定性和可靠性，具备一个现代的消息队列应该有的几乎全部功能和特性，并且它还在持续的成长中。

优点

1. 社区中文且活跃
2. 性能高
3. 二开容易

缺点

1. 不够国际化

三、Kafka

Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。

在早期的版本中，为了获得极致的性能，在设计方面做了很多的牺牲，比如不保证消息的可靠性，可能会丢失消息，也不支持集群，功能上也比较简陋，这些牺牲对于处理海量日志这个特定的场景都是可以接受的。这个时期的 Kafka 甚至不能称之为一个合格的消息队列。

但是，请注意，重点一般都在后面。随后的几年 Kafka 逐步补齐了这些短板，你在网上搜到的很多消息队列的对比文章还在说 Kafka 不可靠，其实这种说法早已经过时了。当下的 Kafka 已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。

第二梯队消息队列

ActiveMQ

​ ActiveMQ 是最老牌的开源消息队列，是十年前唯一可供选择的开源消息队列，目前已进入老年期，社区不活跃。无论是功能还是性能方面，ActiveMQ 都与现代的消息队列存在明显的差距，它存在的意义仅限于兼容那些还在用的爷爷辈儿的系统。

ZeroMQ

​ 严格来说 ZeroMQ 并不能称之为一个消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用 ZeroMQ。

Pulsar

​ Pulsar 是一个新兴的开源消息队列产品，最早是由 Yahoo 开发，目前处于成长期，流行度和成熟度相对没有那么高。与其他消息队列最大的不同是，Pulsar 采用存储和计算分离的设计，我个人非常喜欢这种设计，它有可能会引领未来消息队列的一个发展方向，建议你持续关注这个项目。

选择

如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。

如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。

如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。