省流:

十几年前,淘宝的notify,借鉴ActiveMQ。京东的ActiveMQ集群几百台,后面改成JMQ。

Linkedin的kafka,因为是scala,国内很多人不熟。淘宝的人把kafka用java写了一遍,取名metaq,后来再改名RocketMQ。

正文:

总的来说,三大原因,语言、潮流、生态。

MQ这种东西,当你的消息量不大的时候,用啥是没多大区别的。特别是在过去20年里,有些阶段你没多少开源的MQ可选,所以最开始ActiveMQ和RabbitMQ还是很火的。

ActiveMQ、RabbitMQ、Kafka/RocketMQ,包括最近很火的pulsar,都非常有自己的特色,但是中间件这条线上,越早出现的,包袱越大,功能可能更多,比如ActiveMQ发展16年了,有大几百个功能,你能想到的所有消息领域的特性,它全都有,所有消息协议,都支持,搞的太重了。淘宝最早期的notify,就是借鉴ActiveMQ来的。

京东多年使用大规模的ActiveMQ集群10年前就有几百台了,然后发现古老的MQ模型,broker太重,量一大就卡(90%用ActiveMQ,但是有一定规模的数据量,这个问题都搞不好搞),然后慢慢发展了自己的JMQ。当年大家消息吞吐量都不大的时候,RabbitMQ就是神器,吞吐高出ActiveMQ几倍。但是慢慢大家发现,真有什么问题,团队没有erlang高手的话,没任何办法。比如说,一天几个亿、几十亿的消息,RabbitMQ一卡住,上下游所有交易订单处理,全都蹦掉了。

这个时候,linkedin搞出来了kafka天然支持消息堆积。然后很快twitter之类的公司快速跟上,在传输消息量非常大的几个领域,大数据的数据传输,日志和监控数据收集,等领域就称霸了。这个几年的代差,让大家不在一个起跑线上。紧接着淘宝尝试用kafka效果不错,但是搞不定scala,然后像从ActiveMQ发展出来了notify一样,基本上用java把kafka翻译了一遍,有了metaq,然后再逐渐出来了RocketMQ,发展了很多年,跟Kafka有一些小的差异,本质上还是那一套。

特别是最近这5-6年,随着整个互联网数据量的进一步增大,kafka/rocketmq在越来越丰富的场景下证明了分布式+支持堆积消息的优越性。大家积累了大量的经验和应用场景,然后发现日常做业务也可以放心大胆用mq处理了。

最后kafka和RocketMQ本身社区活跃,工具体系丰富,发展的很快(ActiveMQ中间尝试6.x版本浪费了很多年,最近两年跟hornetq合并才有新的发展方向。RabbitMQ中间也错失了一些机会。特别是RabbitMQ属于pivotal,spring品牌所在的公司,有个erlang的产品,跟其他的东西相比,蛮奇怪的,也许这也有些原因)。

总而言之,现在技术发展太快了,越是后起之秀,越能站上前辈的肩膀上,实现弯道超车。Kafka/RocketMQ,首先是基于JVM和Java,其次就是赶上了数据量爆发的快车道,最后是体系工具非常丰富,所以目前基本上占山为王(时至今日,几乎可以说,rpc和mq是分布式大厦门口最基础的两块砖)。

Kafka在stream流处理的道路上越走越远,下一波大的技术浪潮也许还能赶上。

个人非常看好pulsar,在kafka的基础上,进一步的分离计算和存储计算存储分离是下一代基础软件的大趋势),国内很多人在负责和参与这个新的MQ项目。

对了,前面提到的所有MQ,只有RabbitMQ是pivotal的,其他的都属于Apache开源基金会。

2021-04-08 https://www.zhihu.com/question/449611434/answer/1824707689

至于用不用erlang开发,只不过正巧emq和rabbitmq都是用erlang开发的,但是这个跟你准备用啥语言开发一点关系都没有。你的程序接收到MQTT消息后,就可以作为消息中间件的producer转发给消息中间件,消息中间件你可以选RabbitMQ,也可以选ActiveMQ,kafka等。这个消息中间件的作用是解耦消息解析和消息分发处理的业务逻辑,让其他应用作为消息中间件的consumer可以去订阅消费它所需的消息。

MQTT是IBM制定的物联网通信协议。可以先读下3.1.1版本MQTT协议标准文档,有中文版。emq是华为出来的人开发的遵循MQTT等协议的MQTT broker。官网有详细使用文档。有开源版本和收费的企业版。RabbitMQ不能称之为中间件,更准确的说法是AMQP(Advanced Message Queue 高级消息队列协议)协议的一种broker实现

https://www.zhihu.com/question/326354272/answer/698693509

08-19 01:21