《面试之MQ篇》

《面试之MQ篇》

1. 为什么要使用MQ

• 首先,面试官问的第一个问题或者说是逼问的一个问题："为什么要使用MQ"
• 其实面试官问这个问题就是想考察你MQ的特性，这个时候呢，我们必须要答出三点：解耦、异步、削峰。

1. 解耦

1. 传统系统耦合问题

• 在没有消息队列的系统中，系统组件之间的通信往往是直接的、紧耦合的。
• 例如，在一个电商系统中，订单系统和库存系统可能直接相互调用。当订单系统收到一个新订单时，它会立即调用库存系统的接口来扣减库存。这种紧密耦合的方式使得系统难以维护和扩展。
• 如果库存系统的接口发生变化，比如增加了新的参数或者修改了接口的返回值，那么订单系统也需要相应地修改代码来适应这种变化。而且，当库存系统出现故障时，订单系统的订单处理功能可能也会受到影响，因为它依赖于库存系统的正常运行。

2. 消息队列解耦的优势

• 使用消息队列后，订单系统和库存系统之间通过消息进行通信。订单系统将订单信息作为消息发送到消息队列中，库存系统从消息队列中获取订单消息并进行库存扣减。这样，订单系统和库存系统就不再直接相互依赖。
• 库存系统的接口变化不会直接影响订单系统，只要消息的格式和内容保持一致，订单系统就可以继续正常工作。同时，即使库存系统出现故障，订单消息可以在消息队列中暂存，等库存系统恢复后再进行处理，不会导致订单系统的功能受阻。

2. 异步

1. 同步处理的局限性

• 以用户注册场景为例，在一个简单的系统设计中，如果没有消息队列，用户提交注册信息后，系统可能需要依次完成多项任务，如验证用户信息、创建用户数据库记录、发送注册邮件等。这些任务都是同步执行的，用户需要等待所有任务完成后才能得到注册成功的反馈。
• 假设验证用户信息需要 1 秒，创建用户记录需要 2 秒，发送注册邮件需要 3 秒，那么用户总共需要等待 6
  秒才能得到注册成功的反馈。这种长时间的等待会导致用户体验不佳，尤其是在高并发的情况下，系统的响应时间会变得很长。

2. 消息队列异步处理的优势

• 使用消息队列后，用户提交注册信息后，系统可以将注册信息作为消息发送到消息队列中，然后立即返回注册成功的反馈给用户。后台的服务可以从消息队列中获取注册消息，分别异步地进行验证用户信息、创建用户记录和发送注册邮件等任务。
• 这样，从用户的角度来看，响应时间大大缩短，可能只需要几毫秒就能得到注册成功的反馈。同时，系统的整体性能也得到了提升，因为这些任务可以在后台并行地进行处理，而不是依次等待完成。

3. 削峰

1. 流量高峰的挑战

• 在一些高并发的场景中，如电商的秒杀活动或者热门景点的门票预订，系统可能会在短时间内接收到大量的请求。如果没有消息队列，这些请求会直接冲击后端的服务，如数据库、应用服务器等。
• 以秒杀活动为例，假设数据库每秒只能处理 1000 个订单插入操作，但秒杀活动开始时每秒有 10000
  个订单请求。如果所有请求直接发送到数据库，数据库很可能会因为不堪重负而出现性能下降、甚至崩溃的情况。

2. 消息队列削峰的原理和优势

• 使用消息队列后，这些大量的请求可以先发送到消息队列中进行缓冲。消息队列可以承受高并发的消息流入，将请求暂时存储起来。后端的服务可以按照自己的处理能力从消息队列中获取消息进行处理。
• 例如，数据库每秒能处理 1000
  个订单，那么它就可以以这个速度从消息队列中获取订单消息进行处理。这样，通过消息队列的缓冲作用，有效地避免了后端服务被瞬间的高流量冲垮，保证了系统的稳定性和可靠性。

