RocketMQ Interview Question
Kierke

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

  1. xxx需要再深入学习
1
2
3
4
5
<font color=red></font>
![]()
<img src="" title="图片名称" alt="图片无法正常加载展示!" width="100%" height="100%" >
<img src="" width="70%">
****