消息队列专栏：结缘，初识消息中间件（一）_jms message转 rocket实体-优快云博客

本文链接：https://blog.youkuaiyun.com/IT___zhao/article/details/114996696

“每一次科学家们发生分歧，都是因为掌握的数据不够充分。所以我们可以先就获取哪一类数据达成一致。只要获取了数据，问题也就迎刃而解了。要么我是对的，要么你是对的，要么我们都是错的。然后我们继续研究。 ——Neil deGrasse Tyson”

一、结缘消息中间件

从初次接触消息中间件到成为一名大数据消息队列工程师（主研 KAFKA 开发迭代与维护）至今已近三年，回顾三年工作经历，亲身经历数据的海量增长，在发现服务问题，解决服务问题和业务需求的过程中收获颇多，也踩过了很多坑，却没有一个系统性的总结。因此，希望在这个专栏里记录我的所学所得，如果顺带能帮助到想学习消息中间件的朋友，那么这是一件很让人开心的事，经验尚浅，内容如有误，欢迎交流纠正。

数据（也可以解释为消息）为企业的发展提供动力。我们从数据中获取信息，对它们进行分析处理，然后生成更多的数据。每个应用程序都会产生数据，包括日志消息、度量指标、用户活动记录、响应消息等。数据的点点滴滴都在暗示一些重要的事情，比如下一步行动的方向。我们把数据从源头移动到可以对它们进行分析处理的地方，然后把得到的结果应用到实际场景中，这样才能够确切地知道这些数据要告诉我们什么。例如，我们每天在 Amazon 网站上浏览感兴趣的商品，浏览信息被转化成商品推荐，并在稍后展示给我们。

这个过程完成得越快，组织的反应就越敏捷。花费越少的精力在数据移动上，就越能专注于核心业务。这就是为什么在一个以数据为驱动的企业里，数据管道会成为关键性组件。 如何移动数据，几乎变得与数据本身一样重要。

二、发布订阅消息系统

在介绍消息队列之前，可以先了解下发布与订阅消息系统的概念。数据(消息)的发送者(发布者)不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者(订阅者)订阅它们，以便接收特定类型的消息。发布与订阅系统一般会有一个 broker，也就是发布消息的中心点。

如图所示，这是一个比较经典的发布与订阅系统，可以看到，消息会被发送到不同的服务系统，来提供给下游的消费方使用，但这里有太多重复的地方。你的公司因此要为维护多个消息系统，每个系统又有各自的缺陷和不足。而且，接下来可能会有更多的场景需要用到消息系统。此时，你真正需要的是一个单一的集中式系统，它可以用来发布通用类型的数据，其规模可以随着公司业务的增长而增长。

好了，废话不多说，大哥（消息队列）登场。

三、消息队列发展史

先引一张在其他文章看到的图

这里做一个补充，2018 --》Pulsar 出现

不一一介绍，只对其中个人感兴趣的部分做下介绍，另外这里列举的只是部分具备代表性的开源消息队列，很多 IT 大厂其实都有独属于自己的消息队列系统，或沿用社区版本进行内部迭代，或孵化自研的消息队列（比如字节、腾讯等等），都具备自己优越的特点，这里不做展开讲述，如果读者有兴趣，可以在后续的文章中再进行跟进。也可以自行在网上查到相关的 PPT 介绍，一般都是有技术沙龙分享，程序员还是很重视搜索信息的能力的Q_Q。

(1) TIB

1985年，Teknekron的The Information Bus（TIB）标志着发布订阅模式（PubSub）诞生，同时还诞生了世界上第一个现代消息队列软件，用于解决高盛金融交易的需求。

(2) RabbitMQ

在2006年，Rabbit Technologies诞生了：其拥有着RabbitMQ的知识产权。之所以叫Rabbit这个名字，是因为他们觉得，兔子是行动非常迅速的动物，而且繁殖起来也非常疯狂，把它用于分布式软件的命名再合适不过了。

RabbitMQ是一个开源的AMQP（Advanced Message Queuing Protocol）实现，服务器端采用Erlang语言编写，支持多种客户端，如：Java、C、Python Python、NET 等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

(3) kafka

（3）2011年，kafka诞生，kafka 的诞生是为了解决linkedin的数据管道问题，起初linkedin采用了ActiveMQ来进行数据交换，大约是在2010年前后，那时的ActiveMQ还远远无法满足linkedin对数据传递系统的要求，经常由于各种缺陷而导致消息阻塞或者服务无法正常访问，为了能够解决这个问题，linkedin决定研发自己的消息传递系统，当时linkedin的首席架构师jay kreps便开始组织团队进行消息传递系统的研发。KAFKA 是目前业务业界内最流行的MQ（不接受反驳 Q_Q ），整体非常成熟，应用生态也很完善。

(4) RocketMQ

（4）2012年，ROCKETMQ 诞生，随着 2011 年 Kafka 从 Apache 顶级项目毕业，其自研存储引擎带来的海量消息堆积，高效的持久化特性走入我们的视野。但它特殊的日志通道定位，不能完全满足阿里巴巴高频的在线交易场景，为此团队设计并研发了新一代消息引擎 RocketMQ（内部叫 MetaQ），从最初的日志传输领域到后来阿里集团全维度在线业务的支撑，RocketMQ 被广泛用在交易，数据同步，缓存同步，IM 通讯，流计算，IoT 等场景。如果是应对一些高并发，高可靠以及高可用比较苛刻的场景，RocketMQ 也是一个不错的选择。

(5) Pulsar

2018年，Pulsar。Apache Pulsar 最初诞生于雅虎，当时就是为了解决雅虎内部各个部门之间数据的协调，所以多租户特性显得至关重用，Pulsar 从诞生之日起就考虑到多租户这一特性，并在后续的实现过程中，将其不断的完善。多租户这一特性，使得各个部门之间可以共享同一份数据，不用单独部署独立的系统来操作数据，很好的保证了各部门间数据一致性的问题，同时简化维护成本。Pulsar 的无状态是一个很大的亮点，个人感觉无状态会是一种趋势。