1.1. 总结话术

面试官您好 ，使用消息队列（MQ）主要有三个重要原因。
首先 呢就是mq具有解耦的特性，在复杂的软件系统中，不同的模块之间往往存在着紧密的依赖关系。如果不使用 MQ，模块之间可能会直接进行方法调用，这会导致高度耦合。例如，在一个电商系统中，订单模块和库存模块、物流模块等可能直接交互。一旦其中一个模块的接口发生变化，就会影响到与之直接交互的其他模块，使得系统的维护变得极为困难。

而引入 MQ 后，各个模块之间通过发送和接收消息进行通信，不再直接依赖对方的接口。订单模块在生成订单后，将订单消息发送到 MQ，库存模块和物流模块从 MQ 中获取订单消息并进行相应的处理。这样，即使某个模块出现故障，也不会直接影响到其他模块的正常运行，极大地提高了系统的可维护性和可扩展性。
再一个 呢就是因为它能异步处理消息了，

在没有 MQ 的情况下，很多业务流程往往是同步执行的。比如在一个在线教育平台中，学生提交作业后，系统需要进行作业存储、批改、反馈等一系列操作。如果这些操作都是同步进行的，学生就需要等待所有操作完成后才能得到反馈，这会导致响应时间过长，影响用户体验。

使用 MQ 后，可以将这些操作异步化。学生提交作业后，系统将作业提交的消息发送到 MQ，然后立即返回提交成功的响应。后台的作业存储、批改、反馈等服务可以从 MQ 中获取作业消息并进行异步处理。这样，学生能够快速得到反馈，同时系统也能够更加高效地利用资源，提高整体性能。
最后一点 就是因为它具有流量削峰的特性，

在一些特定场景下，系统可能会面临瞬间的高流量冲击。比如电商平台的促销活动、抢购活动等，短时间内会有大量的用户请求涌入。如果没有 MQ，这些请求会直接到达后端服务，可能会导致服务过载甚至崩溃。

通过 MQ，可以将这些突发的高流量请求缓冲起来。用户的请求先发送到 MQ，后端服务按照自己的处理能力从 MQ 中获取请求进行处理。这样就能够有效地避免系统因瞬间高流量而崩溃，保证系统在高负载情况下的稳定性。

我的回答完毕，谢谢！

2. 消息队列有什么优点和缺点

1. 优点

（一）解耦系统

传统系统耦合问题说明

• 在传统的紧耦合系统中，系统的各个模块之间直接相互调用。例如，在一个电商系统里，订单系统和库存系统紧密相连。当订单系统接收到一个新订单时，它会马上调用库存系统的接口来更新库存。这种方式使得两个系统高度依赖彼此的接口细节。
• 如果库存系统的接口发生变化，比如增加了一个新的参数用于记录库存更新的原因，那么订单系统就需要相应地修改代码来适应这个新参数。而且，当库存系统出现故障，订单系统可能会因为无法成功调用库存更新接口而无法正常处理订单。

消息队列解耦原理及优势

• 消息队列的引入改变了这种紧密耦合的状态。以刚才的电商系统为例，订单系统将新订单信息作为消息发送到消息队列中，库存系统从消息队列中获取消息来更新库存。
• 这样一来，订单系统和库存系统之间不再直接依赖对方的接口。库存系统的接口变化只要不影响消息的格式和内容，就不会对订单系统产生影响。即使库存系统出现故障，订单消息可以在消息队列中暂存，等到库存系统恢复后再进行处理，从而提高了系统的可维护性和灵活性。

（二）异步处理

同步处理的局限案例分析

• 考虑一个用户注册的场景。在没有消息队列的系统中，用户提交注册信息后，系统需要依次完成验证用户信息（假设耗时 1 秒）、创建用户数据库记录（假设耗时 2 秒）、发送注册欢迎邮件（假设耗时 3 秒）等操作。
• 这些操作是同步执行的，用户需要等待所有操作完成后才能得到注册成功的反馈，总共需要等待 1 + 2 + 3 = 6 秒，这在用户体验上是比较差的，尤其是在高并发的情况下，系统的响应时间会因为这种同步等待而变得很长。

