【主流技术】聊一聊消息队列 RocketMQ 的基本布局与概念 ...

目录

• 前言
  
• 一、初识 RocketMQ
  
  
  
  • 1.1基本模型
    
  
  
• 二、基本概念
  
  
  
  • 2.1Producer
    
  • 2.2Consumer
    
  • 2.3Topic
    
  • 2.4Tag
    
  • 2.5Message
    
  • 2.6Broker
    
  • 2.7Pull Consumer
    
  • 2.8Producer Group
    
  • 2.9Consumer Group
    
  • 2.10Ordered Message
    
  
  
• 三、高级特性
  
  
  
  • 3.1消息顺序
    
  • 3.2消息可靠性
    
  • 3.3延时队列
    
  • 3.4消息重试
    
  • 3.5死信队列
    
  
  
• 四、文章小结
  

前言

RocketMQ 是阿里巴巴在 2012 年开源的分布式消息中间件，目前已经捐赠给 Apache 软件基金会，并于 2017 年 9 月 25 日成为 Apache 的顶级项目。
作为经历过多次阿里巴巴双十一这种“超等工程”的洗礼并有稳定出色表现的国产中间件，以其高性能、低延时和高可靠等特性比年来已经也被越来越多的国内企业使用。
一、初识 RocketMQ

2011 年初，Linkin 开源了 Kafka 这个优秀的消息中间件，淘宝中间件团队在对 Kafka 做过充分 Review 之后，被 Kafka 无限消息堆积、高效的持久化速率等优点吸引了。
美中不足的的是，Kafka 主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满意。以是，阿里的中间件团队重新用 Java 语言编写了 RocketMQ ，定位于全场景的可靠消息传输。
目前 RocketMQ 在阿里集团的应用生态里被广泛应用于订单、交易、充值、物流、消息推送、日志处理， binglog 分发等场景。
RocketMQ 对比 Kafka，虽然设计的头脑上有鉴戒，但在架构上做了减法，在功能上做了加法：

• 去掉 Zookeeper，使用 NameServer 来管理 Broker 集群，通信更方便；
  
• 有延时队列和死信队列，开箱即用，减化代码逻辑实现。
  

1.1基本模型

RocketMQ 主要由 Producer、Broker、Consumer 三部门组成。其中，Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。

基本模型而 Broker 在实际部署过程中对应的是一台服务器，每个 Broker 可以存储多个 Topic 的消息，每个Topic 的消息也可以分片存储于差别的 Broker。Message Queue 用于存储消息的物理地点，每个 Topic 中的消息地点都会存储在多个 Message Queue 中。
ConsumerGroup 由多个Consumer 实例构成。
二、基本概念

以下的基本概念是明白和掌握 RocketMQ 最基础的概念，也是最紧张的概念。现在不明白没有关系，先记住有个印象，后续使用的时间，兴许能资助你豁然开朗。
2.1Producer

消息生产者（Producer）负责生产消息，一般由业务系统负责生产消息。
一个消息生产者会把业务应用系统里产生的消息（封装好的消息体）发送到 Broker 服务器。RocketMQ 提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。其中，同步和异步方式均需要 Broker 返回确认信息（即Ack），单向发送不需要。
2.2Consumer

消息消费者（Consumer）负责消费消息，一般是由下游的系统负责异步消费。
一个消息消费者会从 Broker 服务器默认主动拉取（Pull 模式）消息，并将其提供给应用步伐。从用户应用的角度而言提供了两种消费形式：拉取式消费（默认 Pull 模式）、推动式消费。
2.3Topic

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

2.4Tag

标签（Tag）为消息设置的标记，用于同一 Topic 下区分差别类型的消息。来自同一业务单位的消息，可以根据差别业务的功能模块在同一主题下设置差别的标签。标签可以或许有用地保持代码的清晰度和连贯性，并优化 RocketMQ 提供的查询系统。消费者可以根据 Tag 实现对差别子主题的差别消费逻辑，实现更好的扩展性。
2.5Message

消息（Message）是系统所传输信息的物理载体、生产和消费数据的最小单位，每条消息必须属于某一个主题。RocketMQ 中的每条消息都拥有唯一的 Message ID 作为标识，且可以携带具有业务标识的 Key。系统提供了通过 Message ID 和 Key 查询消息的功能。
2.6Broker

