今天我们一起来探讨如何正确的选择消息队列,包含如下3个章节:
那么目前在业界有哪些比较知名的消息引擎呢?如下图所示
这里面几乎完全列举了当下比较知名的消息引擎,包括:
1.解耦
解耦是消息队列要解决的最本质问题。
2.最终一致性
最终一致性指的是两个系统的状态保持一致,要么都成功,要么都失败。
最终一致性不是消息队列的必备特性,但确实可以依靠消息队列来做最终一致性的事情。
2.广播
消息队列的基本功能之一是进行广播。
有了消息队列,我们只需要关心消息是否送达了队列,至于谁希望订阅,是下游的事情,无疑极大地减少了开发和联调的工作量。
3.错峰与流控
典型的使用场景就是秒杀业务用于流量削峰场景。
由于篇幅的关系,本文重点介绍消息队列比较,详细应用场景请查看:
什么是流量削峰?如何解决秒杀等业务的削峰场景
谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,在数据采集、传输、存储的过程中发挥着举足轻重的作用,被LinkedIn,Uber, Twitter, Netflix等大公司所采纳,而storm,spark,flink等大数据流处理或批处理平台都有Kafka的相关插件支持。
Apache Kafka它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log),之后成为Apache项目的一部分。
Kafka优点:
kafka缺点:
RabbitMQ 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
使用RabbitMQ需要:
RabbitMQ优点:
RabbitMQ缺点:
RocketMQ出自 阿里公司的开源产品,用 Java 语言实现,在设计时参考了 Kafka,并做出了自己的一些改进,消息可靠性上比 Kafka 更好。
RocketMQ在阿里集团被广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等场景。
使用RocketMQ需要:
RocketMQ优点:
RocketMQ缺点:
1.Kafka
Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,适合产生大量数据的互联网服务的数据收集业务。
是一个不折不扣的大数据通道,追求高吞吐,不过存在丢消息的可能。
2.RocketMQ
天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务削峰,在大量交易涌入时,后端可能无法及时处理,所以MQ的大量消息堆积功能就可以发挥作用。
RoketMQ在稳定性上可能更值得信赖,这些业务场景在阿里双11已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择RocketMQ。
3.RabbitMQ
RabbitMQ :结合erlang语言本身的并发优势,性能较好,社区活跃度也比较高,但是不利于做二次开发和维护。
最后,结合上面的介绍,再简要总结如下:
1.中小型软件公司,建议选RabbitMQ,一方面,erlang语言天生具备高并发的特性,而且他的管理界面用起来十分方便,但是不利于做二次开发和维护。
所幸,RabbitMQ的社区十分活跃,可以解决开发过程中遇到的bug,这点对于中小型公司来说十分重要。中小型软件公司不如互联网公司,数据量没那么大,选消息中间件,应首选功能比较完备的,推荐RabbitMQ。
2.大型软件公司,根据具体使用在RocketMq和kafka之间二选一。至于kafka,根据业务场景选择,如果有日志采集功能,肯定是首选kafka了。