RocketMQ Interview Question

RocketMQ Interview Question
基础
为什么要使用消息队列
- 消息队列主要有三大用途:
- 解耦:服务与服务之间解耦合
- 异步:缩短调用链路,降低响应时间
- 削峰:扛住短时大流量
为什么选择RocketMQ
- 选择中间件的可以从这些维度来考虑:可靠性,性能,功能,可运维行,可拓展性,社区活跃度
RocketMQ有什么优缺点
RocketMQ优点
- 单机吞吐量:十万级
- 可用性:非常高,分布式架构
- 消息可靠性:经过参数优化配置,消息可以做到0丢失
- 功能支持:MQ功能较为完善,还是分布式的,扩展性好
- 支持10亿级别的消息堆积,不会因为堆积导致性能下降
- 源码是Java,方便结合公司自己的业务二次开发
- 天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务削峰,在大量交易涌入时,后端可能无法及时处理的情况
- RoketMQ在稳定性上可能更值得信赖,这些业务场景在阿里双11已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择RocketMQ
RocketMQ缺点
- 支持的客户端语言不多,目前是Java及c++,其中c++不成熟
- 没有在 MQ核心中去实现JMS等接口,有些系统要迁移需要修改大量代码
消息队列有哪些消息模型
- 消息队列有两种模型:队列模型和发布/订阅模型。
队列模型
- 这是最初的一种消息队列模型,对应着消息队列“发-存-收”的模型
- 生产者往某个队列里面发送消息,一个队列可以存储多个生产者的消息,一个队列也可以有多个消费者
- 消费者之间是竞争关系,也就是说每条消息只能被一个消费者消费
发布/订阅模型
- 消息的发送方称为发布者(Publisher)
- 消息的接收方称为订阅者(Subscriber)
- 服务端存放消息的容器称为主题(Topic)
- 如果需要将一份消息数据分发给多个消费者,并且每个消费者都要求收到全量的消息。很显然,队列模型无法满足这个需求。解决的方式就是发布/订阅模型
- 发布者将消息发送到主题中,订阅者在接收消息之前需要先“订阅主题”
- 每份订阅中,订阅者都可以接收到主题的所有消息
RocketMQ的消息模型呢
- RocketMQ使用的消息模型是标准的发布-订阅模型
- RocketMQ本身的消息是由下面几部分组成:
- Message(消息)就是要传输的信息
- Topic(主题)可以看做消息的归类,它是消息的第一级类型,Tag(标签)可以看作子主题,它是消息的第二级类型
- Group:RocketMQ中,订阅者的概念是通过消费组(Consumer Group)来体现的
- Message Queue(消息队列),一个 Topic 下可以设置多个消息队列,Topic 包括多个 Message Queue
Queue
是一个长度无限的数组,Offset 就是下标
消息的消费模式了解吗
- 消息消费模式有两种:Clustering(集群消费)和Broadcasting(广播消费)
默认情况下就是集群消费,这种模式下
一个消费者组共同消费一个主题的多个队列,一个队列只会被一个消费者消费
,如果某个消费者挂掉,分组内其它消费者会接替挂掉的消费者继续消费。而广播消费消息会发给消费者组中的每一个消费者进行消费。
RoctetMQ基本架构了解吗
RocketMQ 一共有四个部分组成:NameServer,Broker,Producer 生产者,Consumer 消费者,它们对应了:发现、发、存、收,为了保证高可用,一般每一部分都是集群部署的。
NameServer
- NameServer 是一个无状态的服务器,角色类似于 Kafka使用的 Zookeeper,但比 Zookeeper 更轻量
- 每个 NameServer 结点之间是相互独立,彼此没有任何信息交互
- 主要功能:
- 和Broker 结点保持长连接
- 维护 Topic 的路由信息
Nameserver 被设计成几乎是无状态的,通过部署多个结点来标识自己是一个伪集群,Producer 在发送消息前从 NameServer 中获取 Topic 的路由信息也就是发往哪个 Broker,Consumer 也会定时从 NameServer 获取 Topic 的路由信息,Broker 在启动时会向 NameServer 注册,并定时进行心跳连接,且定时同步维护的 Topic 到 NameServer
Broker
- 消息存储和中转角色,负责存储和转发消息
- Broker 内部维护着一个个 Consumer Queue,用来存储消息的索引,真正存储消息的地方是 CommitLog(日志文件)
- 单个 Broker 与所有的 Nameserver 保持着长连接和心跳,并会定时将 Topic 信息同步到 NameServer,和 NameServer 的通信底层是通过 Netty 实现的
Producer
进阶
Reference
Remark
- xxx需要再深入学习
1 | <font color=red></font> |