阿里面试:说说你项目里使用的 MQ ,分布式系统中 MQ 作用?

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

开篇思考

  1. MQ 为什么在系统中使用?一定要在分布式系统中使用吗?
  2. MQ 有哪些中间件?他们有哪些特点?
  3. MQ 给系统带来好处的同时有没有带来什么问题?如何解决?

在阿里的面试中,面试官问到关于 MQ 的几个问题:

  • 你的项目中 MQ 的作用?
  • 为什么选择这款 MQ 作为消息中间件?
  • 重复消费怎么办?
  • 如何确保消息被消费?
  • 有遇到其他问题吗?
    那么接下来带着问题先思考下,有好的想法可以在评论区留言,大家一起分享。

消息中间件在系统中的使用

我之前写过一篇关于 rocketMQ 实现分布式锁的文章,主要介绍如何使用 RocketMQ 实现分布式锁,
《Springcloud + RocketMQ 解决分布式事务》
但是这个功能并不是 MQ 基本功能,也不是所有 MQ 都有的功能。

MQ 在系统中到底有哪些作用呢?抛开基本的消息发布订阅不说,还有以下几点:

  1. 分布式系统解耦
  2. 不需要立即返回的业务异步处理
  3. 削峰填谷,不直接访问服务,缓解服务压力,增加性能
  4. 日志记录

分布式系统解耦

解耦

在分布式系统中,要么是通过 rest 调用,要么是通过 dubbo 等 RPC 调用,但是有些场景需要解耦设计,不能直接调用。
比如消息驱动的系统中,消息发送者完成本地业务,发送消息,多平台的消息消费者服务需要收到推送的消息,然后继续处理其他业务。

看这两个架构图,第一种 BC 都直接依赖 A 服务,那么如果 A 中的接口修改,BC 都要跟着做修改,耦合度高。
第二种,通过 MQ 来作为中间件收发消息,BC 只依赖收到的消息而不是具体的接口,这样即使 A 服务修改或者增加其他服务,都只要订阅MQ就行。

不要求实时的业务异步处理

用户注册业务流程为例,

  1. 用户注册入库
  2. 用户验证邮件发送
  3. 用户验证短信发送

原来的系统设计,这样的服务流程会串行处理,即先 1-2-3 ;但是这里可以思考下,如果单个服务单台机器的情况下,注册用户特别多,系统能不能抗住?

这里假设各个阶段的时间 1 = 50ms , 2 = 50ms , 3 = 50ms,那么一个请求下来就是 all = 150ms;
这里再假设,这个服务器 CPU = 1 , 且只能处理单线程,那么以这种单台服务器单线程的 QPS 来算;QPS = 1000/150 ≈ 7
现在我要让这个 QPS * 3 提升三倍,这个时候引入 MQ 服务作为中间件

异步

如图可见,我在 A 服务用户注册完成后,就直接返回了,这个时候 MQ 用来发送异步处理消息,B,C 服务分别处理。
A 不用等待 B、C 的返回结果 ,这样用户体验就是只有 50ms 等待时间。而在邮件、短信这个阶段,因为网络延迟原因,
用户可以接受一定时间的等待。

削峰填谷

一般的服务,我们的请求访问到系统都是直接请求,这样的模式在用户访问量不大的情况下,问题不是很大。
但是如果用户请求达到了一定的瓶颈或者产生了一些问题,我们就需要考虑优化我们的架构设计,MQ 中间件正是解决办法之一。

下面以秒杀系统为例分析问题
秒杀系统瞬间百万并发,怎么处理?一般秒杀系统会进行请求过滤,无效、重复都会被过滤一遍,剩下的才真正进入到秒杀服务、订单服务。
但即使这样并发仍然很高,如果网关把全部请求都转发到下游订单服务,一样会压垮下游系统,造成服务不可用甚至雪崩。

秒杀的队列使用
真实的秒杀系统更复杂 ,包含 Nginx 、网关、注册中心、redis 缓存、mysql 集群、消息队列集群

解决方式就是将上游处理的较快的任务,加入到队列处理,下游逐一消费队列,直到所有队列消费完成。
假如秒杀服务处理请求数:1000/s,
下游订单服务处理请求书:10/s,
为了不给下游订单服务造成压力,秒杀后的信息发送到队列,订单服务就可以从容淡定的每秒处理十个,而不是直接塞 1000 个请求
也不管人家愿意不愿意。

