本文共 2810 字,大约阅读时间需要 9 分钟。
1、为什么使用消息队列
2、消息队列有什么优点和缺点
3、kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点
先说一下消息队列的常见使用场景吧,其实场景有很多,但是比较核心的有3个:解耦、异步、削峰
解耦: A系统发送个数据到BCD三个系统,接口调用发送,那如果E系统也要这个数据呢?那如果D系统现在不需要了呢?现在A系统又要发送第二种数据了呢?A系统负责人濒临各种修改代码崩溃中。。。然后又有更加崩溃的事,A系统要时时刻刻考虑BCDE四个系统如果挂了咋办?要不要重发?要不要把消息存起来?
不使用MQ的系统解耦场景图:
使用MQ之后的解耦场景图:
异步: A系统接收一个请求,需要在自己本地写库,还需要在BCD三个系统写库,自己本地写库要3ms,BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms,接近1s。系统响应就会很慢
不使用MQ,高延时同步场景图:
使用MQ异步化后的接口性能优化图:
削峰: 每天0点到11点,A系统风平浪静,每秒并发请求数量就100个。结果每次一到11点~1点,每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求,系统就可能会死
不使用MQ的时候高峰期系统被打死场景图:
使用MQ高峰期系统削峰场景图:
优点上面已经说了,就是在特殊场景下有其对应的好处,解耦、异步、削
缺点呢?显而易见:
系统可用性降低:系统引入的外部依赖越多,越容易挂。如:MQ挂了,整套系统不可用
系统复杂性提高:加了MQ进来,需要考虑怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?
一致性问题:A系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是BCD三个系统那里,BD两个系统写库成功了,结果C系统写库失败了,这数据就不一致了。
所以消息队列实际是一种非常复杂的架构,引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,之后,你会发现,系统复杂度提升了一个数量级,也许是复杂了10倍。但是关键时刻,还是得用的
activemq最早企业都用ActiveMQ,但是现在企业确实用的不多了。没经过大规模吞吐量场景的验证,社区也不是很活跃,所以这里不对比
特性 | RabbitMQ | RocketMQ | Kafka |
---|---|---|---|
单机吞吐量 | 万级,吞吐量比RocketMQ和Kafka要低了一个数量级 | 10万级,RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别,这是kafka最大的优点,就是吞吐量高。 一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
topic数量对吞吐量的影响 | topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降 (这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topic) | topic从几十个到几百个的时候,吞吐量会大幅度下降 (所以在同等机器下,kafka尽量保证topic数量不要过多。 如果要支撑大规模topic,需要增加更多的机器资源) | |
时效性 | 微秒级,这是rabbitmq的一大特点,延迟是最低的 | ms级 | 延迟在ms级以内 |
可用性 | 高,基于主从架构实现高可用性 | 非常高,分布式架构 | 非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用 |
消息可靠性 | 经过参数优化配置,可以做到0丢失 | 经过参数优化配置,消息可以做到0丢失 | |
功能支持 | 基于erlang开发,所以并发能力很强,性能极其好,延时很低 | MQ功能较为完善,还是分布式的,扩展性好 | 功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用上的标准 |
优劣总结:
RabbitMQ好处:
0、基本不会丢数据
1、吞吐量到万级,MQ功能比较完善、延时非常低(消息写到mq,到消费停留的时间)
2、开源的管理界面,大量的操作可基于管理界面操作,包括创建queues、集群的监控等
3、官方社区很活跃,几乎一个月发布几个版本。近几年比较企业使用的也比较多
------------------
RabbitMQ劣势:
0、吞吐量单机会低一些,因为它做的实现机制比较重
1、erlang语言开发,很难看懂源码,企业很难定制和掌控,基本得依靠开源社区的快速维护和修复bug(不用到比较乱七八糟的功能,这个问题不大)
2、集群动态扩展相对比RocketMq麻烦
RocketMQ好处:
0、在阿里大规模应用过,日处理消息上百亿之多(阿里品牌保障)
1、可以做到大规模吞吐、性能也非常好、分布式扩展很方便
2、java源码开发,可以定制公司的MQ
3、官方社区算活跃
------------------
RocketMQ劣势:
0、文档相对简单一些,接口不是按照JMS规范走的。有些系统要迁移需要修改大量代码
1、阿里出台的技术,得做好这个技术万一被抛弃,官方停止维护得公司自己去维护或者靠社区修复一些bug
Kafka好处:
0、仅仅提供较少的核心功能,但是提供超高的吞吐量
1、ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展
2、topic数量越少,保证其超高吞吐量
3、大数据领域的实时计算、日志采集等场景,Kafka是业内标准,绝对不会黄
------------------
Kafka劣势:
0、topic从几十个到几百个的时候,吞吐量会大幅度下降
1、有可能消息重复消费,那么对数据准确性会造成极其轻微的影响
个人建议:
ActiveMQ:不建议使用,没经过大规模吞吐量场景的验证,社区也不是很活跃,防止踩坑
Kafka: 如果是大数据领域的实时计算、日志采集等场景,用Kafka是业内标准
RabbitMQ:erlang语言开放,是由存大量个人散户,一般是不会黄,社区很活跃
RocketMQ:确实很不错,但是得想好社区万一突然黄掉的风险,对自己公司技术实力有绝对自信就推荐用RocketMQ
中小型公司技术挑战不是特别高,用RabbitMQ是不错的选择(吞吐量不错、功能也完备、管理后台方便、开源社区活跃。不一定要自己去看erlang源码,依靠社区快速迭代版本也是可以)
大型公司或者中大型公司,有基础架构研发实力,可以投入一组java的研发MQ源码,并可以进行改造,这种公司选择RocketMQ更合适,因为RocketMQ做的确实比RabbitMQ更好。(吞吐量、分布式等)
大数据领域的实时计算、日志采集等场景,kafka不用考虑
转载地址:http://giuws.baihongyu.com/