今天来学习一款国产的消息中间件：RocketMQ。RocketMQ最初是由阿里团队研发，具有高性能、低延迟和高可靠等特性。
一、概述
先来对RocketMQ有一个宏观的了解
- 灵活的可扩展性。天然支持集群，四大核心组件（NameServer、Broker、Producer、Consumer）都支持水平扩展，同时保证高可用。
- 具有海量数据堆积能力。可以在堆积了很多消息之后仍然保证低延迟写入
- 支持顺序消息。可以保证按照消息发送的顺序对消息进行消费。顺序消息分为全局有序消息和具有有序消息，一般推荐使用局部有序消息，即生产者通过将某一类消息顺序发送至同一对列实现
- 支持分组。通过将生产者、消费者分组，组成逻辑上的集群，实现了服务的高可用以及高性能
- 支持多种消息过滤。可分为服务端过滤和消费端过滤。服务端过滤时可以按照消息消费者的要求进行过滤，优点是减少了不要的消息传输，缺点是会增加消息服务器的负担，同时实现相对复杂；消费者端过滤则完全由具体应用自定义实现，实现简单，而且灵活，缺点是会有一些无用的数据发送给消息消费者
- 支持事务消息。提供了分布式事务的另一种解决思路
- 支持回溯消费。对于已经消费成功的消息再次进行消费
在大概了解了RocketMQ之后，我们再来了解一些具体的概念，深入学习一下。
二、基本概念
1.生产者(Producer)
负责生产消息，并向消息服务器发送业务产生的消息。有以下三种发送消息方式
- 同步发送：在消息发送之后，只有在接受到消息服务器的响应之后才会发送下一条消息。这种方式保证了消息的可靠投递，适用于重要消息通知的场景，但吞吐量不高。
- 异步发送：在消息发送之后，不等消息服务器响应就接着发送另一条消息。此种方式下，生产者需要提供一个回调接口，由消息服务器告知其消息接收结果。吞吐量较上一种要高。
- 单向发送：生产者在发送消息之后不等消息服务器的响应也不提供回调函数用于通知其接受结果。换句话说，提供的是不可靠的消息投递。这种适用于对可靠性要求不高的场景，如日志收集。
生产者生产消息时需要指定消息主题，生产相同topic的多个生产者可以组成一个生产者集群。
2.消费者(Consumer)
从消息服务器获取消息并进行消费，具体又分为拉取型消费者和推送性消费者
拉取型：消费者主动从消息服务器拉取数据
推送型：消费者提供一个回调函数，在消息到达时调用回调函数push数据
和生产者类似，消费同一主题消息的多个消费者可以组成消费者组。
3.消息服务器(Broker)
接收并存储生产者发送的消息。除此之外，它还存储与消息有关的元数据，包括用户组、消费进度偏移量、队列信息。
上面我们说了，Broker也是支持集群的。不过和生产者和消费者集群不同，Broker分为master和slave两种，其中，master既可以写也可以读；slave只可以读不可以写，常见的有多master、多master多slave两大架构。
一个Broker下可以存储多个Topic的消息。
4、名称服务器(NameServer)
用来保存Broker相关的元数据并提供给消费者/生产者查找Broker使用。
每个Broker启动时都需要到名称服务器注册，生产者在发送消息时也需要根据主题到名称服务器中查找Broker路由信息，消费者也会定期获取主题的相关路由信息。
如此看来，RocketMQ的四大组件之间是通过主题关联起来的。
5、主题(Topic)
消息的分类就是主题，一个消息必须要有一个主题，可以根据具体的业务划分。
除此之外，还可以为消息设置标签（子主题），相比于刚才的主题，又增加了一个维度。、
下面说的队列便是以标签为维度划分的。
6、队列(Quene)
消息的最终存储载体是队列，队列是按照子主题（标签）划分的，存在于Broker中。
注意，消息真正存储在commitlog中，队列中只是存储了commitlog中的位置信息。
7、消费模式
消息的消费模式有两种：集群消费、广播消费，默认是集群消费。
集群消费：一个消费者集群共同消费一个主题下的多个队列。一个消息只会被一个消费者消费，如果某个消费者挂掉了，由集群内的其他消费者继续消费。
广播消费：将消息发给消费者组内的每一个消费者进行消费。
很显然，集群消费的吞吐量大。
8、消费顺序
消息的消费方式有两种：顺序消费、并行消费
顺序消费表示按照消息产生的顺序进行消费，而并行消费不保证按照消息产生的顺序消费。
要想实现消息的顺序消费，需要将业务相关的数据都发送到同一个队列中。但是该队列会同时有其他消息灌入，需要进行消息的过滤，推荐在消费端过滤。
三、架构图
最后放一张整体的架构图，架构里的几个组件已经在上面说过了，如不清楚向上翻。
