RocketMQ基础

RocketMQ简介

定义

MQ全称为Message Queue，即消息队列 ，是一种提供消息队列服务的中间件，也称为消息中间件，是一套提供了消息生产、存储、消费全过程的软件系统，遵循FIFO原则。RocketMQ是一个统一消息引擎、轻量级数据处理平台。

为什么用

1.高并发请求在MQ中排队，达到了消除峰值的目的，不会有大量的请求同时怼到支付系统

2.服务异步调用，响应时间很快

3.服务彻底解耦，即使支付服务挂掉，也不影响“天府通出站API”正常工作，当支付系统再启动仍然可以继续消费MQ中的消息。

使用场景

消除峰值

MQ可以将系统的超量请求暂存其中，以便系统后期可以慢慢进行处理，从而避免了请求的丢失或系统 被压垮。

异步&解耦

上游系统对下游系统的调用若为同步调用，则会大大降低系统的吞吐量与并发度，且系统耦合度太高。 而异步调用则会解决这些问题。所以两层之间若要实现由同步到异步的转化，一般性做法就是，在这两层间添加一个MQ层。 即使消费者挂掉也不影响生产者工作，只要把消息放入队列即可，消费者重启后自己消费即可。

数据收集

分布式系统会产生海量级数据流，如：业务日志、监控数据、用户行为等。针对这些数据流进行实时或 批量采集汇总，然后对这些数据流进行大数据分析，这是当前互联网平台的必备技术。通过MQ完成此 类数据收集是最好的选择。

大数据处理

比如我们的平台向“三方平台”获取数据，一次请求了大量数据回来要进行处理，由于数据较多处理不过来，那么就可以放入MQ，再创建一些消费者进行数据处理即可。

MQ好处

提高系统响应速度-异步执行

任务异步处理。 将不需要同步处理的并且耗时长的操作由消息队列通知消息接收方进行异步处理。提高了应用程序的响应时间。

提高系统稳定性-消峰,解耦

一是并发被消峰后，系统不容易被高并发打垮，二是系统挂了也没关系,操作内容放到消息队列不丢失，后续重新消费者一样能消费做业务处理。 

排序保证 FIFO

遵循队列先进先出的特点，能够保证消息按照添加的数据被消费。

RocketMQ优点

支持集群模型、负载均衡、水平扩展能力 

亿级别消息堆积能力

采用零拷贝的原理，顺序写盘，随机读 -nio,零拷贝

底层通信框架采用Netty NIO - nio通讯模型---Netty -redis-kafaka/rocketmq

NameServer代替Zookeeper，实现服务寻址和服务协调

消息失败重试机制、消息可查询 

强调集群无单点，可扩展，任意一点高可用，水平可扩展 

经过多次双十一的考验

RocketMQ存储结构

Commitlog : 消息是存储写在commitlog目录中，一mapperdFile文件顺序存储消息。

Config : 存放运行期间的配置文件

Consumerqueue : 该目录中存放的是队列，consume queue存放着commitlog中的消息的索引位置

Index :存放着消息索引文件 indexFile，用来实现根据key进行消息的快速查询

Abort : 该文件在broker启动后自动创建，正常关闭abort会消失

Checkpoint ：记录 Commitlog ，Consumerqueue 和index 文件的最后刷盘时间戳

RocketMQ原理

RocketMQ架构

Producer

消息发布的角色，支持分布式集群方式部署。Producer通过nameserver的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。

Consumer

消息消费的角色，支持分布式集群方式部署。支以push推，pull拉两种模式对消息进行消费。同时    也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。

Broker

Broker主要负责消息的存储、投递和查询以及服务高可用保证。

NameServer

Broker管理

NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制检查Broker是否还存活。

路由信息管理

每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费

RocketMQ工作原理

1.启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。

2.Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。

3.收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。

4.Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。

5.Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息

RocketMQ核心概念

Producer 生产者

