RocketMQ基本介绍_rocketmq作用

MQ：MessageQueue，消息队列。 队列，是一种FIFO 先进先出的数据结构。消息由生产者发送到MQ
进行排队，然后按原来的顺序交由消息的消费者进行处理。QQ和微信就是典型的MQ。
MQ的作用主要有以下三个方面：
异步
例子：快递员发快递，直接到客户家效率会很低。引入菜鸟驿站后，快递员只需要把快递放到菜鸟
驿站，就可以继续发其他快递去了。客户再按自己的时间安排去菜鸟驿站取快递。
作用：异步能提高系统的响应速度、吞吐量。
解耦
例子：《Thinking in JAVA》很经典，但是都是英文，我们看不懂，所以需要编辑社，将文章翻译
成其他语言，这样就可以完成英语与其他语言的交流。
作用：
1、服务之间进行解耦，才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。
2、另外，解耦后可以实现数据分发。生产者发送一个消息后，可以由一个或者多个消费者进行消
费，并且消费者的增加或者减少对生产者没有影响。
削峰
例子：长江每年都会涨水，但是下游出水口的速度是基本稳定的，所以会涨水。引入三峡大坝后，
可以把水储存起来，下游慢慢排水。
作用：以稳定的系统资源应对突发的流量冲击。

MQ的优缺点

系统可用性降低
系统引入的外部依赖增多，系统的稳定性就会变差。一旦MQ宕机，对业务会产生影响。这就需要考虑
如何保证MQ的高可用。
系统复杂度提高
引入MQ后系统的复杂度会大大提高。以前服务之间可以进行同步的服务调用，引入MQ后，会变为异
步调用，数据的链路就会变得更复杂。并且还会带来其他一些问题。比如：如何保证消费不会丢失？不
会被重复调用？怎么保证消息的顺序性等问题。
消息一致性问题
A系统处理完业务，通过MQ发送消息给B、C系统进行后续的业务处理。如果B系统处理成功，C系统处
理失败怎么办？这就需要考虑如何保证消息数据处理的一致性。

几大MQ产品特点比较

一、基础概念：

1 消息模型（Message Model）
RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，
Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。MessageQueue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。

2 消息生产者（Producer）
负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。
生产者中，会把同一类Producer组成一个集合，叫做生产者组，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

3 消息消费者（Consumer）
负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。

拉取式消费的应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。

推动式消费模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高。

消费者同样会把同一类Consumer组成一个集合，叫做消费者组，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息。

广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息。

4 主题（Topic）
表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。
同一个Topic下的数据，会分片保存到不同的Broker上，而每一个分片单位，就叫做MessageQueue。MessageQueue是生产者发送消息与消费者消费消息的最小单位。

5 代理服务器（Broker Server）
消息中转角色，负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。
Broker Server是RocketMQ真正的业务核心，包含了多个重要的子模块：
Remoting Module：整个Broker的实体，负责处理来自clients端的请求。
Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息
Store Service：提供方便简单的API接口处理消息存储到物理硬盘和查询功能。
HA Service：高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快
速查询。
而Broker Server要保证高可用需要搭建主从集群架构。RocketMQ中有两种Broker架构模式：
普通集群：
这种集群模式下会给每个节点分配一个固定的角色，master负责响应客户端的请求，并存储消息。
slave则只负责对master的消息进行同步保存，并响应部分客户端的读请求。消息同步方式分为同步同步和异步同步

这种集群模式下各个节点的角色无法进行切换，也就是说，master节点挂了，这一组Broker就不可用了。
Dledger高可用集群：
Dledger是RocketMQ自4.5版本引入的实现高可用集群的一项技术。这个模式下的集群会随机选出一个节点作为master，而当master节点挂了后，会从slave中自动选出一个节点升级成为master。
Dledger技术做的事情：1、接管Broker的CommitLog消息存储 2、从集群中选举出master节点 3、完成master节点往slave节点的消息同步。
Dledger的关键部分是在他的节点选举上。Dledger是使用Raft算法来进行节点选举的。这里简单介绍下Raft算法的选举过程:

首先：每个节点有三个状态，Leader，follower和candidate(候选人)。正常运行的情况下，集群
中会有一个leader，其他都是follower，follower只响应Leader和Candidate的请求，而客户端的
请求全部由Leader处理，即使有客户端请求到了一个follower，也会将请求转发到leader。
集群刚启动时，每个节点都是follower状态，之后集群内部会发送一个timeout信号，所有
follower就转成candidate去拉取选票，获得大多数选票的节点选为leader，其他候选人转为
follower。如果一个timeout信号发出时，没有选出leader，将会重新开始一次新的选举。而
Leader节点会往其他节点发送心跳信号，确认他的leader状态。
-- 然后会启动定时器，如果在指定时间内没有收到Leader的心跳，就会转为Candidate状态，然
后向其他成员发起投票请求，如果收到半数以上成员的投票，则Candidate会晋升为Leader。然
后leader也有可能会退化成follower。
然后，在Raft协议中，会将时间分为一些任意时间长度的时间片段，叫做term。term会使用一
个全局唯一，连续递增的编号作为标识，也就是起到了一个逻辑时钟的作用。

 在每一个term时间片里，都会进行新的选举，每一个Candidate都会努力争取成为leader。获
