消息队列--入门篇

消息队列–入门篇

如何学习一门新技术？

学习任何知识需要有一个整体的认识，然后再深入学习，钻研细节，最后抓住核心脉络，总结整理消化在脑海中形成体系。

就好比我们在阅读一些经典的书籍，先粗读（建立大概的认识）—后细读（深入学习思考）—最后总结整理（消化成自己的东西）

我们从RocketMQ入手，一起来看企业级消息队列的整体设计架构。

市面上消息队列的设计基本都是八九不离十大同小异，在了解RocketMQ的大体设计后，对其他消息队列也就手到擒来了。

我们先来思考一下，完整的消息队列需要哪些组件呢？

消息队列的组件

先看一张图：

我是生产消息的人，发送一条消息给杰尼龟，消息内容是：“放学KTV见”。

但是杰尼龟忙着陪对象，他可能不能及时看到我的消息，但我的消息也不想让它丢了。

因此需要有一个中转站，用来暂存这些消息，这样杰尼龟即使不能及时处理消息，也可以等他空了再来看这些消息，我当然也不需要关注杰尼龟忙不忙，直接发消息就完事了。

可以看到中转站，不仅存储我的信息，还能存储很多信息，比如妙蛙种子发给星之卡比的。

渐渐地消息变多了，一个中转站可能运作不过来，这时候需要扩容再建一个。

但是随之而来的是，中转站多了，管理起来就不容易，大家用起来就不容易。

比如妙蛙种子这个人就是比较犟，他每次就去中转站1取消息，也不去中转站2看看有没有他的消息，导致星之卡比给他发的“今晚老地方见啊”，他也没看到。

这个时候就需要一个看板，这个看板的作用就是让大家知晓有几个中转站。

中转站们需要自己上报收到的消息给看板，让大家知晓它们的存在。

而发消息的人和收消息的人可以从看板上知晓中转站的存在和对应的消息，从而顺利的进行收发消息。

渐渐地我和杰尼龟之间的消息变多了，我把一些工作分担出去给我的小弟，于是就组建起来自己的小团队，招募了小火龙-1，小火龙-2来帮忙。

上图虽然看起来有模有样，但是细想还有很多的问题。

比如：

1. 我怎么知道哪个中转站比较空，将消息发给中转站1还是2？
2. 如果中转站堆积了很多消息，怎么让杰尼龟快速找到他的消息，难道要一条一条翻吗，效率也太低了。
3. 如果这时候又来了一个小陆，她是一个海王，每天都要收发大量的消息，并且是和不同的接收方，如何保证中转站的负载均衡不超负荷呢？

这些事看起来没有那么简单，但是没有关系，后续我们慢慢盘，今天我们的目标是建立一个大体的印象。

结合上面我画的图，我们再来看下面这张官方的图，它包括了RocketMQ相关的组件和角色。

• producer类似于上面的我，小火龙
• producer group-A就是我的团队
• nameSrv1、2就是看板
• BrokerA、B就是中转站1、2
• BrokerCluster就是中转站们
• consumer就是上面的杰尼龟
• consumer group-A就是杰尼龟的团队

我相信通过上文通俗易懂的介绍，大家对这几个角色与组件应该有初步了解。

大体介绍一下

producer

生产者，就是消息的发送者。

它会将消息发送给Broker。

producer group

生产者组，用于标识一类生产者。

比如发送事物消息时，一个生产者挂了后，broker可以赵同一个生产组里的另一个生产者来确认事物的情况。（不理解没事，后面会讲到）

nameSrv

名字服务，上面的例子把它比作一个看板，实际上就是一个路由注册中心。

broker会定时把自己的信息比如IP地址等上传给nameSrv。

这样生产者和消费者就可以从nameSrv上获取这些信息，这样才能顺利的发送和接受信息。

broker

代理服务器，也就是我们所说的消息中转站，它主要负责消息的存储、投递、查询。

broker cluster

代理服务器集群，我们知道一个服务是脆落的，假设就一个broker，万一挂了消息就无法正常的发送、存储和消费。

所以我们在企业级场景会搭设集群。

集群可以是主–主集群，也就是集群内部的broker是同等的，同时对外提供服务。

也可以是主—从集群，主broker对外提供服务，从broker同步主broker的消息作为备份， 当主broker宕机，从broker也可以提供消费信息。

一个主可以有多个从，关于集群更多高可用和高可靠的知识，我们后续再谈。

consumer和consumer group

消费者，用来消费消息。可以向broker拉去自己想要消费的消息。

可以让broker把自己想要的消息推过来，然后消费者们可以组成一个消费组，就像杰尼龟小团队。

消费组的概念很关键，比如现在一共有两个消费组分别是杰尼龟消费组和皮卡丘消费组。那么两个消费组之间的消息消费是互不干扰的。就好比我发了一条消息给broker，这条消息杰尼龟消费组可以看，皮卡丘消费组也能看，那么这条消息被杰尼龟消费组消费了不影响它被皮卡丘消费组继续消费。

对于一个组来说，消费的模式有集群消费和广播消费两种模式。

• 集群模式：生产者发送了4条消息，编号为A-D，杰尼龟团队收到了4条消息，实际上是杰尼龟收到A、D，而杰尼龟-1收到了B，杰尼龟-2收到了C，大家负载均衡地消费了这四条消息。

  

• 广播模式：生产者发送了4条消息，编号为A-D，杰尼龟团队收到了这4条信息，实际上是杰尼龟收到了A、B、C、D，杰尼龟-1收到了A、B、C、D，杰尼龟-2收到了A、B、C、D，组内的每个消费者都收到了全部信息，这就是广播。

Topic

主题，可以认为是消息的分类。比如足球主题、篮球主题。

那么有关足球的消息，我们都发往足球主题，如Topic-football。有关篮球的消息，我都发送篮球主题，如Topic-basketball。

这样就给信息分了类，那么对足球有兴趣的消费者则可以订阅Topic-football、对篮球有兴趣的则可以订阅Topic-basketball，大家相互之间互不干扰。

这样一来大家都只订阅了自己想要的信息，不会被无关的信息给打扰了。

Tag

topic已经给消息分类了，那么tag类似于二级分类，这能更精细化地区分信息。

比如有人对足球主题感兴趣，但是只喜欢看梅西相关的信息，而有些人喜欢看C罗的消息。

那么发送消息往足球主题发，但是也顺带加上了tag信息来标记这个信息是梅西的还是 C罗的。

这样订阅了足球主题的消费者可以根据tag选择它们想要的信息，过滤他们不想要的信息。

比如小火龙喜欢梅西，那么订阅的时候只要标记自己只要topic-football且带有tag是梅西的信息。

总结

初始篇我们介绍了消息队列应该有的相关的组件和角色，当然还有很关键的队列,keys等概念，我们放到后面重点讲。

通过本文的介绍，我们至少对其有了初步的印象，也清晰了各个组件大概的作用与消息的流转。后边我会带大家剖析消息队列的原理，清晰RocketMQ整体的运行流程。然后开始掌握基础和进阶的用法，怎么在项目中使用，以及面试常问的消息队列问题。