1.应用场景

1.1.RocketMQ应用场景

RocketMQ 是阿里巴巴开源的分布式消息中间件，前身为阿里内部消息系统Notify及MetaQ。RocketMQ被广泛应用于电商、订单、金融等分布式应用领域，其主要特点和应用场景如下：
RocketMQ主要特点：

• 金融级别可靠性
• 高性能及大量数据存储
• 低延迟消费
• 事务消息、顺序消息
• 定时消息
• 重试队列及死信队列
  RocketMQ主要应用场景：
• 系统解耦、削峰、异步化（金融级应用）
• 电商、订单、金融、秒杀、库存等应用间消息传递

1.2.Kafka应用场景

Kafka作为一款热门的消息队列中间件，具备高效且较可靠的消息异步传递机制，主要用于不同系统间的数据交流和传递，在企业解决方案、金融支付、电信、电子商务、社交、即时通信、视频、物联网、车联网等众多领域都有广泛应用，其主要特点和应用场景如下：
Kafka主要特点：
Kafka最早设计的目的是作为LinkedIn的活动流和运营数据的处理管道。这些数据主要是用来对用户做用户画像分析以及服务器性能数据的一些监控，所以Kafka一开始设计的目标就是作为一个分布式、高吞吐量的消息系统，所以适合运用在大数据传输场景。

• 高性能
• 高吞吐
• 海量数据处理
• 海量数据存储
  Kafka主要应用场景：
  主要围绕的特点就是“高吞吐、大数据、海量数据存储”这三个特点来进行选型。
• 系统解耦、削峰、异步化（海量数据级应用）
• 实时流式消息处理
• 实时日志系统
• 实时监控系统
• 大规模分析、爬虫
• 大规模模型训练

2.架构组成

2.1.RocketMQ架构组成

核心概念：

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

• Queue：一个Topic下存在一个或多个Queue，和Kafka中的Partition语义一致，每个Message会被发送到Topic的一个Queue中。Queue的作用是对Topic下的消息负载均衡。

• Tag：RocketMQ特有，一个Topic可含有多个Tag，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签，比如订单消息中可区分为取消订单消息和下单消息，可以分为两个Tag来订阅。

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

• Producer：负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。

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

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

• Name Server：名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表。多个Namesrv实例组成集群，但相互独立，没有信息交换。

• Pull Model：Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。

• Push Model：Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高。

• Producer Group：同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

• Consumer Group：同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

• OffSet：一般指某个消费者消费到某个Topic下Queue的偏移量，通过这个偏移量继续往后消费。需要注意的是，RocketMQ或Kafka是不会在消费消息后把消息删除的，而是保存一定时间，比如RocketMQ默认来说对以Broker集群为单位的持久化是2天，而Kafka可以设置单个Topic的消息持久化时间，默认为全局7天。
  以下是1个Topic含有5个Queue，并且有一个消费组含有2个消费者实例的消费情况：
  

每个消费者可以消费多个Queue，但是一个Queue只能被一个消费者消费，这样可以做到Queue内的消息严格有序消费，假如消费组含有6个实例，那么多余的1个消费者将空闲，所以最优情况下，Queue的数量=所有消费组中消费者的数量，做到1对1消费。

• Clustering：集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息，假如需要有两个业务，同时消费topic的全量数据，那么可以多启动一个消费组，不同消费组之间的消费进度不互相影响，独立维护OffSet。
  

• Broadcasting：广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息，一般不会使用这个广播模式，因为一类业务通常由一个消费组为单位消费，而不是以一个消费者为单位消费。
  

整体架构：

RocketMQ的架构中不存在Zookeeper这种外部注册中心，而是自行实现了NameS而ver，方便管理。

• BrokerServer：Broker主要负责消息的存储、投递和查询以及服务高可用保证
• NameServer：NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。
• Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
• Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。

2.2.Kafka架构组成

RocketMQ的架构和概念很多来自于Kafka，所以这里不再详细展开说明。
核心概念：

• Producer
  Producer即消息的生产者，它负责创建消息，然后将其投递到Kafka中。
• Consumer
  Consumer即消息等消费者，它连接到Kafka中并且获取消息，进行相应的业务处理。
• Broker
  Broker即服务代理节点（集群），用以处理消息。对于Kafka而言，Broker可以简单地看作一个独立的Kafka实例节点，但一般将其视为Kafka的集群，它里面由许多个服务代理节点broker组成。
• Zookeeper
  Zookeeper的作用是管理Broker集群的元数据及Leader选举。在Kafka 3.0之后预计完全移除对Zookeeper的依赖，而是基于Raft协议，“kafka on kafka”的模型来保存集群元数据及Leader选举。
  

5.Topic
Topic即消息主题。生产者和消费者面向主题投递消息和消费消息 。
6.Partition
Partition即消息分区。每个Topic都含有若干个分区用以存储消息，同一主题的不同分区可以存储在不同的broker中。由于消息的写入会追加到分区尾部，所以Kafka的消息有序性是依赖分区等有序性来实现的，和RocketMQ的Queue是一个作用。
整体架构：