一、RocketMQ简介
RocketMQ是阿里巴巴开源Apache项目，功能强大的分布式消息中间件，经过阿里巴巴双十一考验。
Rocketmq在高可用、高性能、负载均衡的系统设计上比较出众，主要特性有：
多 主多 从架构，高版本支持主从切换
消息负载均衡和水平 扩展
Netty 高性能网络通信
轻量级 NameServer 进行消息路由
高性能的消息存储机制
支持消息发送和消费重试
支持 顺序消息和事务 消息
支持 消息 轨迹查询和消息回溯
….....
二、消息生产消费概览
Topic
1. Topic是消息的逻辑概念，可配置多个队列，关联到多个Broker，增加消息的并行度
2. Broker上Topic的同一队列，只分配给一个Consumer， 而Cosumer可消费一个Topic的多个队列（集群消费方式）
3.Topic关联指定的Broker，其中master负责消息读写，slave只可读
4.各Broker会定时同步更新Topic信息到全部NameServer
三、Consumer
1.消费方式：
集群消费（消息被consumerGroup中任一consumer消费，默认方式）
广播消费（消息被consumerGroup中各consumer消费）
2.消息拉取方式
Pull模式：Consumer端自主控制拉取消息，并本地保存消费进度
Push模式：默认模式。封装了Pull模式，通过消息拉取服务从订阅的消息队列中拉取消息，然后分发给消费者处理，再更新消费进度到服务端
3.消费处理模式
ConsumeMessageConcurrentlyService：并行消费处理
ConsumeMessageOrderlyService：顺序消费处理
4.consumerGroup
消费者组，标识Topic的一类Consumer集合。同一consumerGroup下的各实例共同消费Topic的消息
5.订阅Topic
Consumer启动时订阅了消息Topic、相应重试主题（%RETRY%+消费组名）
6.消息过滤
示例：tags={a || b || c}
四、消息拉取和消费流程
PullMessageService: 消息拉取服务线程。
1.从pullRequestQueue获取pullRequest，不断从 Broker 拉取消息到ProcessQueue
消息拉取结果状态：有消息、无新消息、无匹配消息、偏移量不合法(异常情况)
2.将拉取的消息提交消费任务到 ConsumeMessageService，封装成ConsumeRequest提交消费线程池
消息拉取
对push模式的consumer，消息拉取分3个主要步骤：
1.消息拉取客户端消息拉取请求封装
2.消息服务器查找并返回符合条件的消息
3.消息拉取客户端处理返回的消息，Consumer处理完后会接着发送请求到Broker拉取下一批消息，拉取间隔时间默认是0
限流场景：
放弃本次拉取消息的动作，并且这个队列下次拉取任务，将在50ms后才加入到消息拉取队列
1. 消息处理总数：当前ProcessQueue正在处理的消息数量超过 pullThresholdForQueue=1000
2. 消息总大小：当前ProcessQueue正在处理的消息大小不超过 pullThresholdSizeForQueue=100M
3. 消费间隔：并发消费时处理队列最大跨度，队列中最大和最小偏移量差距超过 consumeConcurrentlyMaxSpan=2000时。设计原因：部分消息可能阻塞无法推进进度
消息并发消费：
ConsumeRequest线程的处理方法：
1，判断proccessQueue如果被废弃直接返回，不再消费消息
2，调MessageListenerConcurrently 监听器的 consumeMessage 方法消费消息，返回消费结果
拿到msgList处理流程：将本次拉取的消费按照设置的批量消费批次大小（默认为1）进行划分，然后提交至消费线程池，等待被消费
3.处理消费结果processConsumeResult
如果ProcessQueue的droped为false，若消费不成功则发回消息重试。然后更新offset
如果ProcessQueue的droped为true，不处理结果，不更新 offset(但其实消费端是消费了消息，这种情况有被重复消费的风险)
消息进度更新：
consumerOffset：消费位移，标记consumerGroup在一个队列的消费进度
Push模式消费进度，除定时持久化，拉取消息等操作也进行消费进度持久化
1. Consumer消费进度先保存在内存，定时10s上传Broker;
2. Broker中消费进度先保存在内存，定时持久化到消费进度文件
以上消费流程还涉及到消费重试等，将另写文章介绍。
