消息队列面试大全

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

消息队列引入

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

Kafka是一个流式处理平台，可以看作一个实时版的Hadoop，在这个平台可以发布和订阅数据流，可以存储和持续处理大型数据流。

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

kafka和rabbitMQ区别

kafka应用场景
用于事件驱动微服务系统的消息总线
流式应用和大规模数据管道

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发送方确认模式，接收方确认机制