常见的消息队列中间件,我们可以选择的有很多,但基本需要满足如下的要求
1.要求必须要开源
2.社区要求有一定的活跃度
3.要求和其他的生态系统有一定的集成和兼容,比如Kafka和Flink的兼容
所以,作为一款及格的消息队列产品,具备的特性有
消息的可靠传递
支持集群化的部署
具有良好的传递性能
第一梯队:
1.RabbitMQ
老牌劲旅,RabbitMQ,使用Erlang写的,轻量级,迅捷,开箱即用,容易部署和使用
支持灵活的路由配置,在生产者和队列之间增加了一个Exchange模块,可以理解为交换机
而且支持的客户端很多,即时是冷门的语言,也可以找到对应的RabbitMQ
但是RabbitMQ的消息堆积处理并不好,大量堆积可能导致性能下降
而且性能一般,使用的编程语言Erlang,也是很小众很难以学习的语言,并不好进行二次开发
2.RocketMQ
阿里开源的项目,基本没有什么缺点,品学兼优的好孩子,而且使用的Java开发,贡献者大多都是中国人,源代码易于读懂,可以使用RocketMQ进行扩展或者二次开发
而且响应极其的好,可以做到毫秒级
就是现在的生态环境还没起来
3.Kafka
Apache的顶级项目,Kafka最开始用于处理海量的日志,早期版本为了实现这个目的,牺牲了很多其他方面,比如不支持集群,可能丢数据,
但是伴随着发展,都已经发展为一个成熟的消息队列了
而且和周边生态的兼容性很好,大数据和流计算领域,都基本支持kafka
但是Kafka的消息首发延迟比较高,往往不是立刻发出去,而是等一会攒一批再发,其Broker中,大量体现了这种设计,业务场景中,每秒的消息数量不多的时候,Kafka时延反而很高
然后是第二梯队:
1.ActiveMQ,老牌的消息队列,十年前的唯一选择,已经进入了老年期,社区不活跃,性能不达标
2.ZeroMQ,一个基于消息队列的多线程网络库,偏向于网络交互
3,Pulsar,新兴的开源消息队列,采用存储和计算分离的设计
这样就是我们根据自身的特点选择对应的MQ了
本次思考,我们的思考题是围绕着消息队列的技术选型做的,那么我们对消息队列的需求有什么.使用的是哪款产品?理由呢?
1.我们现阶段使用的是Kafka和RocketMQ,一个用于外部的日志数据接收并存储,方便集群内服务消费并聚合,一个用于内部的服务解耦,将处理完成的数据批量存库