消息队列异步处理优势阐述

• 当使用消息队列时，用户提交注册信息后，系统将注册信息作为消息发送到消息队列中，然后立即返回注册成功的反馈给用户。
• 后台的服务可以从消息队列中获取注册消息，分别异步地进行验证用户信息、创建用户记录和发送注册欢迎邮件等操作。这样从用户角度来看，响应时间可能缩短到几毫秒，大大提升了用户体验。同时，系统的整体性能也得到提高，因为这些任务可以在后台并行地进行处理，提高了资源的利用效率。

（三）流量削峰

流量高峰的危害示例

• 在电商的秒杀活动中，瞬间可能会有成千上万的用户请求涌入。如果没有消息队列，这些请求会直接冲击后端的服务，比如数据库。
• 假设数据库每秒能够稳定处理 1000 笔订单插入操作，但在秒杀活动开始的瞬间，每秒有 10000 笔订单请求。如果所有请求直接发送到数据库，数据库很可能会因为不堪重负而出现性能下降，如查询和插入操作变得极其缓慢，甚至可能会因为资源耗尽而崩溃。

消息队列削峰机制及优势

• 消息队列可以将这些大量的请求先缓冲起来。在秒杀场景中，用户的订单请求先发送到消息队列。后端的数据库服务可以按照自己的处理能力，比如每秒处理 1000 笔订单的速度，从消息队列中获取订单消息进行处理。
• 这样就有效地避免了后端服务被瞬间的高流量冲垮，使得系统在高负载情况下依然能够保持相对稳定的运行状态，保证了系统的可靠性。

（四）广播和多播能力

广播功能说明及应用场景

• 消息队列可以将一条消息广播给多个消费者。例如，在一个新闻发布系统中，当有重要新闻发布时，消息队列可以将新闻消息广播给所有订阅了新闻频道的客户端应用。
• 这些客户端应用可以是网页端、移动端等不同平台的应用，它们都能从消息队列中获取到相同的新闻消息，从而实现了消息的广泛传播。

多播功能介绍及适用场景

• 多播功能则允许消息被发送到一组特定的消费者。以一个企业内部的系统为例，当有一个部门级别的通知需要发送时，消息队列可以将通知消息发送给该部门对应的一组消费者，如该部门的员工使用的工作软件客户端。
• 这种广播和多播能力提高了消息传递的效率，使得消息能够快速地到达多个目标接收者，适合于需要一对多或组播消息传递的场景。

（五）可扩展性

水平扩展的便利性

• 消息队列系统本身通常很容易进行水平扩展。随着业务的增长，系统的消息处理量不断增加，可以通过添加更多的消息队列服务器或者消息代理（如在RocketMQ 中的 Broker）来处理更多的消息。
• 例如，当一个电商平台的订单消息量从每天 10 万条增长到每天 100 万条时，可以增加消息队列服务器的数量来应对这种增长。新添加的服务器可以分担原有的消息处理任务，并且在配置好相关的路由和负载均衡后，整个系统可以平稳地运行，不需要对现有系统的架构进行大规模的修改。

对业务扩展的支持

• 对于业务系统来说，消息队列的可扩展性也提供了很大的便利。以一个物流系统为例，随着业务的拓展，需要增加新的物流服务提供商或者新的物流信息处理模块。
• 只要这些新的模块遵循消息队列的消息格式和通信协议，就可以很容易地接入到现有的消息队列系统中。它们可以从消息队列中获取自己需要的消息，如订单发货消息或者货物运输状态消息，从而实现了业务系统的平滑扩展。

2. 缺点

（一）系统复杂性增加

架构复杂性

