面试题之RocketMq

本文深入探讨RocketMQ的组件、使用原因、优缺点,以及其在消息顺序消费、重复消费、消息丢失等方面的问题与解决方案。同时,介绍了RocketMQ的消费模式、消息堆积处理、延时消息机制和高容错性设计。此外,对比了RocketMQ与Kafka的区别,并提出了构建分布式消息中间件的整体架构设计思路。
摘要由CSDN通过智能技术生成

1. RocketMq的组成及各自的作用?

在这里插入图片描述

  • 在RocketMq中有四个部分组成,分别是Producer,Consumer,Broker,以及NameServer,类比于生活中的邮局,分别是发信者,收信者,负责暂存,传输的邮局,以及协调各个地方邮局的管理机构。

  • NameServer
    主要是 Topic 和 Broker 注册中心,支持 Broker 动态注册和发现,主要保存 Topic的路由信息和Broker的状态信息。通常也是集群部署,但是各 NameServer 之间不会互相通信, 各 NameServer 都有完整的路由信息,即无状态(跟zk的区别是,zk为有状态的)。

  • Broker
    就是MQ本身,负责收发消息、持久化消息,每个broker负责管理一部分topic的消息;主要分为 Master Broker 和 Slave Broker,一个 Master Broker 可以对应多个 Slave Broker,但是一个 Slave Broker 只能对应一个 Master Broker。Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接,定时注册Topic信息到所有Name Server。Broker 启动后需要完成一次将自己注册至 Name Server 的操作。

  • Producer:消息生产者
    可以集群部署。它会先和 NameServer 集群中的随机一台建立长连接,得知当前要发送的 Topic 存在哪台 Broker Master上,然后再与其建立长连接,支持多种负载平衡模式发送消息。

  • Consumer:消息消费者
    可以集群部署。它也会先和 NameServer 集群中的随机一台建立长连接,得知当前要消息的 Topic 存在哪台 Broker Master、Slave上,然后它们建立长连接,支持集群消费和广播消费消息。

  • Topic:
    标识一类消息的逻辑名字,消息的逻辑管理单位。无论消息是生产还是消费都需要指定Topic;比如电商系统可以分为:交易消息、物流消息,每条消息都必须有一个topic,一个类型的消息可以定义一个topic,也可以定义多个,根据业务需求来定;

  • Tag:
    可以看作子主题,它是消息的第二级类型,同一业务模块不同目的的消息就可以用相同 Topic 而不同的 Tag 来标识。比如交易消息又可以分为:交易创建消息、交易完成消息等,一条消息可以没有 Tag ;虽然同一个topic的管理逻辑一样,但是消费topic1的时候,如果你订阅指定的是tagA,那么tagB的消息不会投递。

  • Group
    分组,一个组可以订阅多个Topic,代表某一类的生产者和消费者,一般来说同一个服务可以做为Group,同一个Group一般来说发送和消费的消息都是一样的。

  • Queue
    队列其实就是对Topic的分片,在Kafka里面就是Partition。将Topic分片再切分为若干等分,其中的一份就是一个Queue。每个Topic分片等分的Queue的数量可以不同,由用户在创建Topic时指定。这些队列会被RocketMQ均衡的分布在不同Broker上,Producer在发送消息时会根据一定策略选择一个消息队列进行发送,这样就可以实现负载均衡和提高吞吐的效果。

  • Offset
    偏移,本质上有两种Offset,一种是写入时末尾的Offset,另一种是同一消费组读的Offset。RocketMq消息内容是分片存储,CommitLog 的大小默认是1G,当超过大小限制的时候需要准备新的文件,CommitLog 采用混合型存储,也就是所有 Topic 都存在一起,顺序追加写入,文件名用起始偏移量命名。其次RocketMq还存储了消息体与偏移的关系,用于快速随机读取和检索。

2. 为什么使用消息队列?

最开始的时候业务量小,直接单机能解决,后来业务量大,采用微服务的设计思想,分布式部署的方式,拆出了很多服务,场景也就越来越复杂,所以引用了消息队列。

3. 为什么要用RocketMq?

削峰:在高并发场景下,系统的请求量可能会瞬间增加,给服务器带来巨大的压力。通过使用消息队列,可以将突发的大量请求进行缓冲和削峰,使其平滑地处理,从而避免服务器过载和崩溃;
异步:如果下单流程涉及多个系统,影响支付时间,所以支付同时完成其他工作去校验;在这里插入图片描述
解耦:可以将系统的各个模块解耦,减少模块之间的直接依赖。这样可以使各个模

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值