RocketMq

1、MQ

1.1 简介

MQ，Message Queue，是一种提供消息队列服务的中间件，也称为消息中间件，是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据。一般消息的体量不会很大。

1.2 用途

1.2.1 解耦

作用

• 服务之间进行解耦，才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。
• 另外，解耦后可以实现数据分发。生产者发送一个消息后，可以由一个或者多个消费者进行消费，并且消费者的增加或者减少对生产者没有影响。
  

1.2.2 异步

例子：快递员发快递，直接到客户家效率会很低。引入菜鸟驿站后，快递员只需要把快递放到菜鸟驿站，就可以继续发其他快递去了。客户再按自己的时间安排去菜鸟驿站取快递。
作用

• 提供系统的响应速度
• 提高吞吐量
  同步模型
  异步模型
  

1.2.3 限流削峰

1.3 缺点

• 系统可用性降低
  系统引入的外部依赖增多，系统的稳定性就会变差。一旦 MQ 宕机，对业务会产生影响。这就需要考虑如何保证 MQ 的高可用。
• 系统复杂度提高
  引入 MQ 后系统的复杂度会大大提高。以前服务之间可以进行同步的服务调用，引入 MQ 后，会变为异步调用，数据的链路就会变得更复杂，并且还会带来其他一些问题。比如：如何保证消费不会丢失？不会被重复调用？怎么保证消息的顺序性等问题。
• 消息一致性问题
  A 系统处理完业务，通过 MQ 发送消息给 B 、 C 系统进行后续的业务处理。如果 B 系统处理成功， C 系统处理失败怎办？这就需要考虑如何保证消息数据处理的一致性。

1.4 常用MQ对比

Kafka 的吞吐量高达 17.3w/s，不愧是高吞吐量消息中间件的行业老大。这主要取决于它的队列模式保证了写磁盘的过程是线性 IO。此时 broker 磁盘 IO 已达瓶颈。
RocketMQ 也表现不俗，吞吐量在 11.6w/s，磁盘 IO %util 已接近 100%。RocketMQ 的消息写入内存后即返回 ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。
RabbitMQ 的吞吐量 5.95w/s，CPU 资源消耗较高。它支持 AMQP 协议，实现非常重量级，为了保证消息的可靠性在吞吐量上做了取舍。我们还做了 RabbitMQ 在消息持久化场景下的性能测试，吞吐量在 2.6w/s 左右。

2、初识RocketMQ

我们平时使用一些体育新闻软件，会订阅自己喜欢的一些球队板块，当有作者发表文章到相关的板块，我们就能收到相关的新闻推送。
发布-订阅（Pub/Sub）是一种消息范式，消息的发送者（称为发布者、生产者、Producer）会将消息直接发送给特定的接收者（称为订阅者、消费者、Comsumer）。而RocketMQ的基础消息模型就是一个简单的Pub/Sub模型。

2.1 相关概念

2.1.1生产者

负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。

2.1.2消费者

负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。

2.1.3主题

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

2.2 RocketMQ的基础消息模型，一个简单的Pub/Sub模型

在基于主题的系统中，消息被发布到主题或命名通道上。消费者将收到其订阅主题上的所有消息，生产者负责定义订阅者所订阅的消息类别。这是一个基础的概念模型，而在实际的应用中，结构会更复杂。例如为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个Topic会有多个生产者，同一个信息会有多个消费者，消费者之间要进行负载均衡等。

2.3 RocketMQ 扩展后的消息模型

扩展的消息系统模型
上图就是一个扩展后的消息模型，包括两个生产者，两个消息Topic，以及两组消费者 Comsumer。
存储消息Topic的 代理服务器( Broker )，是实际部署过程对应的代理服务器。

• 为了消息写入能力的水平扩展，RocketMQ 对 Topic进行了分区，这种操作被称为队列（MessageQueue）。
• 为了消费能力的水平扩展，ConsumerGroup的概念应运而生。

consumer group消费模式

• 相同的ConsumerGroup下的消费者主要有两种负载均衡模式，即广播模式，和集群模式
• 在集群模式下，同一个 ConsumerGroup 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅 TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue 1的消息，Consumer2是消费的是MessageQueue2的消息。
• 在广播模式下，同一个 ConsumerGroup 中的每个 Consumer 实例都处理全部的队列。需要注意的是，广播模式下因为每个 Consumer 实例都需要处理全部的消息，因此这种模式仅推荐在通知推送、配置同步类小流量场景使用。

1.4 RocketMQ的部署模型

2.4.1 producer

发布消息的角色。Producer通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。

2.4.2 consumer

消息消费的角色。

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

2.4.3 名字服务器 NameServer

NameServer是一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。
主要包括两个功能：

• Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
• 路由信息管理，每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。

NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。

2.4.4 代理服务器 Broker

Broker主要负责消息的存储、投递和查询以及服务高可用保证。
NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。Broker部署相对复杂。
在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

2.4.5小结

• 每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
• Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
• Consumer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。