RocketMQ简单认识以及其集群的特点

涛涛之海
151 阅读7分钟

RocketMQ

为什要用MQ

消息队列是一种“先进先出” 的数据结构

image-20200903205001405

应用解耦

原来

image-20200903205223908

现在

image-20200903205245326

流量削峰

原来

image-20200903205644435

现在

image-20200903205840113

数据分发

原来

image-20200903210059053

现在

image-20200903210224706

MQ的优缺点

优点：解耦、削峰，数据分发

缺点：

  • 系统可用性降低

    系统引入的外部依赖越多，系统的稳定性越差。一旦MQ宕机，就会对业务造成影响。

    如何保证MQ的高可用？

  • 系统的复杂度提高

    MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。

    如何保证消息没有被重复消费？怎么处理消息丢失情况？怎么保证消息传递的顺序性？

  • 一致性的问题

    A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理成功，D系统处理失败。

    如何保证消息数据处理的一致性？

各种MQ产品的比较

特性ActiveMQRabbiMQRocketMQKafKa
开发语言javaerlangjavascala
单机吞吐量万级万级10万级10万级
时效性ms级us级ms级ms级以内
可用性高(主从架构)高(主从架构)非常高(分布式架构)非常高(分布式架构)
功能性成熟的产品，有较多的文档，各种协议支持较好基于erlang开发，所有并发能力强，性能极其好，延时很低，管理界面较丰富MQ功能比较完备，扩展性佳只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广

安装RocketMQ

安装maven（centOs7）

 #切换目录
 cd /usr/local
 ​
 #下载
 wget http://mirrors.hust.edu.cn/apache/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
 ​
 #解压
 tar -zxvf apache-maven-3.6.3-bin.tar.gz 
 ​
 #修改环境变量
 vim /etc/profile
 ​
 修改内容
 export MAVEN_HOME=/usr/local/apache-maven-3.6.3
 export PATH=$PATH:$MAVEN_HOME/bin
 ​
 #重启配置生效
 source /etc/profile
 ​
 #使用命令查看是否安装成功
  chmod a+x /usr/local/apache-maven-3.6.3/bin/mvn
  mvn –v
  
  # 修改setting.xml 文件配置镜像
  [root@localhost local]# cd apache-maven-3.6.3/conf
   vim settings.xml 
   
 ##设置maven  jar包下载地址
 <localRepository>/usr/local/maven-localRepository</localRepository>
 ​
 ##修改镜像为阿里地址
 <mirror>
       <id>alimaven</id>
       <name>aliyun maven</name>
         <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
        <mirrorOf>central</mirrorOf>        
 </mirror>
 ​
 

image-20200904203019834

image-20200904203904714

下载git

  yum -y install git

下载rocketMq

 #下载
 wget https://mirrors.tuna.tsinghua.edu.cn/apache/rocketmq/4.7.1/rocketmq-all-4.7.1-bin-release.zip 
 ​
 #下载unzip 工具
  yum install -y unzip zip
  
  #解压
  unzip rocketmq-all-4.7.1-bin-release.zip

image-20200904205347834

目录

image-20200904205728446

启动RocketMQ

启动NameServer

  #启动
  nohup sh bin/mqnamesrv &
  
  # 查看日志
  tail -f ~/logs/rocketmqlogs/namesrv.log

image-20200904211339089

启动Broker

 #启动
 nohup sh bin/mqbroker -n localhost:9876 &
 ​
 #查看日志
 tail -f ~/logs/rocketmqlogs/broker.log

查看日志时会发现没有这个日志，说明Broker 没有启动

 [root@localhost bin]# tail -f ~/logs/rocketmqlogs/broker.log 
 tail: 无法打开"/root/logs/rocketmqlogs/broker.log" 读取数据: 没有那个文件或目录
 tail: 没有剩余文件
 ​
 # 查看
 [root@localhost bin]# jps
 6745 Jps
 6715 NamesrvStartup

问题原因：

RocketMQ 默认的虚拟机内存较大，启动Broker如果内存不足失败，需要编辑如下两个配置文件，修改JVM内存大小

 vim runbroker.sh
 ​
 vim runserver.sh

runbroker.sh

image-20200904212235511

修改

 JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m"

image-20200904212830281

runserver.sh

image-20200904213407602

修改

image-20200904213517785

重启NameServer前，需要先关闭NameServer

 [root@localhost bin]# sh mqshutdown namesrv
 The mqnamesrv(6715) is running...
 Send shutdown request to mqnamesrv(6715) OK

启动成功

image-20200904215010096

测试RocketMQ

发送消息

 # 设置环境变量
 export NAMESRV_ADDR=localhost:9876
 ​
 # 使用安装包的Demo 发送消息
 sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

接受消息

 # 设置环境变量
 export NAMESRV_ADDR=localhost:9876
 ​
 # 使用安装包的Demo 发送消息
 sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

关闭RocketMQ

 #关闭namesrv
 sh mqshutdown namesrv
 ​
 #关闭 broker
 sh mqshutdown broker

RocketMQ 集群搭建

各角色介绍

  • Producer:消息的发送者；举例：发信者；
  • Consumer: 消息接受者；举例：收信者
  • Broker:暂存和传输消息；举例：邮局
  • NameServer:管理Broker;举例：各个邮局的管理机构
  • Topic:区分消息的种类：一个发送者可以发送消息给一个或者多个Topic;一个消息的接受者可以订阅一个或者多个Topic消息
  • Message Queue :相当于Topic 的分区，用于并行发送和接受消息

image-20200907213309336

集群搭建方式

集群特点

  • NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
  • Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。
  • Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
  • Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

集群模式

1）单Master模式

这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。

2）多Master模式

一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点如下：

  • 优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
  • 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
3）多Master多Slave模式（异步）

每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：

  • 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；
  • 缺点：Master宕机，磁盘损坏情况下会丢失少量消息。
4）多Master多Slave模式（同步）

每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：

  • 优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；
  • 缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

双主双从(同步)集群搭建

image-20200907215007898

工作流程

  1. 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。
  2. Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
  3. 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
  4. Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
  5. Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息
avatar
文章
阅读
粉丝