RocketMQ角色组成

常见的消息中间件

ActiveMQ

• ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE
  1.4规范的 JMS Provider实现。【5W/s吞吐量】

RabbitMQ

• AMQP协议的领导实现，支持多种场景。淘宝的MySQL集群内部有使用它进行通讯，OpenStack开源云平台的通信组件，最先在金融行业得到运用。【5W/s吞吐量】
• rabbitmq由erlang语言开发，性能比较好，高并发能力也很强

RocketMQ

• 阿里开源分布式消息队列系统 【10W/s吞吐量】
• rocketmq的话是阿里巴巴开源的，对分布式有很好的支持，同时接口简单易用

Kafka

• Apache项目。特点：高吞吐，在一台普通的服务器上既可以达到【10W/s的吞吐量】
• 完全的分布式系统。适合处理海量数据
• Kafka的优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景来设计

RocketMQ简介

什么是RocketMQ

• RocketMQ作为一款纯java、分布式、队列模型的开源消息中间件，
• 支持 事务消息、顺序消息、批量消息、定时消息、消息回溯 等
• RocketMQ由阿里巴巴开源。

RocketMQ 由哪些角色组成？

生产者（Producer）：负责产生消息，生产者向消息服务器发送由业务应用程序系统生成的消息。

消费者（Consumer）：负责消费消息，消费者从消息服务器拉取信息并将其输入用户应用程序。

消息服务器（Broker）：是消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。

名称服务器（NameServer）：用来保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找 Broker 信息。

RocketMQ执行流程

1. 启动 Namesrv，Namesrv起 来后监听端口，等待 Broker、Producer、Consumer连上来，相当于一个路由控制中心。
2. Broker 启动，跟所有的 Namesrv 保持长连接，定时发送心跳包。
3. 收发消息前，先创建 Topic 。创建 Topic 时，需要指定该 Topic 要存储在 哪些 Broker上。也可以在发送消息时自动创建Topic。
4. Producer 发送消息。
5. Consumer 消费消息。

topic

• Topic 是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单 Topic
  存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。

Producer(生产者)

1. 获得 Topic-Broker 的映射关系。Producer 启动时，也需要指定 Namesrv 的地址，从 Namesrv集群中选一台建立长连接。生产者每 30 秒从 Namesrv 获取 Topic 跟 Broker 的映射关系，更新到本地内存中。然后再跟 Topic 涉及的所有 Broker 建立长连接，每隔 30 秒发一次心跳。
2. 生产者端的负载均衡。生产者发送时，会自动轮询当前所有可发送的broker，一条消息发送成功，下次换另外一个broker发送，以达到消息平均落到所有的broker上。
3. 与nameserver的关系单个Producer和一台nameserver保持长连接，定时查询topic配置信息，如果该nameserver挂掉，生产者会自动连接下一个nameserver，直到有可用连接为止，并能自动重连。与nameserver之间没有心跳。
4. 与broker的关系,单个Producer和与其关联的所有broker保持长连接，并维持心跳。默认情况下消息发送采用轮询方式，会均匀发到对应Topic的所有queue中。

Consumer(消费者)

• 获得 Topic-Broker 的映射关系。Consumer 启动时需要指定 Namesrv 地址，与其中一个 Namesrv建立长连接。消费者每隔 30 秒从 Namesrv 获取所有Topic 的最新队列情况，Consumer 跟 Broker是长连接，会每隔 30 秒发心跳信息到Broker .
• 消费者端的负载均衡。根据消费者的消费模式不同，负载均衡方式也不同。
• 与nameserver的关系,单个Consumer和一台nameserver保持长连接，定时查询topic配置信息，如果该nameserver挂掉，消费者会自动连接下一个nameserver，直到有可用连接为止，并能自动重连。与nameserver之间没有心跳。
• 与broker的关系,单个Consumer和与其关联的所有broker保持长连接，并维持心跳，失去心跳后，则关闭连接，并向该消费者分组的所有消费者发出通知，分组内消费者重新分配队列继续消费。

Broker

• Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接及心跳，并会定时将Topic信息注册到NameServer，顺带一提底层的通信和连接都是基于Netty实现的。Broker中分master和slave两种角色，每个master可以对应多slave，但一个slave只能对应一个master,master和slave通过指定相同的Brokername，不同的BrokerId（master为0）成为一个组。
• master和slave之间的同步方式分为同步双写和异步复制，异步复制方式master和slave之间虽然会存在少量的延迟，但性能较同步双写方式要高出10%左右。

NameServe

• NameServer的作用是注册中心，类似于Zookeeper，但又有区别于它的地方。每个NameServer节点互相之间是独立的，没有任何信息交互，也就不存在任何的选主或者主从切换之类的问题，因此NameServer与Zookeeper相比更轻量级。单个NameServer节点中存储了活跃的Broker列表（包括master和slave），这里活跃的定义是与NameServer保持有心跳。

消费者消费模式有几种？

消费者消费模式有两种：集群消费和广播消费。

1. 集群消费

消费者的一种消费模式。一个 Consumer Group 中的各个 Consumer 实例分摊去消费消息，即一条消息只会投递到一个 Consumer Group 下面的一个实例。

2. 广播消费

消费者的一种消费模式。消息将对一 个Consumer Group 下的各个 Consumer 实例都投递一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。

消费者获取消息有几种模式？

消费者获取消息有两种模式：推送模式和拉取模式。

1. PushConsumer

推送模式（虽然 RocketMQ 使用的是长轮询）的消费者。消息的能及时被消费。使用非常简单，内部已处理如线程池消费、流控、负载均衡、异常处理等等的各种场景。

长轮询，push + pull 模式结合的方式。

2. PullConsumer

拉取模式的消费者。应用主动控制拉取的时机，怎么拉取，怎么消费等。主动权更高。但要自己处理各种场景。