RocketMQ：能够抵挡双十一的中间件是怎么设计的？

最近又重新学习了一遍 RocketMQ，真的是每次看都能够感悟到一些新的东西。

所以说学东西还是得先粗略的了解一下大概之后，再去往深了一点点研究，从而形成一套体系。

1. 什么是 RocketMQ？

github 地址：https://github.com/apache/rocketmq

来自知乎：Apache RocketMQ 是一款低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。

它最早作为阿里巴巴内部的消息中间件解决方案被使用，用于支持公司的大规模分布式系统和应用。后来，阿里巴巴将 RocketMQ 贡献给了 Apache 软件基金会，并成为 Apache RocketMQ 项目的一部分，成为一个开源项目。

一句话概括来说就是：RocketMQ 是我们国内知名大厂 阿里巴巴 设计开发的一款高并发、高可用、高性能的 分布式消息中间件。

那既然是阿里的中间件，肯定也是抵挡住了多年双十一冲击的，当然这也就和上面的 三高 呼应上了，话不多说。学一波~

2. 正常消息收发流程

提到消息收发，必不可少的两位核心：消息生产者和消息消费者。

对应到我们生活中的场景就很多啦，就比如快递员送快递的场景。我们在手机上下单之后，可能过个两天左右，咚咚咚~小哥就来了，此时我们（你）就可以拿起打气筒，然后利用上面的利刃给快递打开。

但是！万一小哥上门给你送货的时候，这个时候恰巧你不在家，小哥联系你又恰巧联系不上，是的，我说的是恰巧。这种情况怎么办？快递小哥只能把货又拿回站点等待下一次的配送。

上面这种场景是不是还挺常见的？等等…我知道你想说什么，让我来说。

这种场景是不是挺不方便的？

• 你（消息消费者）着急用，却拿不到货。
• 小哥（消息生产者）也着急把货送出去。

3. 消息队列

哎呀~怎么办呢？要是有个快递柜就好了。对哦！快递柜！！

这样小哥就可以不用管你在不在家，直接将货给你放到快递柜里，紧接着再发一条短信给你，就可以下班陪回家老婆去了（异步）。

对于你来说呢，等下班直接按照小哥发的短信息，直接找柜子拿自己的快递就好了（解耦）。

快递多的话，也不用怕快递小哥丢过来压噶自己，一件一件从快递柜中拿就好了（削峰填谷）。

那如果快递柜子塞满了怎么办？哈哈，那就再来一个。这下问题又来啦，快递柜变多了之后，我怎么知道存放我快递的柜子在哪？还记不记得前面提到的小哥会发一条短信（或者通知）给你？

根据这个通知，我们就可以清楚的知道快递柜的所处位置了。这个通知其实就可以理解为看板，快递小哥和我们都可以从看板上看到快递柜的相关信息。

至于一个快递小哥忙不过来的场景，是不是再招募几个小哥就可以了。这样也就解决其中一个小哥请假不在的时候，快递也能够正常的送达。那对于取快递的人（也就是消息消费者）是不是也是一样的道理？在消息队列中也就是生产者组和消费者组的概念了。

上面这个例子大致可以体现出消息队列的功能，但是并不完全合理。因为在我们的消息队列中是可以支持多个消费者消费同一条消息的场景，还用快递这个场景的话，是不是多少有点不太合适了。多个人去拿一个快递，乱了套。。。

相信大家通过上面的例子已经对消息队列有了一个初步的认识，之后我们将不再沿用上述示例，改为真实的消息收发场景。

4. RocketMQ 的设计

上面就是 RocketMQ 的架构图，对比之前的图，相信大家可以基本理解了。

producer

消息生产者，发送消息的人。会将消息发送给 Broker 实例。

producer group

消息生产者组，具有多个生产者，表示同一类生产者。

nameSrv

名称服务，也就是路由注册中心，Broker 实例会定时将自己的信息上传给 nameSrv。然后消息收发者就可以从 nameSrv 上获取 Broker 信息，从而进行消息的收发工作。

Broker

代理服务器，消息中转站，存储消息的地方。

Broker cluster

代理服务器集群，具有多个代理服务器，其中一个挂掉之后，其他的可以顶上来工作，不至于服务直接挂掉。

consumer

消息消费者，从 Broker 上拉取消息进行消费。

consumer group

消息消费者组，每组有多个消费者。每个消费者组之间的消息互不干扰。比如往 Broker 中发送了一条消息，group A 可以看到，group B 也可以看到。

消费者组消费的模式一般有两种：广播和集群。

• 广播：生产者发送了 10 条消息，消费者组中的消费者们都将会接收到者 10 条消息。
• 集群：生产者发送了 10 条消息，好比说消费者组中有 4 个消息消费者，此时消费者 1 消费了 1 条消息，消费者 2 消费了 2 条消息，消费者 3…总之大家均匀的消费了所有的消息。

Topic

也就是主题的意思，生产者可能会发送多种类型的消息，比如：关于体育的、关于 IT 的…其实生产者在生产消息的时候就可以给消息打上 Topic：Topic-体育、Topic-IT…然后消费者就可以根据不同的主题订阅不同的内容了，达到拒绝无用消息的目的。

Tag

Tag 其实也是对消息进行区分的，相比 Topic 来说，Tag 会更细一点。还是用 Topic 中的例子，你喜欢马龙，那么你就订阅 Topic-体育 && 马龙的消息，也是达到拒绝和自己无关消息的目的。

好啦，今天就先说这么多，后续我们再来循序渐进的来认识 RocketMQ！