Java面试题 -RocketMQ

简介: Java面试题 -RocketMQ

http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/

  1. 中⼩型公司⾸选RabbitMQ:管理界⾯简单,⾼并发。
  2. ⼤型公司可以选择RocketMQ:更⾼并发,可对rocketmq进⾏定制化开发。
  3. ⽇志采集功能,⾸选kafka,专为⼤数据准备。
1. 消息可靠性:

影响消息可靠性的情况:

i. Broker正常关闭

ii. Broker异常Crash

iii. OS Crash

iv. 机器掉电,但是能⽴即恢复供电情况。

v. 机器⽆法开机(可能是cpu、主板、内存等关键设备损坏)

vi. 磁盘设备损坏。

1、(1)、(2)、(3)、(4)四种情况都属于硬件资源可⽴即恢复情况,RocketMQ在这四种情况下能保证消息不丢,或者丢失少量数据(依赖刷盘⽅式是同步还是异步)。

2、(5)、(6)属于单点故障,且⽆法恢复,⼀旦发⽣,在此单点上的消息全部丢失。RocketMQ在这两种情况下,通过异步复制,可保证99%的消息不丢,但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点,同步双写势必会影响性能,适合对消息可靠性要求极⾼的场合,例如与Money相关的应⽤。

2. 消息低延迟:

在消息不堆积情况下,消息到达Broker后,能⽴刻到达Consumer。RocketMQ使⽤⻓轮询Pull⽅式,可保证消息⾮常实时,消息实时性不低于Push。

3. 每个消息⾄少投递⼀次

RocketMQ Consumer先pull消息到本地,消费完成后,才向服务器返回ack,如果没有消费⼀定不会ack消息,所以RocketMQ可以很好的⽀持此特性。

4. 每个消息只消费⼀次

前提:

  • i. 发送消息阶段,不允许发送重复的消息。
  • ii. 消费消息阶段,不允许消费重复的消息。

2、只有以上两个条件都满⾜情况下,才能认为消息是“Exactly Only Once”,⽽要实现以上两点,在分布式系统环境下,不可避免要产⽣巨⼤的开销。所以RocketMQ为了追求⾼性能,并不保证此特性,要求在业务上进⾏去重,也就是说消费消息要做到幂等性RocketMQ虽然不能严格保证不重复,但是正常情况下很少会出现重复发送、消费情况,只有⽹络异常,Consumer启停等异常情况下会出现消息重复。

5. Broker的Buffer满了怎么办?

下⾯是CORBA Notification规范中处理⽅式

i. RejectNewEvents 拒绝新来的消息,向Producer返回RejectNewEvents错误码。

ii. 按照特定策略丢弃已有消息

  1. AnyOrder - Any event may be discarded on overflow. This is the default setting for this property.
  2. FifoOrder - The first event received will be the first discarded.
  3. LifoOrder - The last event received will be the first discarded.
  4. PriorityOrder - Events should be discarded in priority order, such that lower priority events will bediscarded before higher priority events.
  5. DeadlineOrder - Events should be discarded in the order of shortest expiry deadline first.

RocketMQ没有内存Buffer概念,RocketMQ的队列都是持久化磁盘,数据定期清除。

  • 对于此问题的解决思路,RocketMQ同其他MQ有⾮常显著的区别,RocketMQ的内存Buffer抽象成⼀个⽆限⻓度的队列,不管有多少数据进来都能装得下,这个⽆限是有前提的,Broker会定期删除过期的数据,例如Broker只保存3天的消息,那么这个Buffer虽然⻓度⽆限,但是3天前的数据会被从队尾删除。此问题的本质原因是⽹络调⽤存在不确定性,即既不成功也不失败的第三种状态,所以才产⽣了消息重复性问题。
6. 回溯消息

a. 回溯消费是指Consumer已经消费成功的消息,由于业务上需求需要重新消费,要⽀持此功能,Broker在向Consumer投递成功消息后,消息仍然需要保留。并且重新消费⼀般是按照时间维度,例如由于Consumer系统故障,恢复后需要重新消费1⼩时前的数据,那么Broker要提供⼀种机制,可以按照时间维度来回退消费进度。

b. RocketMQ⽀持按照时间回溯消费,时间维度精确到毫秒,可以向前回溯,也可以向后回溯。

7. 消息堆积

