RocketMQ的核心功能包括消息发送、消息存储（Broker）、消息消费，NameServer实现了各类元数据的管理。
主题：Topic ，消息主题，一级消费类型，生产者向其发送消息，消费者负责从topic接收消息并消费
生产者：消息发布者，负责生产并发送消息到Topic
消费者：也称为消息订阅者，负责从Topic接收并消费消息
消息：生产者或者消费者进行消息发送或者消费的主题，对于RocketMq来讲，消息就是字节数组。
NameServer的选择
客户端首先会生产一个随机数，然后再与 NameServer 节点数量取模，此时得到的就是所要连接的
节点索引，然后就会进行连接。如果连接失败，则会采用 round-robin 策略，逐个尝试着去连接其它节
点。
运行流程：RocketMq需要先启动NameServer再启动Rocket中的Broker，Broker在启动的时候向全部的NameServer注册，生产者在发送消息以前从NameServer中获取Broker服务器地址列表，而后根据负载均衡算法从列表中选择一台服务器进行消息发送。NameServer与每台Broker服务保持长连接，并间隔30s检查Broker是否存活，若是检查到Broker宕机（使用心跳机制，若是检测超过120s），则从路由注册表中将其剔除，保证其高可用。
用处：
（1）顺序消息：RocketMQ可以保证消息有序
（2）消息过滤：消费者能够对同一主题下的消息按照规则只消费本身感兴趣的消息，能够支持在服务端与消费端的消息过滤机制
（3）消息存储：RocketMQ核心就是消息的存储，对存储通常讲有两个维度：消息堆积能力和消息存储性能。RocketMQ最求消息的高性能，引入内存映射机制，全部的主题消息顺序存储在同一个文件中。同时防止无限堆积，引入消息文件过时机制和文件存储空间报警机制。
消息的高可用：断电、关机的情况下，RocketMq可以保证消息的不丢失（同步刷盘机制不丢失，异步刷盘少许丢失）
为了增强 Broker 性能与吞吐量， Broker 一般都是以集群形式出现的。各集群节点中可能存放着相同
Topic 的不同 Queue 。不过，这里有个问题，如果某 Broker 节点宕机，如何保证数据不丢失呢？其解决 方案是，将每个Broker 集群节点进行横向扩展，即将 Broker 节点再建为一个 HA 集群，解决单点问题。
Broker 节点集群是一个主从集群，即集群中具有 Master 与 Slave 两种角色。 Master 负责处理读写操作请 求，Slave 负责对 Master 中的数据进行备份。当 Master 挂掉了， Slave 则会自动切换为 Master 去工作。所 以这个Broker 集群是主备集群。一个 Master 可以包含多个 Slave ，但一个 Slave 只能隶属于一个 Master 。
Master 与 Slave 的对应关系是通过指定相同的 BrokerName 、不同的 BrokerId 来确定的。 BrokerId 为 0 表 示Master ，非 0 表示 Slave 。每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信 息到所有NameServer 。
版权声明：本文为weixin_43882788原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。