RocketMq灰皮书(一)------选型&RocketMQ名词

一. MQ选型对比

目前业内常用的MQ框架有一下几种:

Kafka
RabbitMQ
RocketMQ

除此之外,还有ActiveMQ等,但是ActiveMQ目前使用已经很少了,在一些老项目中可能还能看到,因此在这里不做赘述.

(1) Kafka

优点:

高吞吐量

在常规机器下,使用Kafka,一台机器可以达到每秒十几万的QPS.
高性能

消息发送性能很高,达到毫秒级别.
高可用

支持集群部署,部分机器宕机依然可以正常使用

缺点:

数据丢失

Kafka收到数据会写入磁盘缓冲区,并没有直接落地到物理磁盘,如果此时机器本身故障宕机,可能会导致缓冲区的数据丢失.
功能单一

主要支持发送消息和消费消息,没有额外的功能.

适用场景:

业内一般适用Kafka来进行用户行为日志的采集和传输.

(2) RabbitMQ

优点:

数据不丢失
高可用
拥有高级功能

支持死信队列、消息重试

缺点:

吞吐量低

每秒几万的QPS,在并发比较高的情况下比较困难.
集群扩展比较麻烦
使用erlang开发,二次开发比较困难

使用场景:

一般小型的公司,吞吐量并不高的系统中还在使用,基本上满足项目需求即可.

(3) RocketMQ

优点:

高吞吐量

单机可达10万QPS
高可用
支持集群部署
可以通过配置保证数据不丢失
支持高级功能

如延迟消息、事务消息、死信队列、消息回溯
基于java开发,符合国内很多公司的技术栈,可以很方便的进行二次开发

缺点:

官方文档不够详细,比前面两款略有不足

使用场景:

在大公司中,日常的项目需求,一般都使用比较频繁.

二. RocketMQ中的概念介绍

在详细了解RocketMq之前,有必要先对它涉及的所有相关的概念有所了解,这样在后面使用的时候就能有个初步的印象.

我们用一个简单的流程来介绍,一般来说,我们使用MQ的流程是这样的:

有2个微服务A和B,然后运维部署好MQ
A服务发送消息到MQ
B服务从MQ获取消息,处理逻辑

以上步骤如图:

站在上帝视角,服务A和服务B都是在利用MQ传递消息,即可以说:(1)服务A生产消息,服务B消费消息;(2)RocketMq只是临时持有消息,类似数据库,看到这里,我们已经发现在这个流程中,有两个比较重要的概念了.

Producer

消息生产者,即上图中的服务A

Consumer

消息消费者,即上图中的服务B

Message

代表一条消息,由producer产生,由consumer消费

Broker

每台机器上部署的RocketMq一般称为Broker,每个Broker会收到不同的消息,consumer会从Broker上获取消息.

通过简单的一个消息发送的图示,我们得到了RocketMq中的四个比较重要的概念,不过既然本系列博文取名灰皮书,仅仅到此是不够的,接下来我们思考几个问题.

服务A要发送消息到MQ,它具体是怎么实现的?
服务B要消费MQ的消息,它又是怎么拿到这些消息的?
Broker自己要保存消息,以供服务B来获取,那么它是怎么存储的呢?
RocketMQ高吞吐,且可以集群部署,支持HA,这些又是如何实现的?

以上这些问题,将会在下一篇博文中逐步探索,力求对Rocket的使用和原理都有一定的认识.

总结

写到这里,其实我们只是初步了解了业界使用的MQ的优劣对比,了解了RocketMq中存在的四个概念.探究学识,由浅入深,只有对这些基本的东西理解透彻,才能更进一步.

个人公众号<橙耘自留地>日前已经开通,后续博主发布的文章都会一并更新到公众号,如有需要,自行查阅.

关于橙耘自留地,是我个人聚焦互联网技术栈学习分享的一个平台,创立之初是因为目前业内各种技术课程资料层次不齐,褒贬不一,有时候一门课花费高价买入,其实内含草包,有时偶尔低价得之,却又大有干货.因此我会根据大家的意见和评价,选择不同的技术栈去学习,一为提升我自己的技术,二为大家梳理出质量比较好的课程,以作参考.同时,相关的学习心得也会一并更新到博客和公众号.