消息队列面试大全

北慕城南 提交于 2020-02-24 05:05:22


分布式构建三把斧:缓存+异步+数据分组
支付状态:未支付,支付成功,支付失败,待退款,已退款
快递状态:代发货,待收货,已收货,退货-商家待收货,退货-商家已收货
订单状态:订单打开,订单取消,订单关闭,订单完成

消息队列引入

Http请求适用于耗费数百毫秒或更少时间执行任务,当业务耗时达到一两秒种或更长时,需要。
例如

  1. 下单送积分,下单是最主要的,送积分可以异步去做
  2. 订单支付成功短信通知,返回支付订单进入下一环节更重要,短信通知可以异步执行
  3. 订单系统的日志收集功能

你在项目种使用过消息队列么?公司使用什么消息架构

ActiveMq: 分发效率最高,是其他队列的几十倍,缺点是不能做数据持久化
RabbitMQ:使用Erlang语言开发的开源消息队列,基于AMQP协议实现,支持消息的可靠传输,支持事务,不支持批量操作。
Kafka:最初由领英开发,以可水平扩展和高吞吐率被广泛使用,同等硬件Kafka性能超过传统的消息中间件,我们公司使用的消息队列中间件就是Kafka搭建的。

消息队列和异步调用的区别

  1. 异步调用其实就是异步线程处理,通常用于在单体应用中进行异步处理,一般不会涉及到多个系统的协作
  2. mq通常用于在多个分布式应用间进行通信,实现了应用的解耦,提升了系统负载能力

那些业务场景使用了消息队列

我在公司的核心部分负责的是订单核心系统(具体什么订单系统自行yy一个)
用户下单——>用户支付——>商家接单——>订单配送——>用户收货——>后续售后——>订单完成
从普通用户的角度来看,一个外卖订单从下单后,会经历支付、商家接单、配送、用户收货、售后及订单完成多个阶段。
以技术的视角来分解的话,每个阶段依赖多个子服务来共同完成,比如下单会依赖购物车,订单预览,订单确认等服务,这些子服务又依赖于底层基础系统来完成器功能

一个服务同步的操作越少,性能越好,通过将部分服务异步化来减少需要同步进行的操作,进而提升服务的整体性能
a)使用消息队列:异步操作通过接收消息完成
b) 使用多线程:将异步操作放在单独的线程中处理,避免阻塞服务线程

由于我们的系统准备分布式部署,而且还得保证系统具有削峰限流,海量信息堆积,高吞吐量,可靠重试等特性,所以我们引入mq实现异步操作

  1. 比如在订单模块,采集日志是系统中经常用到的功能,业务系统流量高,数据量大,响应时间要求高,如果想收集日志,那么收集日志的动作一定不能影响订单主流程,采集日志就可以通过使用mq来实现

  2. 比如在秒杀模块,不仅需要及时响应客户端请求,而且还不能把入库请求同时都涌入了数据库,使用了mq进行了异步下单

  3. 消费积分功能,用户没消费一笔给用户增加一定的积分,引入mq来实现异步

消息队列的优点

扣减库存后,才能进行支付

  1. 实现异步处理,异步处理操作不会阻碍主流程的返回,减少了同步操作,使得系统极大提升系统的并发量
  2. 实现了应用解耦,契合了微服务时代单一职责原则
  3. 实现了削峰限流,例如在订单系统中,订单接口在应对高峰流量时,比如在做"秒杀活动"时,日志服务接口处理能力有限,可以先将日志消息积压在队列中,后台慢慢处理
  4. 实现了发布/订阅,一条消息广播给任意收听方,就像广播一样,是系统之间跨机房跨机器通讯的主要手段。例如在下订单流程中,订单系统确认订单,给用户跳转支付页面,支付成功后,支付系统广播一条message:用户xx已经确认付款,订单系统订阅该消息,将订单状态改成已支付;物流系统订阅该消息,物流系统开始发货。

消息中间件的缺点

凡事都有两面性,不能只考虑到消息队列的优点,分布式环境下,引入mq后提升了系统复杂度,并且带来了一系列问题。

  1. 消息丢失问题
    任何系统不能保证万无一失,如果producer发出1000条消息,consumer只收到999条,需要判断消费者能够接收丢失一条的结果。
    如果是下订单成功发成功短信可以接收丢失一条,就是有一个顾客没有接收到通知但货已经发出去了(抢先购不能接收)。但如果是支付系统,用户已经付款却因为消息丢失没有通知到订单系统and物流系统,那顾客肯定要找平台了
  2. 消息重复问题:消费者能够接收到一条重复消息,这个是系统设计者需要考虑的问题
  3. 消息顺序问题:需要考虑消费者对顺序是否敏感
  4. 一致性问题:如果消息丢失而无法找回,会导致两个系统的 数据最终不一致。如果消息延迟,会造成短暂不一致

Kafka概述

Kafka 是我工作多年使用最多的消息中间件 ,特点是”

简述kafka架构下的重要关键字

为什么要选择kafka

  1. 相比同类消息中间件RabbitMQ or ActiveMQ,kafka支持批量拉取消息,大大增加了kafka的消息吞吐量
  2. 支持多种发送场景:1. 发送并忘记 2.同步发送 3. 异步发送+回调函数
    具体使用哪种方式要看具体的业务场景,比如业务要求消息必须是按顺序发送,可以使用第2种同步发送,并且只能在一个partation上。如果业务只关心消息的吞吐量,容许少量消息发送失败,也不关注消息的发送顺序,那么可以使用发送并忘记的方式。如果业务需要知道消息发送是否成功,并且对消息的顺序不关心,那么可以用异步+回调的方式来发送消息
  3. 分布式高可用扩展,可以透明的进行扩展

kafka和rabbitMQ区别

kafka和rabitMQ的区别
1.在应用场景方面
rabbitmq遵循amqp协议,由高并发的erlang语言开发,用在对可靠性要求比较高的消息传递上
kafka是基于发布订阅的分布式消息系统,以可水平扩展和高吞吐率被广泛使用,用在大数据流处理,以及对吞吐率要求比较高的消息传递上
2.在架构模型方面
rabbitmq由exchange,binding,queue组成,通过binding队列路由键到交换器上路由,消费者从queue中进行消费,有消息的确认机制
kafka遵从一般的架构模型,producer,broker,consumer,consumer从broker上pull数据,无消息确认机制
3.在可靠性方面
rabmq是通过持久化消息,持久化交换器,持久化队列来保证数据不丢失
kafka是通过副本冗余机制保证可靠性的,维护了一个ISR
4.保证消息的不丢不重方式机制上不同
虽然都是使用ack机制,但是实现机制不同
kafka生产消息保证不丢,消费者消费消息保证不重
rabbitmq发送方确认模式,接收方确认机制

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!