消息中间件的主要功能是异步解耦,还有个重要功能是挡住前端的数据洪峰,保证后端系统的稳定性,这就要求消息中间件具有⼀定的消息堆积能⼒,消息堆积分以下两种情况:

  • i. 消息堆积在内存Buffer,⼀旦超过内存Buffer,可以根据⼀定的丢弃策略来丢弃消息,如CORBA Notification规范中描述。适合能容忍丢弃消息的业务,这种情况消息的堆积能⼒主要在于内存Buffer⼤⼩,⽽且消息堆积后,性能下降不会太⼤,因为内存中数据多少对于对外提供的访问能⼒影响有限。
  • ii. 消息堆积到持久化存储系统中,例如DB,KV存储,⽂件记录形式。 当消息不能在内存Cache命中时,要不可避免的访问磁盘,会产⽣⼤量读IO,读IO的吞吐量直接决定了消息堆积后的访问能⼒。

评估消息堆积能⼒主要有以下四点:

i. 消息能堆积多少条,多少字节?即消息的堆积容量。

ii. 消息堆积后,发消息的吞吐量⼤⼩,是否会受堆积影响?

iii. 消息堆积后,正常消费的Consumer是否会受影响?

iv. 消息堆积后,访问堆积在磁盘的消息时,吞吐量有多⼤?

8. 分布式事务
  1. 已知的⼏个分布式事务规范,如XA,JTA等。其中XA规范被各⼤数据库⼚商⼴泛⽀持,如Oracle,Mysql等。其中XA的TM实现佼佼者如Oracle Tuxedo,在⾦融、电信等领域被⼴泛应⽤。
  2. 分布式事务涉及到两阶段提交问题,在数据存储⽅⾯的⽅⾯必然需要KV存储的⽀持,因为第⼆阶段的提交回滚需要修改消息状态,⼀定涉及到根据Key去查找Message的动作。RocketMQ在第⼆阶段绕过了根据Key去查找Message的问题,采⽤第⼀阶段发送Prepared消息时,拿到了消息的Offset,第⼆阶段通过Offset去访问消息,并修改状态,Offset就是数据的地址。
  3. RocketMQ这种实现事务⽅式,没有通过KV存储做,⽽是通过Offset⽅式,存在⼀个显著缺陷,即通过Offset更改数据,会令系统的脏⻚过多,需要特别关注。
9. 定时消息

a. 定时消息是指消息发到Broker后,不能⽴刻被Consumer消费,要到特定的时间点或者等待特定的时间后才能被消费。

b. 如果要⽀持任意的时间精度,在Broker层⾯,必须要做消息排序,如果再涉及到持久化,那么消息排序要不可避免的产⽣巨⼤性能开销。

c. RocketMQ⽀持定时消息,但是不⽀持任意时间精度,⽀持特定的level,例如定时5s,10s,1m等。

10. 消息重试

Consumer消费消息失败后,要提供⼀种重试机制,令消息再消费⼀次。Consumer消费消息失败通常可以认为有以下⼏种情况:

  • i. 由于消息本身的原因,例如反序列化失败,消息数据本身⽆法处理(例如话费充值,当前消息的⼿机号被注销,⽆法充值)等。这种错误通常需要跳过这条消息,再消费其他消息,⽽这条失败的消息即使⽴刻重试消费,99%也不成功,所以最好提供⼀种定时重试机制,即过10s秒后再重试。
  • ii. 由于依赖的下游应⽤服务不可⽤,例如db连接不可⽤,外系统⽹络不可达等。遇到这种错误,即使跳过当前失败的消息,消费其他消息同样也会报错。这种情况建议应⽤sleep 30s,再消费下⼀条消息,这样可以减轻Broker重试消息的压⼒。
11. RocketMq是什么?

上图是⼀个典型的消息中间件收发消息的模型,RocketMQ也是这样的设计,简单说来,RocketMQ具有以下特点:

  • 是⼀个队列模型的消息中间件,具有⾼性能、⾼可靠、⾼实时、分布式特点。
  • Producer、Consumer、队列都可以分布式。
  • Producer向⼀些队列轮流发送消息,队列集合称为Topic,Consumer如果做⼴播消费,则⼀个consumer实例消费这个Topic对应的所有队列,如果做集群消费,则多个Consumer实例平均消费这个topic对应的队列集合。
  • 能够保证严格的消息顺序
  • 提供丰富的消息拉取模式
  • ⾼效的订阅者⽔平扩展能⼒
  • 实时的消息订阅机制
  • 亿级消息堆积能⼒
  • 较少的依赖
12. RocketMq物理部署结构

  • Name Server是⼀个⼏乎⽆状态节点,可集群部署,节点之间⽆任何信息同步。
  • Broker部署相对复杂,Broker分为Master与Slave,⼀个Master可以对应多个Slave,但是⼀个Slave只能对应⼀个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,⾮0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建⽴⻓连接,定时注册Topic信息到所有Name Server。
  • Producer与Name Server集群中的其中⼀个节点(随机选择)建⽴⻓连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建⽴⻓连接,且定时向Master发送⼼跳。Producer完全⽆状态,可集群部署。
  • Consumer与Name Server集群中的其中⼀个节点(随机选择)建⽴⻓连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master、Slave建⽴⻓连接,且定时向Master、Slave发送⼼跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。
