你好呀，我是歪歪。
大家都知道，系统优化有三宝：异步、缓存、分片。
那说到异步，很多人第一反应是线程池。但是有一说一，和线程池比起来，消息队列才是异步的精华。
对于消息队列，必须做到知其然，知其所以然。而消息中间件恰好也是集大成者，需要也值得投入大量精力去研究。
早年，业界消息队列演进的主要推动力在于功能、场景、分布式集群的支持等等。近几年，随着云原生架构和 Serverless 的普及，业界 MQ 主要向实时消息和流消息的融合架构、Serverless、Event、协议兼容等方面演进。从而实现计算、存储的弹性，实现集群的 Serverless 化。
作为一个老后端，我理解作为消息队列的使用者、研发人员、运维人员、架构师，大家希望获得什么，解决什么问题。
- 使用者：希望选出符合我们业务需求、系统架构的最优组件；
- 研发人员：希望了解消息队列的底层原理、设计思考、实现方案；
- 运维人员：希望能够判断这款产品是否足够稳定，是否有隐藏的风险等等；
- 架构师：希望了解到每款消息队列的功能清单、系统架构的优劣势、成本结构等等信息，以此辅助我们做出合理的决策。
但不管什么角色，都会遇到一个关键问题，那就是：消息队列那么多，看起来那么复杂，我们是否做出了最优选择？
而要解决这个问题，我们是不是要把业界那么多的主流消息队列都学一遍？
当然不用，学习应有技巧。
掌握消息队列的关键路径是什么？
从架构设计角度来看，消息队列在演进过程中本就存在相互借鉴，这也给我们学习消息队列提供了一个便捷的路径。
即只要我们从需求出发，理解设计原理、主流技术方案、方案之间的优劣、选型过程主要的思考点，那么我们再往下学习具体某一款消息队列就会变得非常简单。
在我看来，掌握的核心关键点是成体系、系统、全面的知识结构。只要掌握了核心、掌握了顶层设计原理，不管有多少消息队列都能轻松驾驭。
以最近消息队列领域最火的 Apache Pulsar 举例。
从它的设计思想中，你会看到 Kafka、RocketMQ、RabbitMQ 的影子。从架构的角度，Pulsar Broker 和 Kafka 的设计几乎是一模一样的。所以你只要理解了 Kakfa、RocketMQ、RabbitMQ，再来理解 Pulsar，就是事半功倍的。
