RocketMQ 是阿里巴巴在 2012 年开源的消息队列产品，后来捐赠给 Apache 软件基金会，2017 正式毕业，成为 Apache 的顶级项目。
阿里内部也是使用 RocketMQ 作为支撑其业务的消息队列，经历过多次“双十一”考验，它的性能、稳定性和可靠性都是值得信赖的。
优点
- 性能高
就是前面在文件存储机制中所提到的：RocketMq采用文件系统存储消息，采用顺序写的方式写入消息，使用零拷贝发送消息，这三者的结合极大地保证了RocketMq的性能
- 能够保证严格的消息顺序
- 提供丰富的消息拉取模式
支持拉（pull）和推（push）两种消息模式 （Push好理解，比如在消费者端设置Listener回调；而Pull，控制权在于应用，即应用需要主动的调用拉消息方法从Broker获取消息，这里面存在一个消费位置记录的问题（如果不记录，会导致消息重复消费））RocketMQ的Consumer获取消息是通过向Broker发送拉取请求获取的，而不是由Broker发送Consumer接收的方式。
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
- RocketMQ 有非常活跃的中文社区
- RocketMQ 使用 Java 语言开发，很容易对 RocketMQ 进行扩展或者二次开发。
单一队列百万消息的堆积能力
RocketMQ的通信模块是建立在Netty基础之上
在Metaq1.x/2.x的版本中，分布式协调采用的是Zookeeper，而RocketMQ自己实现了一个NameServer，更加轻量级，性能更好！
架构图
NameServer
负责管理所有的Broker消息
为 producer 和 consumer 提供路由信息。
部署多台，保证高可用性。
Broker 实现数据多副本存储和高可用，使用 主从架构
生产者 向MQ发送消息
消费者 从MQ获取消息
如何集群化部署来支撑高并发访问？
系统的流量分散在RocketMQ部署的多台机器上
问2：RocketMQ如何分布式存储海量消息的？答：
RocketMQ进程一般称为Broker，集群部署的各个Broker收到不同的消息，然后存储在自己本地的磁盘文件中。
问3： 任何一台 Broker 突然宕机了怎么办？那不就会导致 RocketMQ 里一部分的消息就没了吗？这就会导致 MQ 的不可靠和不可用，这个问题怎么解决？
RocketMQ的解决思路是Broker主从架构以及多副本策略。
Master收到消息后会同步给Slave，这样一条消息就不止一份了，Master宕机了还有slave中的消息可用，保证了MQ的可靠性和高可用新。
问4： 怎么知道有哪些 Broker ？怎么知道要连接到哪一台 Broker 上去发送和接收消息？
答：
每个Broker向所有的NameServer上注册自己的信息，NameServer就知道集群里有哪些Broker了!
发送消息到Broker，会找NameServer去获取路由信息
系统要从Broker获取消息，也会找NameServer获取路由信息，去找到对应的Broker获取消息。
Broker会定时（30s）向NameServer发送心跳
然后 NameServer会定时（10s）运行一个任务，去检查一下各个Broker的最近一次心跳时间，如果某个Broker超过120s都没发送心跳了，那么就认为这个Broker已经挂掉了。
Broker挂掉不会实时感知，所以存在发送消息和消费消息失败的情况，生产者有 一套容错机制的。
消费收发模型
发布/订阅模型，消息生产者发送消息到 Topic。消费者订阅Topic从其接收消息。
可以是一对多、多对一和多对多。 
通过Group机制，让RocketMQ天然的支持消息负载均衡！比如某个Topic有9条消息，其中一个Consumer Group有3个实例（3个进程 OR 3台机器），那么每个实例将均摊3条消息！（注意RocketMQ只有一种模式，即发布订阅模式。???疑问）
名词解析
Broker
Broker 是 RocketMQ 系统的主要角色，其实就是前面一直说的 MQ。Broker 接收来自生产者的消息，储存以及为消费者拉取消息的请求做好准备。
Topic
Topic 是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。
Tag
标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
Message
Message 是消息的载体。一个 Message 必须指定 topic，相当于寄信的地址。Message 还有一个可选的 tag 设置，以便消费端可以基于 tag 进行过滤消息。
也可以添加额外的键值对，例如你需要一个业务 key 来查找 broker 上的消息，方便在开发过程中诊断问题。
消息属性：生产者可以为消息定义的属性，包含 Message Key 和 Tag。
同一个消费者 Group ID 下所有 Consumer 实例的处理逻辑必须完全一致。
一旦订阅关系不一致，消息消费的逻辑就会混乱，甚至导致消息丢失。
Producer / Producer Group
消息生产者，生产者的作用就是将消息发送到 MQ，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。
生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。在这里可以不用关心，只要知道有这么一个概念即可。
Consumer / Consumer Group
消息消费者。
消费者组，和生产者类似，消费同一类消息的多个 consumer 实例组成一个消费者组。
[
若有收获，就点个赞吧
0 人点赞