署理服务器（Broker）是消息中转角色，负责存储消息、转发消息。署理服务器在 RocketMQ 系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。署理服务器也存储消息相关的元数据，包罗消费者组、消费进度偏移和主题和队列消息等。
2.7Pull Consumer

拉取式消费（Pull Consumer）是 Consumer 消费的一种类型，也是默认的类型。下游应用系统通常主动调用 Consumer 的拉消息方法从 Broke r服务器拉消息，即主动权由下游应用控制。一旦获取了批量消息，应用就会启动消费过程。

2.8Producer Group

生产者组（Producer Group）是同一类 Producer 的集合，这类 Producer 发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则 Broker 服务器会接洽同一生产者组的其他生产者实例重试提交或回溯消费。
2.9Consumer Group

消费者组（Consumer Group）是同一类 Consumer 的集合，这类 Consumer 通常消费同一类消息且消费逻辑一致。消费者组使得在消息过程中实现负载平衡和进步容错变得非常容易。要注意的是，消费者组的每个消费者实例必须订阅完全雷同的 Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。
2.10Ordered Message

顺序消息分为平凡顺序消费（Normal Ordered Message）和严格顺序消息（Strictly Ordered Message）。
平凡顺序消费（Normal Ordered Message）下的消费者通过同一个消息队列（Message Queue） 收到的消息是有顺序的，差别消息队列收到的消息则可能是无顺序的。
而在严格顺序消息（Strictly Ordered Message）模式下，消费者收到的全部消息均是严格有序的。
三、高级特性

3.1消息顺序

消息有序指的是一类消息消费时，能按照发送的顺序来消费，RocketMQ 可以严格的保证消息有序。

例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才气故意义，但是同时订单之间是可以并行消费的。
顺序消息分为全局顺序消息与分区顺序消息，全局顺序是指某个 Topic 下的全部消息都要保证顺序，部门顺序消息只要保证每一组消息被顺序消费即可。

• 全局顺序
  
  
  
  • 对于指定的一个 Topic，全部消息按照严格的先进先出（FIFO）的顺序进行发布和消费。
    
  • 实用场景：性能要求不高，全部的消息严格按照 FIFO 原则进行消息发布和消费的场景。
    
  
  
• 分区顺序
  
  
  
  • 对于指定的一个 Topic，全部消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分差别分区的关键字段，和平凡消息的 Key 是完全差别的概念。
    
  • 实用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。
    
  
  

3.2消息可靠性

RocketMQ 支持消息的高可靠，以下是影响消息可靠性的 6 种环境：

• Broker 非正常关闭
  
• Broker 异常 Crash
  
• OS Crash
  
• 机器掉电，但是能立即恢复供电环境
  
• 机器无法开机（可能是 cpu、主板、内存等关键装备损坏）
  
• 磁盘装备损坏
  

其中上述的1、2、3、4 这四种环境都属于硬件资源可立即恢复的环境，RocketMQ 在这四种环境下能保证消息不丢失，或者丢失少量数据（取决于刷盘方式是同步照旧异步）。
而5、6这两点属于单点故障，无法恢复，一旦发生，在此单点上的消息会全部丢失。
RocketMQ 在这两种环境下，通过异步复制可保证 99% 的消息不丢失，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，得当对消息可靠性要求极高的场所，例如与订单、支付等相关的应用。注：RocketMQ 从 3.0 版本开始支持同步双写。
3.3延时队列

耽误队列是指消息发送到 Broker 后，不会立即被消费，等候特定时间后才会投递给真正的 Topic。
Broker 有设置项 messageDelayLevel，默认值为：1s、5s、10s、30s、1min、2min、3min、4min、5min、6min、7min、8min、9min、10min、20min、30min、1h、2h 这 18 个 level。
也可以设置自定义 messageDelayLevel ，注意：messageDelayLevel 是 Broker 的属性，不属于某个 Topic。
发消息时，设置 delayLevel 品级即可：msg.setDelayLevel(level)。level 有以下 3 种环境：
<ul>level == 0，消息为非耽误消息
1