• 引入消息队列后，系统架构变得更加复杂。除了原有的业务系统模块，还需要引入消息队列服务器、消息生产者和消费者等组件。
• 例如，在一个简单的三层架构（表示层、业务逻辑层、数据访问层）的应用中，加入消息队列后，需要考虑如何在业务逻辑层正确地生产消息，以及在其他可能的模块中作为消费者接收和处理消息。这需要设计新的通信路径和处理逻辑，增加了系统架构设计的难度。

运维复杂性

• 消息队列的运维也比较复杂。需要监控消息队列服务器的性能指标，如消息堆积情况、服务器的负载、网络带宽的使用等。
• 当出现问题时，如消息丢失、消息重复消费等，需要有相应的技术手段来解决。例如，要确定消息丢失是在生产阶段、传输阶段还是消费阶段，并且采取不同的措施来恢复丢失的消息，这对运维人员的技术要求较高。

（二）一致性问题

最终一致性挑战

• 在分布式系统中，使用消息队列可能会导致数据一致性的问题。例如，一个事务涉及多个系统，其中一个系统通过消息队列发送消息来触发其他系统的操作。
• 由于消息队列的异步特性，可能会出现消息还未被其他系统处理，而发起事务的系统已经完成了自己部分的操作并提交。这就导致了系统之间的数据在一段时间内可能不一致，需要通过一些额外的机制来保证最终一致性。

分布式事务处理困难

• 处理分布式事务与消息队列结合的情况比较复杂。比如在一个包含消息队列的电商系统中，订单系统和库存系统通过消息队列通信来处理订单和库存事务。
• 如果订单系统成功发送了订单消息，但库存系统在消费消息时出现故障，就需要有复杂的机制来处理这种情况，如事务补偿机制、消息重试等，以确保订单和库存操作最终能够正确完成，保证系统的一致性。

（三）消息可靠性问题

消息丢失风险

• 消息在生产、传输和消费过程中都有可能丢失。在生产阶段，如果生产者没有正确地将消息发送到消息队列，或者消息队列服务器出现故障导致消息未被正确接收，就会发生消息丢失。
• 例如，在网络不稳定的情况下，生产者发送消息时可能因为网络中断而无法成功将消息发送到消息队列。在传输过程中，如果消息队列服务器之间的网络出现故障或者存储出现问题，也可能导致消息丢失。

消息重复消费风险

• 消息可能会被重复消费。例如，消费者在处理消息后，由于网络抖动或者系统故障等原因，没有正确地向消息队列确认消息已经被消费，消息队列可能会认为该消息没有被消费，从而将消息再次发送给消费者。
• 这就需要消费者具备幂等性（即对同一操作的多次重复执行结果和单次执行结果相同）来避免重复消费带来的问题，增加了系统开发的复杂性。

3. RabbitMQ死信队列、延时队列分别是什么

1. 死信队列

DLX（Dead Letter Exchange），死信交换器。

当队列中的消息被拒绝、或者过期会变成死信，死信可以被重新发布到另一个交换器，这个交换器就是DLX，与DLX绑定的队列称为死信队列。 造成死信的原因：

• 信息被拒绝
• 信息超时
• 超过了队列的最大长度

2. 延迟队列

• 延迟队列存储的是延迟消息

延迟消息指的是，当消息被发发布出去之后，并不立即投递给消费者，而是在指定时间之后投递。如：

在订单系统中，订单有30秒的付款时间，在订单超时之后在投递给消费者处理超时订单。

• rabbitMq没有直接支持延迟队列，可以通过死信队列实现。
• 在死信队列中，可以为普通交换器绑定多个消息队列，假设绑定过期时间为5分钟，10分钟和30分钟，3个消息队列，然后为每个消息队列设置DLX，为每个DLX关联一个死信队列。
• 当消息过期之后，被转存到对应的死信队列中，然后投递给指定的消费者消费。