到这里,可以总结下秒杀系统的过滤方式:

  1. 页面按钮点击一次置灰
  2. 每秒透过请求数限制,例如 100/s,可以使用 Nginx ,sentinel
  3. 过滤同一用户的重复请求,通过用户唯一标识、商品信息,
  4. 通过消息队列存储成功的秒杀信息,下游订单系统处理

日志

所有服务都将日志发送到 MQ 服务用来作为日志存储。
MQ 作为中间件对日志进行持久化、转发
大数据服务对 MQ 读取和进行日志分析

日志处理基本流程

MQ 怎么选

有人上来就是一通性能比较,然后说 RabbitMQ 是世界上最好的 MQ...
你把挑选 MQ 比作挑老婆吧,上来就要全套,肤白貌美、前凸后翘、性感火辣、勤劳能干。。。
真是缺乏社会的教育啊,兄弟
养得起吗?动不动一套保养套餐,1W/月
守得住吗?隔壁老王经常来你家吃饭吧,疯狂脑补。。。
吃的消吗?红枣+枸杞+肾宝片,怕是心有余力不足吧

言归正传,其实我觉得这是一个思考题,首先我们要看的应该是条件是哪些?

  1. 用途?是用来做日志、解耦、还是异步处理
  2. 公司情况?人员是否充足,现有人员技术栈情况,人员的技术栈实力
  3. 项目情况?项目周期,人员,用户量,架构设计,是否老项目
  4. 主流 MQ 现状?稳定可靠度,社区活跃度,文档全面性,云服务支持情况

上图的例子日志消息就是使用的 kafka,为什么是kafka?
Kafka是LinkedIn开源的分布式发布-订阅消息系统,属于 Apache 顶级项目,社区活跃。
Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输。
后来版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务。
但是 kafka 相对来说很重,需要依赖 zookeeper,大公司里使用没问题,也少不了专人维护。

RocketMQ 是阿里开源的一套可靠消息系统,已经捐赠 Apache 成为顶级项目。刚开始定位于非日志的可靠消息传输,其实在日志处理方面性能也不错。
目前支持的客户端包括 java,c++,GO ,社区比较活跃,文档还算全面。但是涉及到核心的要修改还是有难度的,毕竟阿里云靠卖这个服务赚钱呢。
所以如果公司实力不自信还是慎重选择吧,实在不行可以直接购买云服务,省心省力,还是那句话,看实际情况。

主流 MQ 的特点

下图是来源网络的图片,部分描述已经过时,但是基本不差,仅供参考:
主流 MQ 比较(网络图)

如何确保消息不被重复消费

这里简单说说,后面专门针对这个问题进行书写招供。
大致就是一些特殊原因例如网络原因,服务重启造成消息消费未被记录,造成重复消费的可能。
一般的处理方式就是保证接口设计的幂等性,主旨通过唯一标识判断是否存在。

  1. redis 缓存使用,唯一性 token 保存redis,每次消费后删除 token
  2. 唯一主键判断,数据库判断是否存在该主键记录,存在则更新,不存在则插入

喜欢文章请关注我

程序领域

点击关注+转发,私信发送【面试】或者【资料】可以收获更多资源