RocketMQ提供多种发送方式，`同步发送、异步发送、顺序发送、单向发送`。同步和异步方式均需要Broker返回确认信息，单向发送不需要。
RocketMQ中的消息生产者都是以生产者组（Producer Group）的形式出现的。生产者组是同一类生产者的集合，这类Producer发送相同Topic类型的消息。一个生产者组可以同时发送多个主题的消息。
Producer会使用一定的算法(随机轮询+规避故障)选择把消息发送到哪个master的某个queue中。

Consumer 消费者

Consumer 支持两种消费形式：拉取式消费、推动式消费。（主动，被动），RocketMQ中的消息消费者都是以消费者组（Consumer Group）的形式出现的。消费者组是同一类消费者的集合，这类Consumer消费的是同一个Topic类型的消息，不同的 Consumer Group可以消费同一个Topic。

Topic 消息主题

Topic表示一类消息的集合，每个topic主题包含若干条message消息，每条message消息只能属于一个topic主题，Topic是RocketMQ进行消息订阅的基本单位。

Message

消息是指消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题(topic)。

Tag 标签

为消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。Topic是消息的一级分类，Tag是消息的二级分类

MessageQueue

在集群模式下, 在一个Consumer Group内，一个Queue最多只能分配给一个Consumer，一个Cosumer可以分配得到多个Queue。这样的分配规则，每个Queue只有一个消费者，可以避免消费过程中的多线程处理和资源锁定，有效提高各Consumer消费的并行度和处理效率。

MessageId/Key

RocketMQ中每个消息拥有唯一的MessageId，且可以携带具有业务标识的Key，以方便对消息的查询。 不过需要注意的是，MessageId有两个：在生产者send()消息时会自动生成一个MessageId（msgId)， 
当消息到达Broker后，Broker也会自动生成一个MessageId(offsetMsgId)。msgId、offsetMsgId与key都称为消息标识。

Rebalance重新负载

当消费者数量或者Queue的数量修改，Rebalance是把⼀个Topic下的多个Queue重新分配给Consumer Group下的Consumer。目的是增加消费能力。由于一个队列值分配给一个Consumer,那么当Consumer Group中的消费者数量大于队列数量，那么多出来的Consumer分配不到队列。

消息拉取模式

pull

拉取式，需要消费者间隔一定时间就去遍历关联的Queue,实时性差但是便于应用控制消息的拉取

push

推送式，封装了Queue的遍历，实时性强，但是对系统资源占用比较多。

消息消费模式

广播模式(一对多):同一个Consumer Group 下的所有Consumer都会收到同一个Topic的所有消息。同一个消息可能会被消费多次。

集群模式(一对一):同一个Gonsumer Group 下的Consumer平分同一个Topic下的消息。同一个消息只是被消费一次。

Queue的分配算法

平均分配【默认】：根据 qeueuCount (4)/ consumerCount (3)作为每个消费者平均分配数量，如果多出来的queue就再依次逐个分配给Consumer。 

环形平均策略：根据消费者的顺序，一个一个的分配Queue即可类似于发扑克牌

一致性Hash策略 ： 该算法将Consumer的Hash值作为节点放到Hash环上，然后将Queue的hash值也放入Hash环上，通过顺时针进行就近分配。

同机房策略：该算法会根据queue的部署机房位置和consumer的位置，过滤出当前consumer相同机房的queue。然后按照平均分配策略或环形平均策略对同机房queue进行分配。如果没有同机房queue，则按照平均分配策略或环形平均策略对所有queue进行分配。

Offset管理

远程Offset管理:Brocker通过 store/config/consumerOffset.json 文件以JSON方式来存储offset相关数据以json的形式：适用于集群模式

本地Offset管理：offset相关数据以json的形式持久化到Consumer本地磁盘文件中，路径为当前用户主目录下的.rocketmq_offsets/${clientId}/${group}/Offsets.json ：适用于广播模式

消息的清理

1.到达时间清理点，自动清理过期的文件(凌晨4点)

2.磁盘空间使用率达到了过期清理阈值(75%),自动清理过期的文件。

3.磁盘占用率达到清理阈值(85%)，开始按照设定的规则清理文件，从老的文件开始。

4.磁盘占用率达到系统危险阈值(90%),拒绝写入数据。