RocketMQ基础知识

1.介绍:

RocketMQ(阿里巴巴)作为一款纯java,分布式,队列模型的开源消息中间件,支持事务消息,顺序消息,批量消息,定时消息,消息回溯,等.它里面又几个区别于标准消息中间件的概念,如Group,Topic,Queue,等.系统组成则由Producer,Consumer,Broker,NameServer,等,类似Kafka,RabbitMQ

1.1 RocketMQ组件

NameServer: 名称服务,充当路由消息的提供者.是一个无状态的节点,可集群部署,节点之间无任何信息同步,在消息队列RocketMQ中提供命名服务,更新和发现Broker服务

​ NameServer 俩个功能:

• 接收broker 的请求,注册broker的路由信息

• 接收client(producer/consumer)的请求,根据某个topic获取到broker的路由信息

  - nameserver没有状态,可以横向扩展.每个borker在启动的时候会到nameserver中注册;
  

  • producer在发送消息前会根据topic到nameserver中获取路由信息,

  • consumer也会定时获取topic路由信息

Broker: 消息中转角色,负责消息存储,消息转发.可以理解为消息队列服务器,提供了消息的接收,存储,拉取,和转发服务. borker 是 RockerMQ 的核心,它不能挂载所以需要保证broker的高可用.

• Broker要想实现高可用,必须搭建集群,一个Master Broker 对应多个Slave Broker,在rockermq安装目录下conf文件夹下边,有可以参考的配置文件/2m-2s-async(两主-两从-异步)/2m-2s-sync(两主-两从-同步)/2m-noslave(两主-没有从broker).默认brokerId为0是主broker,brokerId>0为从broker

  • 每个Broker与NameServer集群中的所有节点建立长连接,定时注册Topic信息到所有NameServer.Broker启动后需要完成一次将自己注册至NameServer的操作,随后每隔30S定期向NameServer上报Topic路由信息

Producer: 与NameServer集群中的其中一个节点(随机)建立长链接(Keep-alive),定期从NameServer读取Topic路由信息,并向提供Topic服务的Master Broker建立长链接,且定时向Master Broker发送心跳.

Consumer: 与NameServer集群中的其中一个节点(随机)建立长链接,定期从NameServer拉取Topic路由信息,并向提供Topic服务的Master Broker,Slave Broker建立长链接,且定时向Master Broker,Slave Broker发送心跳.Consumer既可以从Master Broker 订阅消息,也可以从Slave Broker订阅消息,订阅规则由Broker配置决定

2.MQ的作用:

2.1 异步与解耦

举例(电商系统):

在电商系统中包含:订单系统,支付系统,库存系统,物流系统,等.当我们下了一个订单之后,订单系统会进行RPC同步调用支付系统,库存系统,物流系统,等,那么系统之间就会有耦合性,耦合性越高的话,容错行就越低,比如我们的支付系统宕机了,就会导致整个交易的异常,从而影响用户的体验,如果我们在订单系统和支付系统,库存系统,还有物流系统之间加入MQ(消息中间件)的话,不管是支付系统还是库存系统,都是通过异步的方式进行调用的,如果其中一个系统宕机了,不会影响我们用户下单的使用,订单系统会先发出心跳机制.检测支付,库存或者物流系统是否健康,如果健康:则将消息发送,支付,库存,或者物流系统会接收,否则消息会暂存在MQ当中,等所宕服务从新启动,再将消息发送.本质上MQ第一步完成了异步,第二步完成了解耦.这样我们系统的容错性就越高.

2.2 削峰

流量削峰也可以叫削峰填谷,比如一些互联网公司大促场景,双十一,店庆或者秒杀活动,都会使用到消息中间件.

如果在不使用消息中间件或者没有流量削峰,每秒是很高的并发,这个时候如果我们的A系统,要将数据写入到我们的Mysql中,受限于Mysql本身服务的上限,最大我们只能每秒处理200请求,这个时候会有大量的消息进行堆积,从而导致A系统的奔溃.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kD93EnPL-1679449643382)(G:\note\RocketMQ\images\20230310104634.png)]

这个时候我们可以将用户的请求消息通过MQ进行写入,因为消息中间件本身是对数据量处理比较高的一个系统,所以对于每秒2000请求,消息中间件可以处理,然后A系统作为消息中间件的一个消费者,以固定的速度从MQ中拉取200个消息,完成我们的业务操作,用时间换空间从而确保我们A系统的稳定性.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kfEAXWQZ-1679449643382)(G:\note\RocketMQ\images\20230310105402.png)]

3.常用的消息中间件:Kafka,RabbitMQ,RocketMQ的区别

功能项	Kafka(1.1.0版本)	RabbitMQ(3.6.10版本)	RocketMQ(4.2.0)
优先级队列	不支持	支持，建议优先级大小设置在0-10之间	支持，维护不同的优先级队列，根据message的优先级发送到对于的队列中
延迟队列	不支持	支持	支持
死信队列	不支持	支持	支持
重试队列	不支持	支持	支持
消费模式	pull拉模式	pull + push	pull+长轮询
广播消费	支持，kafka对于广播消息的支持更加正统	支持	支持
批量消息	支持，生产者异步发送	支持	支持，生产者同步发送
消息回溯	支持.Kakfa支持按照offset和timestam两种维度进行消息回溯	不支持，一旦被确认消费就会被删除	支持
消息堆积	支持，海量消息堆积，堆积能力和磁盘大小挂钩	支持，但是内存达到阀值时，性能会受影响	支持海量消息堆积
持久化方式	消息队列，segment方式	支持	消息队列
消息追踪	不支持。消息追踪可以通过外部系统来支持，但是支持粒度没有内置的细腻。	支持	支持
消息过滤	客户端级别的支持，可用过kafka stream进行消息过滤	不支持，但是二次封装一下也较简单	支持，可通过message tag、属性进行过滤
多租户	不支持	支持	不支持
多协议支持	只支持定义协议，目前几个主流版本之间存在兼容性问题	AMQP	JMS ，OpenMessaging
跨语言支持	当前版本采用Java编写，支持多种语言的客户端	采用Erlang编写，支持多种语言客户端	Java, C++, Go
流量控制	支持client和user级别，通过主动设置可将流控作用于生产者或消费者	流量控制基于credit-base算法，是内部被动触发的保护机制，作用于生产者层面	RocketMQ提供了针对于不同维度的流量控制
消息顺序性	支持普通的顺序消息，即对于单个分区的消息发送和消费是有序的，但是不保证不重复	顺序性的条件比较苛刻，需要单线程发送，单线程消费并且不采用延迟队列、优先级队列等一些高级功能，从某种意义上来书不支持顺序性	支持普通的顺序消息和严格的顺序消息
幂等性	支持单个Producer单个分区的会话幂等性	不支持	不支持，不解决消息的重复问题
事务性消息	支持单个Producer单个分区的会话幂等性	支持	最新版的metaq支持事务消息
性能	最高	高	高
高可用和容错	使用partition的副本机制和isr选举机制保证高可用	普通集群非高可用，可用镜像模式和主备集群	通过broker的master和slave实现高可用
定时消息	不支持	不支持	不支持，不解决消息的重复问题
负载均衡	客户端消费者负载均衡，需要一个broker作为coordinator	默认是轮询	客户端负载均衡，支持平均和轮询分配
刷盘策略	默认是异步刷盘	默认是内存存储	默认同步刷盘

4.RocketMQ整体架构设计