得票数最多的节点就会被选举为Leader。被选为Leader的这个节点，在一个term时间片里就会保
持leader状态。这样，就会保证在同一时间段内，集群中只会有一个Leader。在某些情况下，选
票可能会被各个节点瓜分，形成不了多数派，那这个term可能直到结束都没有leader，直到下一
个term再重新发起选举，这也就没有了Zookeeper中的脑裂问题。而在每次重新选举的过程中，
leader也有可能会退化成为follower。也就是说，在这个集群中， leader节点是会不断变化的。
然后，每次选举的过程中，每个节点都会存储当前term编号，并在节点之间进行交流时，都会
带上自己的term编号。如果一个节点发现他的编号比另外一个小，那么他就会将自己的编号更新
为较大的那一个。而如果leader或者candidate发现自己的编号不是最新的，他就会自动转成
follower。如果接收到的请求term编号小于自己的编号，term将会拒绝执行。
在选举过程中，Raft协议会通过心跳机制发起leader选举。节点都是从follower状态开始的，如
果收到了来自leader或者candidate的心跳RPC请求，那他就会保持follower状态，避免争抢成为
candidate。而leader会往其他节点发送心跳信号，来确认自己的地位。如果follower一段时间(两
个timeout信号)内没有收到Leader的心跳信号，他就会认为leader挂了，发起新一轮选举。
 选举开始后，每个follower会增加自己当前的term，并将自己转为candidate。然后向其他节点
发起投票请求，请求时会带上自己的编号和term，也就是说都会默认投自己一票。之后
candidate状态可能会发生以下三种变化：
赢得选举，成为leader： 如果它在一个term内收到了大多数的选票，将会在接下的剩余
term时间内称为leader，然后就可以通过发送心跳确立自己的地位。(每一个server在一个
term内只能投一张选票，并且按照先到先得的原则投出)
其他节点成为leader： 在等待投票时，可能会收到其他server发出心跳信号，说明其他
leader已经产生了。这时通过比较自己的term编号和RPC过来的term编号，如果比对方大，
说明leader的term过期了，就会拒绝该RPC,并继续保持候选人身份; 如果对方编号不比自己
小,则承认对方的地位,转为follower。
选票被瓜分,选举失败: 如果没有candidate获取大多数选票, 则没有leader产生, candidate们
等待超时后发起另一轮选举. 为了防止下一次选票还被瓜分,必须采取一些额外的措施, raft采
用随机election timeout(随机休眠时间)的机制防止选票被持续瓜分。通过将timeout随机设
为一段区间上的某个值, 因此很大概率会有某个candidate率先超时然后赢得大部分选票。
所以以三个节点的集群为例，选举过程会是这样的：
1. 集群启动时，三个节点都是follower，发起投票后，三个节点都会给自己投票。这样一轮投
票下来，三个节点的term都是1，是一样的，这样是选举不出Leader的。
2. 当一轮投票选举不出Leader后，三个节点会进入随机休眠，例如A休眠1秒，B休眠3秒，C休
眠2秒。
3. 一秒后，A节点醒来，会把自己的term加一票，投为2。然后2秒时，C节点醒来，发现A的
term已经是2，比自己的1大，就会承认A是Leader，把自己的term也更新为2。实际上这个
时候，A已经获得了集群中的多数票，2票，A就会被选举成Leader。这样，一般经过很短的
几轮选举，就会选举出一个Leader来。
4. 到3秒时，B节点会醒来，他也同样会承认A的term最大，他是Leader，自己的term也会更
新为2。这样集群中的所有Candidate就都确定成了leader和follower.
5. 然后在一个任期内，A会不断发心跳给另外两个节点。当A挂了后，另外的节点没有收到A的
心跳，就会都转化成Candidate状态，重新发起选举。
Dledger还会采用Raft协议进行多副本的消息同步：
简单来说，数据同步会通过两个阶段，一个是uncommitted阶段，一个是commited阶段。
Leader Broker上的Dledger收到一条数据后，会标记为uncommitted状态，然后他通过自己的
DledgerServer组件把这个uncommitted数据发给Follower Broker的DledgerServer组件。
接着Follower Broker的DledgerServer收到uncommitted消息之后，必须返回一个ack给
Leader Broker的Dledger。然后如果Leader Broker收到超过半数的Follower Broker返回的ack
之后，就会把消息标记为committed状态。
再接下来， Leader Broker上的DledgerServer就会发送committed消息给Follower Broker上的DledgerServer，让他们把消息也标记为committed状态。这样，就基于Raft协议完成了两阶
段的数据同步。
 

6 名字服务（Name Server）
名称服务充当路由消息的提供者。Broker Server会在启动时向所有的Name Server注册自己的服务信息，并且后续通过心跳请求的方式保证这个服务信息的实时性。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表。多个Namesrv实例组成集群，但相互独立，没有信息交换。
这种特性也就意味着NameServer中任意的节点挂了，只要有一台服务节点正常，整个路由服务就不会有影响。当然，这里不考虑节点的负载情况。

7 消息（Message）
消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题Topic。RocketMQ中每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能。
并且Message上有一个为消息设置的标志，Tag标签。用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。