Message Queue

常见消息队列的区别与选型

特性 ActiveMQ RabbitMQ RocketMQ Kafka
单机吞吐量(单机1秒处理的请求) 万级 万级 十万级 十万级(kafka最大的特点)
Topic数量对吞吐的影响     topic可以达到几百、几千个,吞吐量会有小幅度下降 几十到几百个的时候,吞吐量会大幅度下降
数据从生产到能消费到的延迟 毫秒级 微秒级(rabbitMQ最大的特点) 毫秒级 毫秒级以内
可用性 高,基于主从架构实现高可用 高,基于主从架构实现高可用 非常高,分布式架构 非常高,分布式架构,一份数据可以有多个副本,少数机器宕机不会丢失数据,不会导致不可用
消息可靠性 有较低的概率丢数据   经过参数优化配置,可以做到零丢失 经过参数优化配置,可以做到零丢失
功能支持 MQ领域的功能极其完备 基于erlang开发,所以并发能力很强,性能极好,延迟很低 MQ功能较为完善,并且是分布式的,扩展性好 功能较为简单,主要在大数据实时计算以及日志采集场景中被大规模使用,是事实上的标准
优劣势总结 非常成熟,功能强大,在业内很多公司以及项目都有应用

存在较低概率的数据丢失问题

目前社区以及国内应用越来越少,且官方社区对ActiveMQ 5.x 维护也越来越少,目前下一代的 ActiveMQ 出了新的项目叫 ActiveMQ Artemis。

一般主要用于解耦和异步,较少在吞吐量大的场景使用
erlang 语言开发,性能极好,延迟很低

开源提供的管理界面非常棒,很好用

社区相对活跃

问题也是显而易见的,吞吐量低一些,实现的机制比较重。erlang开发,不太好定制修改源码。并且集群动态扩展比较麻烦,主要是erlang语言本身带来的问题。
阿里开源的,接口简单易用

日处理消息上百亿之多,可以做到大规模吞吐,性能非常好,分布式扩展也很方便,可靠性可用性都ok,可以支持大量topic的场景,支持复杂MQ业务场景

缺点就是阿里的开源的项目,如果这个技术被内部放弃了,社区可能会黄掉
提供的功能比较简单,就是生产和消费,但吞吐量超高,可以任意扩展,可用性有保障,非常适合大数据领域实时计算和日志采集场景,是大数据领域的事实标准,但是消息可能会重复,需要自己处理

引入消息队列的优点

  • 解耦:各模块之间的交互可以替换成都和MQ交互,以达到解耦的目的
  • 异步:模块将请求或者数据发送给MQ之后就可以返回了,响应时间减少
  • 消峰:在请求量比较打的时候可以先发送到MQ做缓冲,由消费者控制消费速率,避免大量请求直接将服务压垮

引入消息队列的缺点

  • 系统复杂性增加
  • 可用性降低,引入 MQ 的单点问题,需保证 MQ 高可用
  • 重复数据问题
  • 数据丢失问题
  • 保证数据消费的顺序性
  • 数据的一致性
  • 由于消费者服务挂掉导致的消息队列数据积压问题

如何保证消息队列的高可用

RabbitMQ

基于主从做高可用,它有三种模式

  1. 单机模式:Demo
  2. 普通集群模式(类似于Shard): 多个机器上安装多个实例,如果创建一个新的queue,它的实际数据只会在一个实例上,但是所有实例都会有这个queue的元数据,请求来了会转发到拥有实际的实例。既不是高可用也不是分布式,只是简单的通过分散queue到不同实例增加吞吐量。
    1. 可能会在集群内部产生大量的数据传输
    2. 没什么高可用可言
  3. 镜像集群模式(Replica):

RocketMQ

Kafka

qin

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码支持
扫码打赏

打开支付宝扫一扫,即可进行扫码打赏哦