一 .RocketMQ简介

MQ简介

消息中间件有两种模型

队列模型 (RocketMQ)
主题模型（也叫发布订阅模型）(RabbitMQ)

RocketMQ

MQ（Message Queue）消息队列，是一种用来保存消息数据的队列
◆ 队列：数据结构的一种，特征为 “先进先出”
在这里插入图片描述

何为消息

服务器间的业务请求
- 原始架构：
  - 服务器中的A功能需要调用B、C模块才能完成
- 微服务架构
  - 服务器A向服务器B发送要执行的操作（视为消息）
  - 服务器A向服务器C发送要执行的操作（视为消息）

MQ作用

应用解耦(异步消息发送)
快速应用变更维护(异步消息发送)
流量削锋(异步消息发送)

MQ基本工作模式

在这里插入图片描述

MQ优缺点分析

优点（作用）
- 应用解耦
- 快速应用变更维护
- 流量削锋
缺点
- 系统可用性降低
- 系统复杂度提高
- 异步消息机制
  - 消息顺序性
  - 消息丢失
  - 消息一致性
  - 消息重复使用

MQ产品介绍

ActiveMQ：java语言实现，万级数据吞吐量，处理速度ms级，主从架构，成熟度高
RabbitMQ ：erlang语言实现，万级数据吞吐量，处理速度us级，主从架构，
RocketMQ ：java语言实现，十万级数据吞吐量，处理速度ms级，分布式架构，功能强大，扩展性强
kafka ：scala语言实现，十万级数据吞吐量，处理速度ms级，分布式架构，功能较少，应用于大数据较多
RocketMQ是阿里开源的一款非常优秀中间件产品，脱胎于阿里的另一款队列技术MetaQ，后捐赠给Apache基金会作为一款孵化技术，仅仅经历了一年多的时间就成为Apache基金会的顶级项目。并且它现在已经在阿里内部被广泛的应用，并且经受住了多次双十一的这种极致场景的压力（2017年的双十一，RocketMQ流转的消息量达到了万亿级，峰值TPS达到5600万）
解决所有缺点

二.MQ概念

RockMQ组成

RocketMQ主要由

NameServer（命名服务）
Broker（经纪人–消息服务）
Producer (消息生产者)
Consumer （消息服务者）四部分构成。

NameServer（命名服务）的功能

管理brokers：broker服务器启动时会注册到NameServer上，并且两者之间保持心跳监测机制，以此来保证NameServer知道broker的存活状态；
路由信息管理：每一台NameServer都存有全部的broker集群信息和生产者/消费者客户端的请求信息；

NameServer用于存储Topic、Broker关系信息, 功能简单，稳定性高。
多个NameService之间没有通信, 单台NameService宕机不影响其他
NameServer与集群; 即使整个Namesrv集群宕机，已经正常工作的
Producer, Consumer，Broker仍然能正常工作，但新起的Producer,
 Consumer，Broker就无法工作。

注意: nameServer压力不会太大, 平时主要的开销是在维持心跳和提供brock-topic的关系数据.但有一点需要注意，Broker向Namesr发心跳时，会带上当前自己所负责的所有Topic信息，如果Topic个数太多（万级别），会导致一次心跳中，就Topic的数据就几十M，网络情况差的话，网络传输失败，心跳失败，导致Namesrv误认为Broker心跳失败。

Broker（消息服务）

消息中转角色，负责存储消息，转发消息。

Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接及心跳，并会定时将Topic信息注册到NameServer，顺带一提底层的通信和连接都是基于Netty实现的。
Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型
官网上有数据显示：具有上亿级消息堆积能力，同时可严格保证消息的有序性。

Broker（消息服务）作用

负载均衡: Broker上存Topic信息，Topic由多个队列组成，队列会平均分散在多个Broker上，而Producer的发送机制保证消息尽量平均分布到所有队列中，最终效果就是所有消息都平均落在每个Broker上。
动态伸缩能力（非顺序消息）: Broker的伸缩性体现在两个维度：Topic, Broker。

Producer (消息生产者)

Producer启动时，

需要指定Namesrv的地址(通常会配置NameServer集群的域名)，从Namesrv集群中选一台建立长连接。
如果该Namesrv宕机，会自动连其他Namesrv。直到有可用的Namesrv为止。生产者每30秒从Namesrv获取Topic跟Broker的映射关系，更新到本地内存中。再跟Topic涉及的所有Broker建立长连接，每隔30秒发一次心跳。

RocketMQ提供三种发送方式：

同步：在广泛的场景中使用可靠的同步传输，如重要的通知信息、短信通知、短信营销系统等。
异步：异步发送通常用于响应时间敏感的业务场景，发送出去即刻返回，利用回调做后续处理。
一次性：一次性发送用于需要中等可靠性的情况，如日志收集，发送出去即完成，不用等待发送结果，回调等等

生产者端的负载均衡
生产者发送时，会自动轮询当前所有可发送的broker，一条消息发送成功，下次换另外一个broker发送，以达到消息平均落到所有的broker上。

Consumer（消息消费者）

消费客户端的连接方式和生产者类似。

消费者端的负载均衡

广播消费：每个消费者消费Topic下的所有队列。
集群消费：一个topic可以由同一个ID下所有消费者分担消费。
具体例子：假如TopicA有6个队列，某个消费者ID起了2个消费者实例，那么每个消费者负责消费3个队列。如果再增加一个消费者ID相同消费者实例，即当前共有3个消费者同时消费6个队列，那每个消费者负责2个队列的消费。

消费者端的负载均衡，就是集群消费模式下，同一个ID的所有消费者实例平均消费该Topic的所有队列。