Rocket MQ 详解

开这个专栏主要之前实习的时候经常用到Rocket MQ,大厂使用的也比较多，主要讲解一些关键原理和概念。

介绍

定义：分布式消息中间件。MQ是消息队列的意思。
特点：低延迟、高并发、高可用、高可靠。
解释一下“高可用”：通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。高可用，是消息队列 RocketMQ 跟其他的消息服务器的主要区别

核心概念

• Topic：消息主题，我理解为与特定主题任务相关的一类消息。是消息的第一级（最大）类型，比如交易消息，物流消息。
• 生产者：生产消息，发送消息
• 消费者：接受消息，并消费
• 消息：我理解为一个任务。有消息属性，即消息附带的业务相关的属性，比如key,tag/
• Group: 我理解为同一类具体生产者/消费者，使用同一个dag完成相同的工作。

核心特性

这里参考了此博客：原作者很多地方只点了一下，我在这里做补充说明。

添加链接描述
业务场景说明：
电商行业的下单业务场景，以最简单的下单流程来说，下单流程如下：

锁库存
创建订单
用户支付
扣减库存
修改订单状态
给用户发送购买短信通知
给用户增加积分
通知商家发货

异步解耦

下单之后，用户完成支付，此时有个逻辑叫做支付回调，即我们通常在dag中会使用feedback节点。
在这个回调里，包括上述后面几步：
1.扣减库存
2.修改订单状态
给用户发送购买短信通知
给用户增加积分
通知商家发货

那么问题来了，如果线性的跑这几个步骤需要5个阶段，但是其实对于用户来说，完成了1-2之后，后面三步作为用户本身并不需要关心顺序，他们只需要自由的完成即可，所以我们把这三步发送到rocket mq,让其广播任务，完成任务即可。

打个很简单的比方，你去餐厅吃饭，你只需要告诉服务员来一碗大碗宽面你就可以玩儿手机了，至于这个面怎么拉的，怎么煮的，汤怎么调的，怎么装盘的，这些你都不关心。

所以总体时间并没有变化，只是对于你来说，你直接参与的时间变短了很多

削峰

主要指在并发大流量的冲击下，利用Rocket MQ可以抗住瞬时流量，保护系统稳定
原理是我们把所有的任务都丢到队列中去，消费者尽自己可能的去消费消息就完事儿了，慢可能是慢了一点，起码我系统没有崩溃。（前提该业务得支持异步处理 ，我们知道一个dag中会有多个节点，每个节点的input &output是不一样的，当节点x完成之后产生了节点x+n的input，那这个时候x+n这个节点直接跑就是了，他不需要等他们两个中间的节点跑完才运行，因为逻辑上他们没有依赖关系）

消息幂等——重试导致重复

RocketMQ 的 Exactly-Once 投递语义，就是用于解决幂等问题。Exactly-Once 是指发送到消息系统的消息只能被消费端处理且仅处理一次，即使生产端重试消息发送导致某消息重复投递，该消息在消费端也只被消费一次。

最佳方法是通过不同的消息的ID来区分，但这样所有消费者都需要记录所有已经被消费的id。不合理。
幂等判度通过为每条消息设置一个MessageKey，唯一标识业务。
只有第一个MessageKey能够被消费。

消息过滤

我们说了Topic是消息的一级类型，比如订单topic，可能分为三个关于订单的模块。
创建订单，处理订单，取消订单。
通过给消息指定tag可以来区分消息类型，从而在Rocket MQ服务端过滤

Rocket MQ架构

几个主要组成部分的功能：

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