消息队列经典十连问(一)

发布于 2022-5-27 17:54
浏览
0收藏

 

前言 
大家好呀,我是捡田螺的小男孩。金三银四即将来临,整理了十道十分经典的消息队列面试题,看完肯定对面试有帮助的,大家一起加油哈~

  1. 什么是消息队列
  2. 消息队列的应用场景
  3. 消息队列如何解决消息丢失问题
  4. 消息队列如何保证消息的顺序性。
  5. 消息有可能发生重复消费吗?如何幂等处理?
  6. 如何处理消息队列的消息积压问题
  7. 消息队列技术选型,Kafka还是RocketMQ,还是RabbitMQ
  8. 消息中间件如何做到高可用?
  9. 如何保证数据一致性,事务消息如何实现
  10. 如果让你写一个消息队列,该如何进行架构设计?
    1. 什么是消息队列 
    你可以把消息队列理解为一个使用队列来通信的组件。它的本质,就是个转发器,包含发消息、存消息、消费消息的过程。最简单的消息队列模型如下:

 消息队列经典十连问(一)-开源基础软件社区
我们通常说的消息队列,简称MQ(Message Queue),它其实就指消息中间件,当前业界比较流行的开源消息中间件包括:RabbitMQ、RocketMQ、Kafka。

2. 消息队列有哪些使用场景。 
有时候面试官会换个角度问你,为什么使用消息队列。你可以回答以下这几点:

  1. 应用解耦
  2. 流量削峰
  3. 异步处理
  4. 消息通讯
  5. 远程调用
    2.1 应用解耦
    举个常见业务场景:下单扣库存,用户下单后,订单系统去通知库存系统扣减。传统的做法就是订单系统直接调用库存系统:

 消息队列经典十连问(一)-开源基础软件社区

  • 如果库存系统无法访问,下单就会失败,订单和库存系统存在耦合关系
  • 如果业务又接入一个营销积分服务,那订单下游系统要扩充,如果未来接入越来越多的下游系统,那订单系统代码需要经常修改
     消息队列经典十连问(一)-开源基础软件社区
    如何解决这个问题呢?可以引入消息队列

 消息队列经典十连问(一)-开源基础软件社区

  1. 订单系统:用户下单后,消息写入到消息队列,返回下单成功
  2. 库存系统:订阅下单消息,获取下单信息,进行库存扣减操作。
    2.2 流量削峰
    流量削峰也是消息队列的常用场景。我们做秒杀实现的时候,需要避免流量暴涨,打垮应用系统的风险。可以在应用前面加入消息队列。

 消息队列经典十连问(一)-开源基础软件社区
假设秒杀系统每秒最多可以处理2k个请求,每秒却有5k的请求过来,可以引入消息队列,秒杀系统每秒从消息队列拉2k请求处理得了。

有些伙伴担心这样会出现消息积压的问题,

  • 首先秒杀活动不会每时每刻都那么多请求过来,高峰期过去后,积压的请求可以慢慢处理;
  • 其次,如果消息队列长度超过最大数量,可以直接抛弃用户请求或跳转到错误页面;
    2.3 异步处理
    我们经常会遇到这样的业务场景:用户注册成功后,给它发个短信和发个邮件。

如果注册信息入库是30ms,发短信、邮件也是30ms,三个动作串行执行的话,会比较耗时,响应90ms:

 消息队列经典十连问(一)-开源基础软件社区
如果采用并行执行的方式,可以减少响应时间。注册信息入库后,同时异步发短信和邮件。如何实现异步呢,用消息队列即可,就是说,注册信息入库成功后,写入到消息队列(这个一般比较快,如只需要3ms),然后异步读取发邮件和短信。

 消息队列经典十连问(一)-开源基础软件社区
2.4 消息通讯
消息队列内置了高效的通信机制,可用于消息通讯。如实现点对点消息队列、聊天室等。

2.5 远程调用
我们公司基于MQ,自研了远程调用框架。

3. 消息队列如何解决消息丢失问题? 
一个消息从生产者产生,到被消费者消费,主要经过这3个过程:

 消息队列经典十连问(一)-开源基础软件社区
因此如何保证MQ不丢失消息,可以从这三个阶段阐述:

  • 生产者保证不丢消息
  • 存储端不丢消息
  • 消费者不丢消息
    3.1 生产者保证不丢消息
    生产端如何保证不丢消息呢?确保生产的消息能到达存储端。

如果是RocketMQ消息中间件,Producer生产者提供了三种发送消息的方式,分别是:

  • 同步发送
  • 异步发送
  • 单向发送
    生产者要想发消息时保证消息不丢失,可以:
  • 采用同步方式发送,send消息方法返回成功状态,就表示消息正常到达了存储端Broker。
  • 如果send消息异常或者返回非成功状态,可以重试。
  • 可以使用事务消息,RocketMQ的事务消息机制就是为了保证零丢失来设计的
    3.2 存储端不丢消息
    如何保证存储端的消息不丢失呢?确保消息持久化到磁盘。大家很容易想到就是刷盘机制。

刷盘机制分同步刷盘和异步刷盘:

  • 生产者消息发过来时,只有持久化到磁盘,RocketMQ的存储端Broker才返回一个成功的ACK响应,这就是同步刷盘。它保证消息不丢失,但是影响了性能。
  • 异步刷盘的话,只要消息写入PageCache缓存,就返回一个成功的ACK响应。这样提高了MQ的性能,但是如果这时候机器断电了,就会丢失消息。
    Broker一般是集群部署的,有master主节点和slave从节点。消息到Broker存储端,只有主节点和从节点都写入成功,才反馈成功的ack给生产者。这就是同步复制,它保证了消息不丢失,但是降低了系统的吞吐量。与之对应的就是异步复制,只要消息写入主节点成功,就返回成功的ack,它速度快,但是会有性能问题。

3.3 消费阶段不丢消息
消费者执行完业务逻辑,再反馈会Broker说消费成功,这样才可以保证消费阶段不丢消息。

4. 消息队列如何保证消息的顺序性。 
消息的有序性,就是指可以按照消息的发送顺序来消费。有些业务对消息的顺序是有要求的,比如先下单再付款,最后再完成订单,这样等。假设生产者先后产生了两条消息,分别是下单消息(M1),付款消息(M2),M1比M2先产生,如何保证M1比M2先被消费呢。

 消息队列经典十连问(一)-开源基础软件社区
为了保证消息的顺序性,可以将M1、M2发送到同一个Server上,当M1发送完收到ack后,M2再发送。如图:

 消息队列经典十连问(一)-开源基础软件社区
这样还是可能会有问题,因为从MQ服务器到消费端,可能存在网络延迟,虽然M1先发送,但是它比M2晚到。

 消息队列经典十连问(一)-开源基础软件社区
那还能怎么办才能保证消息的顺序性呢?将M1和M2发往同一个消费者,且发送M1后,等到消费端ACK成功后,才发送M2就得了。

 消息队列经典十连问(一)-开源基础软件社区
消息队列保证顺序性整体思路就是这样啦。比如Kafka的全局有序消息,就是这种思想的体现: 就是生产者发消息时,1个Topic只能对应1个Partition,一个 Consumer,内部单线程消费。

但是这样吞吐量太低,一般保证消息局部有序即可。在发消息的时候指定Partition Key,Kafka对其进行Hash计算,根据计算结果决定放入哪个Partition。这样Partition Key相同的消息会放在同一个Partition。然后多消费者单线程消费指定的Partition。

 

文章转自公众号:小白debug

分类
已于2022-5-27 17:54:32修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