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 | 默认是轮询 | 客户端负载均衡,支持平均和轮询分配 |
刷盘策略 | 默认是异步刷盘 | 默认是内存存储 | 默认同步刷盘 |