相关实践学习
消息队列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
1
分享
相关文章
阿里面试:为什么要索引?什么是MySQL索引?底层结构是什么?
尼恩是一位资深架构师,他在自己的读者交流群中分享了关于MySQL索引的重要知识点。索引是帮助MySQL高效获取数据的数据结构,主要作用包括显著提升查询速度、降低磁盘I/O次数、优化排序与分组操作以及提升复杂查询的性能。MySQL支持多种索引类型,如主键索引、唯一索引、普通索引、全文索引和空间数据索引。索引的底层数据结构主要是B+树,它能够有效支持范围查询和顺序遍历,同时保持高效的插入、删除和查找性能。尼恩还强调了索引的优缺点,并提供了多个面试题及其解答,帮助读者在面试中脱颖而出。相关资料可在公众号【技术自由圈】获取。
招行面试: 分布式调度 设计,要考虑 哪些问题?
45岁资深架构师尼恩在读者交流群中分享了关于设计分布式调度框架时需考虑的关键问题。近期有小伙伴在面试招商银行时遇到了相关难题,因准备不足而失利。为此,尼恩系统化地梳理了以下几点核心内容,帮助大家在面试中脱颖而出,实现“offer直提”。
招行面试:RocketMQ、Kafka、RabbitMQ,如何选型?
45岁资深架构师尼恩针对一线互联网企业面试题,特别是招商银行的高阶Java后端面试题,进行了系统化梳理。本文重点讲解如何根据应用场景选择合适的消息中间件(如RabbitMQ、RocketMQ和Kafka),并对比三者的性能、功能、可靠性和运维复杂度,帮助求职者在面试中充分展示技术实力,实现“offer直提”。此外,尼恩还提供了《尼恩Java面试宝典PDF》等资源,助力求职者提升架构、设计、开发水平,应对高并发、分布式系统的挑战。更多内容及技术圣经系列PDF,请关注【技术自由圈】获取。
说说MQ在你项目中的应用(一)
本文总结了消息队列(MQ)在项目中的应用,主要围绕异步处理、系统解耦和流量削峰三大功能展开。通过分析短信通知和业务日志两个典型场景,介绍了MQ的实现方式及其优势。短信通知中,MQ用于异步发送短信并处理状态更新;业务日志中,Kafka作为高吞吐量的消息系统,负责收集和传输系统及用户行为日志,确保数据的可靠性和高效处理。MQ不仅提高了系统的灵活性和响应速度,还提供了重试机制和状态追踪等功能,保障了业务的稳定运行。
60 6
面试官必问的分布式锁面试题,你答得上来吗?
本文介绍了分布式锁的概念、实现方式及其在项目中的应用。首先通过黄金圈法则分析了分布式锁的“为什么”、“怎么做”和“做什么”。接着详细讲解了使用 Redisson 和 SpringBoot + Lettuce 实现分布式锁的具体方法,包括代码示例和锁续期机制。最后解释了 Lua 脚本的作用及其在 Redis 中的应用,强调了 Lua 保证操作原子性的重要性。文中还提及了 Redis 命令组合执行时的非原子性问题,并提供了 Lua 脚本实现分布式锁的示例。 如果你对分布式锁感兴趣或有相关需求,欢迎关注+点赞,必回关!
36 2
阿里面试:聊聊 CAP 定理?哪些中间件是AP?为什么?
本文深入探讨了分布式系统中的“不可能三角”——CAP定理,即一致性(C)、可用性(A)和分区容错性(P)三者无法兼得。通过实例分析了不同场景下如何权衡CAP,并介绍了几种典型分布式中间件的CAP策略,强调了理解CAP定理对于架构设计的重要性。
64 4
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
本文深入探讨了消息队列的核心概念、应用场景及Kafka、RocketMQ、RabbitMQ的优劣势比较,大厂面试高频,必知必会,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
说说MQ在你项目中的应用(二)商品支付
本文总结了消息队列(MQ)在支付订单业务中的应用,重点分析了RabbitMQ的优势。通过异步处理、系统解耦和流量削峰等功能,RabbitMQ确保了支付流程的高效与稳定。具体场景包括用户下单、支付请求、商品生产和物流配送等环节。相比Kafka,RabbitMQ在低吞吐量、高实时性需求下表现更优,提供了更低延迟和更高的可靠性。
34 0
C#使用Socket实现分布式事件总线,不依赖第三方MQ
`CodeWF.EventBus.Socket` 是一个轻量级的、基于Socket的分布式事件总线系统,旨在简化分布式架构中的事件通信。它允许进程之间通过发布/订阅模式进行通信,无需依赖外部消息队列服务。
C#使用Socket实现分布式事件总线,不依赖第三方MQ
阿里面试:亿级 redis 排行榜,如何设计?
本文由40岁老架构师尼恩撰写,针对近期读者在一线互联网企业面试中遇到的高频面试题进行系统化梳理,如使用ZSET排序统计、亿级用户排行榜设计等。文章详细介绍了Redis的四大统计(基数统计、二值统计、排序统计、聚合统计)原理和应用场景,重点讲解了Redis有序集合(Sorted Set)的使用方法和命令,以及如何设计社交点赞系统和游戏玩家排行榜。此外,还探讨了超高并发下Redis热key分治原理、亿级用户排行榜的范围分片设计、Redis Cluster集群持久化方式等内容。文章最后提供了大量面试真题和解决方案,帮助读者提升技术实力,顺利通过面试。