13. RocketMq逻辑结构

Producer Group

⽤来表示⼀个发送消息应⽤,⼀个Producer Group下包含多个Producer实例,可以是多台机器,也可以是⼀台机器的多个进程,或者⼀个进程的多个Producer对象。⼀个Producer Group可以发送多个Topic消息,Producer Group

作⽤如下:

  1. 标识⼀类Producer
  2. 可以通过运维⼯具查询这个发送消息应⽤下有多个Producer实例
  3. 发送分布式事务消息时,如果Producer中途意外宕机,Broker会主动回调Producer Group内的任意⼀台机器来确认事务状态。

Consumer Group

⽤来表示⼀个消费消息应⽤,⼀个Consumer Group下包含多个Consumer实例,可以是多台机器,也可以是多个进程,或者是⼀个进程的多个Consumer对象。⼀个Consumer Group下的多个Consumer以均摊⽅式消费消息,如果设置为⼴播⽅式,那么这个Consumer Group下的每个实例都消费全量数据。

14. RocketMq数据存储结构

如上图所示,RocketMQ采取了⼀种数据与索引分离的存储⽅法。有效降低⽂件资源、IO资源,内存资源的损耗。即便是阿⾥这种海量数据,⾼并发场景也能够有效降低端到端延迟,并具备较强的横向扩展能⼒。

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
打赏
0
0
0
0
237
分享
相关文章
Java大厂面试高频:Collection 和 Collections 到底咋回答?
Java中的`Collection`和`Collections`是两个容易混淆的概念。`Collection`是集合框架的根接口,定义了集合的基本操作方法,如添加、删除等;而`Collections`是一个工具类,提供了操作集合的静态方法,如排序、查找、同步化等。简单来说,`Collection`关注数据结构,`Collections`则提供功能增强。通过小王的面试经历,我们可以更好地理解这两者的区别及其在实际开发中的应用。希望这篇文章能帮助你掌握这个经典面试题。
30 4
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
113 2
招行面试:10Wqps场景,RocketMQ 顺序消费 的性能 如何提升 ?
45岁资深架构师尼恩在其读者群中分享了关于如何提升RocketMQ顺序消费性能的高并发面试题解析。面对10W QPS的高并发场景,尼恩详细讲解了RocketMQ的调优策略,包括专用方案如增加ConsumeQueue数量、优化Topic设计等,以及通用方案如硬件配置(CPU、内存、磁盘、网络)、操作系统调优、Broker配置调整、客户端配置优化、JVM调优和监控与日志分析等方面。通过系统化的梳理,帮助读者在面试中充分展示技术实力,获得面试官的认可。相关真题及答案将收录于《尼恩Java面试宝典PDF》V175版本中,助力求职者提高架构、设计和开发水平。
招行面试:10Wqps场景,RocketMQ 顺序消费 的性能 如何提升 ?
Java面试必问!run() 和 start() 方法到底有啥区别?
在多线程编程中,run和 start方法常常让开发者感到困惑。为什么调用 start 才能启动线程,而直接调用 run只是普通方法调用?这篇文章将通过一个简单的例子,详细解析这两者的区别,帮助你在面试中脱颖而出,理解多线程背后的机制和原理。
29 12
Java Dubbo 面试题
Java Dubbo相关基础面试题
Java MyBatis 面试题
Java MyBatis相关基础面试题
招行面试:RocketMQ、Kafka、RabbitMQ,如何选型?
45岁资深架构师尼恩针对一线互联网企业面试题,特别是招商银行的高阶Java后端面试题,进行了系统化梳理。本文重点讲解如何根据应用场景选择合适的消息中间件(如RabbitMQ、RocketMQ和Kafka),并对比三者的性能、功能、可靠性和运维复杂度,帮助求职者在面试中充分展示技术实力,实现“offer直提”。此外,尼恩还提供了《尼恩Java面试宝典PDF》等资源,助力求职者提升架构、设计、开发水平,应对高并发、分布式系统的挑战。更多内容及技术圣经系列PDF,请关注【技术自由圈】获取。
Java JVM 面试题
Java JVM(虚拟机)相关基础面试题
Java Druid 面试题
Java Druid 连接池相关基础面试题
Java 多线程 面试题
Java 多线程 相关基础面试题
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等