RocketMq灰皮书(一)------选型&RocketMQ名词
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中存在的四个概念.探究学识,由浅入深,只有对这些基本的东西理解透彻,才能更进一步.
个人公众号<橙耘自留地>日前已经开通,后续博主发布的文章都会一并更新到公众号,如有需要,自行查阅.
关于橙耘自留地,是我个人聚焦互联网技术栈学习分享的一个平台,创立之初是因为目前业内各种技术课程资料层次不齐,褒贬不一,有时候一门课花费高价买入,其实内含草包,有时偶尔低价得之,却又大有干货.因此我会根据大家的意见和评价,选择不同的技术栈去学习,一为提升我自己的技术,二为大家梳理出质量比较好的课程,以作参考.同时,相关的学习心得也会一并更新到博客和公众号.
