RocketMQ搭建+集群

千束
100 阅读4分钟

RocketMQ vs. ActiveMQ vs. Kafka

8528ea9a6bc5d63442a8bdffe689e386.png bbcde3b86446334b849f12b76a4a73f8.png 7d7f16cbc67d3fab79e3fcb41bf808e6.png 464d782426b1b92b3a69285e6fea71bd.png

技术架构

50ef25f893fc79a5b212cb6453628e6a.png

  1. Producer：消息发布的⻆⾊，⽀持分布式集群⽅式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进⾏消息投递，投递的过程⽀持快速失败并且低延迟。

  2. Consumer：消息消费的⻆⾊，⽀持分布式集群⽅式部署。⽀持以push推，pull拉两种模式对消息进⾏消费。同时也⽀持集群⽅式和⼴播⽅式的消费，它提供实时消息订阅机制，可以满⾜⼤多数⽤户的需求。

  3. NameServer：NameServer是⼀个⾮常简单的Topic路由注册中⼼，其⻆⾊类似Dubbo中的zookeeper，⽀持Broker的动态注册与发现。

    1. Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供⼼跳检测机制，检查Broker是否还存活；路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和⽤于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从⽽进⾏消息的投递和消费。
    2. NameServer通常也是集群的⽅式部署，各实例间相互不进⾏信息通讯。Broker是向每⼀台NameServer注册⾃⼰的路由信息，所以每⼀个NameServer实例上⾯都保存⼀份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。

  4. BrokerServer：Broker主要负责消息的存储、投递和查询以及服务⾼可⽤保证，为了实现这些功能，Broker包含了以下⼏个重要⼦模块。

    1. Remoting Module：整个Broker的实体，负责处理来⾃clients端的请求。
    2. Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息
    3. Store Service：提供⽅便简单的API接⼝处理消息存储到物理硬盘和查询功能。
    4. HA Service：⾼可⽤服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
    5. Index Service：根据特定的Message key对投递到Broker的消息进⾏索引服务，以提供消息的快速查询。 46ee01afba91dfa97f4354ec716d60cc.png

⽹络部署特点

  • NameServer是⼀个⼏乎⽆状态节点，可集群部署，节点之间⽆任何信息同步。
  • Broker部署相对复杂，Broker分为Master与Slave，⼀个Master可以对应多个Slave，但是⼀个Slave只能对应⼀个Master，Master与Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，⾮0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建⽴⻓连接，定时注册Topic信息到所有NameServer。 注意：当前RocketMQ版本在部署架构上⽀持⼀Master多Slave，但只有BrokerId=1的从服务器才会参与消息的读负载。
  • Producer与NameServer集群中的其中⼀个节点（随机选择）建⽴⻓连接，定期从NameServer获取Topic路由信息，并向提供Topic 服务的Master建⽴⻓连接，且定时向Master发送⼼跳。Producer完全⽆状态，可集群部署。
  • Consumer与NameServer集群中的其中⼀个节点（随机选择）建⽴⻓连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的Master、Slave建⽴⻓连接，且定时向Master、Slave发送⼼跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，消费者在向Master拉取消息时，Master服务器会根据拉取偏移量与最⼤偏移量的距离（判断是否读⽼消息，产⽣读I/O），以及从服务器是否可读等因素建议下⼀次是从Master还是Slave拉取。

集群⼯作流程

  • 启动NameServer，NameServer起来后监听端⼝，等待Broker、Producer、Consumer连上来，相当于⼀个路由控制中⼼。
  • Broker启动，跟所有的NameServer保持⻓连接，定时发送⼼跳包。⼼跳包中包含当前Broker信息(IP+端⼝等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
  • 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时⾃动创建Topic。
  • Producer发送消息，启动时先跟NameServer集群中的其中⼀台建⽴⻓连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择⼀个队列，然后与队列所在的Broker建⽴⻓连接从⽽向Broker发消息。
  • Consumer跟Producer类似，跟其中⼀台NameServer建⽴⻓连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建⽴连接通道，开始消费消息。

集群启动流程

  1. 启动NameServer
    1. 分别进入三台虚拟机的/usr/local/rocketmq/rocketmq-all-4.7.1-bin-release/bin目录下执行：
      1. nohup ./mqnamesrv -n 192.168.150.101:9876 &
      2. nohup ./mqnamesrv -n 192.168.150.102:9876 &
      3. nohup ./mqnamesrv -n 192.168.150.103:9876 &
  2. 在b虚拟机上启动a主broker和b从broker
    1. nohup ./mqbroker -c ../conf/2m-2s-async/broker-a.properties &
    2. nohup ./mqbroker -c ../conf/2m-2s-async/broker-b-s.properties &
  3. 在c虚拟机是启动a从broker和b主broker
    1. nohup ./mqbroker -c ../conf/2m-2s-async/broker-b.properties &
    2. nohup ./mqbroker -c ../conf/2m-2s-async/broker-a-s.properties &
  4. 启动可视化界面
    1. 在a虚拟机的/usr/local/rocketmq/rocketmq-externals/rocketmq-externals-master-master/rocketmq-console/target目录下执行：
      1. nohup java -jar rocketmq-console-ng-1.0.1.jar
    2. 访问192.168.150.101:8080查看可视化界面
avatar
文章
阅读
粉丝