啥？提到"异步"，你的第一反应居然不是它？

你好呀，我是歪歪。

大家都知道，系统优化有三宝：异步、缓存、分片。

那说到异步，很多人第一反应是线程池。但是有一说一，和线程池比起来，消息队列才是异步的精华。

对于消息队列，必须做到知其然，知其所以然。而消息中间件恰好也是集大成者，需要也值得投入大量精力去研究。

早年，业界消息队列演进的主要推动力在于功能、场景、分布式集群的支持等等。近几年，随着云原生架构和 Serverless 的普及，业界 MQ 主要向实时消息和流消息的融合架构、Serverless、Event、协议兼容等方面演进。从而实现计算、存储的弹性，实现集群的 Serverless 化。

作为一个老后端，我理解作为消息队列的使用者、研发人员、运维人员、架构师，大家希望获得什么，解决什么问题。

• 使用者：希望选出符合我们业务需求、系统架构的最优组件；
• 研发人员：希望了解消息队列的底层原理、设计思考、实现方案；
• 运维人员：希望能够判断这款产品是否足够稳定，是否有隐藏的风险等等；
• 架构师：希望了解到每款消息队列的功能清单、系统架构的优劣势、成本结构等等信息，以此辅助我们做出合理的决策。

但不管什么角色，都会遇到一个关键问题，那就是：消息队列那么多，看起来那么复杂，我们是否做出了最优选择？

而要解决这个问题，我们是不是要把业界那么多的主流消息队列都学一遍？

当然不用，学习应有技巧。

掌握消息队列的关键路径是什么？

从架构设计角度来看，消息队列在演进过程中本就存在相互借鉴，这也给我们学习消息队列提供了一个便捷的路径。

即只要我们从需求出发，理解设计原理、主流技术方案、方案之间的优劣、选型过程主要的思考点，那么我们再往下学习具体某一款消息队列就会变得非常简单。

在我看来，掌握的核心关键点是成体系、系统、全面的知识结构。只要掌握了核心、掌握了顶层设计原理，不管有多少消息队列都能轻松驾驭。

以最近消息队列领域最火的 Apache Pulsar 举例。

从它的设计思想中，你会看到 Kafka、RocketMQ、RabbitMQ 的影子。从架构的角度，Pulsar Broker 和 Kafka 的设计几乎是一模一样的。所以你只要理解了 Kakfa、RocketMQ、RabbitMQ，再来理解 Pulsar，就是事半功倍的。