文章目录
一、Apache RocketMQ 核心组件介绍
Apache RocketMQ是一个分布式、队列模型的消息中间件，具有低延迟、高性能和高可靠、万亿级容量和灵活的可扩展性。核心组件由四部分组成：
- Name Servers
- Brokers
- Producer
- Consumer
它们中的每一个都可以水平扩展，而没有单一的故障节点
1.1 NameServer
重要：主要负责对于源数据的管理，包括了对于Topic和路由信息的管理。
是一个几乎无状态的节点，可集群部署，节点之间无任何信息同步。其角色类似Dubbo中的Zookeeper，由于NameServer集群间无状态，所以比Zookeeper更加轻量级
平时主要开销是在维持心跳和提供Topic-Broker的关系数据。
1.2 Broker
消息中转角色，负责存储消息，转发消息。
部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slaver，但是一个Slaver只能对应一个Master，Master与Slaver的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slaver。Master可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有的NameServer
负责存储数据，也是生产中压力最大的地方
1.3 Producer
负责生产数据。
与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Produce完全无状态，可集群部署
RocketMQ 提供了三种方式发送消息：同步、异步和单向
只能发送把数据推送到Broker-Master中，不推送到Broker-Slave。
1.4 Consumer
负责消费数据
与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、Slaver建立长连接，且定时向Master、Slaver发送心跳。Consumer即可从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定
Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制
二、Apache RocketMQ 核心概念
2.1 Producer(生产者)
producer将业务应用程序系统生成的消息发送给broker。
RocketMQ提供了多种发送范例:同步、异步和单向。
2.1.1 Producer Group（生产组）
同一角色的producer被分组在一起。broker可能会与同一生产者组的不同生产者实例联系，以提交或回滚事务，以防原始生产者在事务之后崩溃。
警告:考虑到所提供的producer在发送消息方面足够强大，每个producer组只允许一个实例，以避免不必要的producer实例初始化。
2.2 Consumer（消费者）
consumer从broker获取消息并将其提供给应用程序。在用户应用方面，提供了两种类型的消费者:
2.2.1 PullConsumer（主动消费者）
主动地从broker获取消息。一旦获取了批量消息，用户应用程序就会启动消费进程。
2.2.2 PushConsumer（被动消费者）
另一方面，推送消费者封装消息提取、使用进度和维护内部的其他工作，将一个回调接口留给最终用户来实现，该接口将在消息到达时执行。
2.2.3 Consumer Group（消费者组）
与前面提到的生产者组类似，将具有完全相同角色的消费者分组在一起并命名为消费者组。
使用者组是一个很好的概念，在消息消费方面，实现负载平衡和容错的目标非常容易。
警告:使用者组的使用者实例必须具有完全相同的主题订阅。
2.3 Topic（主题）
topic是一个类别，producer在其中传递消息，而consumer在其中提取消息。主题与生产者和消费者之间的关系非常松散。
具体地说，一个主题可以有零个、一个或多个发送消息给它的生产者;相反，生产者可以发送不同主题的消息。
从消费者的角度来看，一个主题可以由零个、一个或多个消费者组订阅。消费者组也可以订阅一个或多个主题，只要该组的实例保持订阅一致。
2.4 Message（消息）
message是要传递的信息。邮件必须有一个主题，可以解释为您的信件的邮寄地址。
消息还可以有一个可选的标记和额外的（key-value）键-值对。例如，您可以为消息设置业务键，并在代理服务器上查找消息，以诊断开发期间的问题。
2.4.1 Message Queue（消息队列）
主题被划分为一个或多个子主题，即“消息队列”。特别一提，queue类似kafka的Partition（分区）
2.5 Tag（标志，也称为二级主题）
标签，也就是子主题，为用户提供了额外的灵活性。对于标记，来自同一个业务模块的具有不同目的的消息可能具有相同的主题和不同的标记。标记将有助于保持代码的整洁和一致，并且标记还可以促进RocketMQ提供的查询系统。
2.6 Broker（委托者，消息存储的地方，也是压力最大的地方）
Broker是RocketMQ系统的主要组件。它接收来自生产者的消息，存储它们并准备处理来自消费者的拉请求。
它还存储消息相关的元数据，包括消费者组、消费进度偏移量和主题/队列信息。
2.7 Name Server（名称服务器，对于Topic和路由信息的管理）
Name Server（名称服务器）作为路由信息提供者。生产者/消费者客户端查找主题以查找相应的代理列表
2.8 Message Model（消息模式）
-
Clustering （集群）
-
Broadcasting （广播）
2.9 Message Order（消息顺序）
当使用DefaultMQPushConsumer时，您可以决定有序地或同时地使用消息。
2.9.1 Orderly（有序的）
有序地使用消息意味着消息的使用顺序与生产者为每个消息队列发送消息的顺序相同。如果您正在处理全局顺序是强制的场景，请确保您使用的主题只有一个消息队列。
警告:如果指定了消费顺序，则消息消费的最大并发性是消费组订阅的消息队列的数量。
2.9.2 Concurrently（并发的）
当并发地使用消息时，消息使用的最大并发性仅受为每个使用者客户端指定的线程池的限制。
警告:在此模式下不再保证消息顺序。
三、面试常见问题分析
3.1 RocketMQ优点
• 支持事务型消息（消息发送和DB操作保持两方的最终一致性，rabbitmq和kafka不支持）
• 支持结合rocketmq的多个系统之间数据最终一致性（多方事务，二方事务是前提）
• 支持18个级别的延迟消息（rabbitmq和kafka不支持）
• 支持指定次数和时间间隔的失败消息重发（kafka不支持，rabbitmq需要手动确认）
• 支持consumer端tag过滤，减少不必要的网络传输（rabbitmq和kafka不支持）
• 支持重复消费（rabbitmq不支持，kafka支持）
3.2 RocketMQ缺点
• 支持的客户端语言不多，目前是java及c++，其中c++不成熟
• 社区活跃度不是特别活跃那种
• 没有在 mq 核心中去实现JMS等接口，有些系统要迁移需要修改大量代码