【RocketMq 系列】springboot RocketMq 入门教程

Apache RocketMQ 自诞生以来，因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。

RocketMq 版本

MetaQ 1.x是RocketMQ前身的第一个版本，本质上把Kafka做了一次java版本的重(Kafka是sacla)。
MetaQ 2.x，主要是对存储部分进行了优化，因为kafka的数据存储，它的partition是一个全量的复制，在阿里、在淘宝的这种海量交易。Kafka这种机制的横向拓展是非常不好的。2012年阿里同时把MetaQ 2.0从阿里内部开源出来，取名RocketMQ，同时为了命名上的规范（版本上延续），所以这个就是RocketMQ3.0。 2017年RocketMQ从Apache顶级项目毕业。现在RocketMQ主要维护的是4.x的版本，也是大家使用得最多的版本，RocketMQ5的版本也已经出来了，主要的方向是Cloud Native(云原生)。

部署架构

Apache RocketMQ 部署架构上主要分为四部分:

• 生产者 Producer 发布消息的角色。Producer通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。

• 消费者 Consumer 消息消费的角色。

  • 支持以推（push），拉（pull）两种模式对消息进行消费。
  • 同时也支持集群方式和广播方式的消费
  • 提供实时消息订阅机制，可以满足大多数用户的需求。

• 名字服务器 NameServer NameServer是 一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。 主要包括两个功能：

  1. Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
  2. 路由信息管理，每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。

  NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。

• 代理服务器 Broker Broker主要负责消息的存储、投递和查询以及服务高可用保证。

  NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。Broker部署相对复杂。

  在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

运转流程

1. 每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有