作者：blithe
2020 年我有幸加入腾讯 tdmq 初创团队，当时 tdmq 还正在上云公测阶段，我第一次从一个使用工具的人转变成了开发工具的人，这个过程使我沉淀了很多消息队列知识与设计艺术。后来在业务中台的实践中，也频繁地使用到了 MQ，比如最常见的消息推送，异常信息的重试等等，过程中也对消息队列有了更加深刻的了解。此篇文章，我会站在一个时间维度的视角上去讲解这二十年每款 MQ 诞生的背景以及解决了何种问题。
2003 至今有很多优秀的消息队列诞生，其中就有被大家所熟知的就是 kafka、阿里自研的 rocketmq、以及后起之秀 pulsar。首先我们先来了解一下每一时期消息队列诞生的背景以及要解决的核心问题是什么？
如图所示，我把消息队列的发展切分成了三个大的阶段。
就是从 2003 年到 2010 年之前，03 年可以说计算机软件行业刚刚兴起，解决系统间强耦合变成了程序设计的一大难题，这一阶段以 activemq 和 rabbitmq 为主的消息队列致力于解决系统间解耦合和一些异步化的操作的问题，这也是所有消息队列被使用的最多的功能之一。
在 2010 年到 2012 年期间，大数据时代正式到来，实时计算的需求越来越高，数据规模也越来越大。由于传统消息队列已无法满足大数据的需求，消息队列设计的关键因素逐渐转向为吞吐量和并发程度。在这一背景下，Kafka 应运而生，并在日志收集和数据通道领域占据了重要地位。
然而，随着阿里电商业务的兴起，Kafka 在可靠性、一致性、顺序消息、事务消息支持等方面已经无法满足阿里电商场景的需求。因此，RocketMQ 诞生了，阿里在自研消息队列的过程中吸收了 Kafka 的很多设计理念，如顺序写盘、零拷贝、end-to-end 压缩方式，并在此基础上解决了 Kafka 的一些痛点问题，比如强依赖 Zookeeper。后来，阿里将 RocketMQ 捐赠给了 Apache，并最终成为了 Apache RocketMQ。
"没有平台的产品是没用的，再精确一点，去平台化的产品总是被平台化的产品所取代" 这句话并不是我说的，而是来自一篇来自 2011 年的文章《steve 对亚马逊和 google 的吐槽》（ https://coolshell.cn/articles/5701.html 推荐阅读）。
2012 以后，随着云计算、k8s、容器化等新兴的技术兴起，如何把基本底层技术能力平台化成为了众多公司的攻坚方向，阿里云、腾讯云、华为云的入场都证明了这点，在这种大背景下，Pulasr 诞生了。
雅虎起初启动 pulsar 项目是为了解决以下三个问题：
公司内部多团队重复建造轮子。
当前主流 mq 的租户隔离机制都支持的不是很好。
数据迁移、恢复、故障转移个个都是头疼的问题，消息队列运维成本极高。
这三个问题的答案都指向了一个方向：平台化。