[每周一更]-(第123期)：模拟面试｜消息队列面试思路解析

22｜消息队列：消息队列可以用来解决什么问题？

1. 你用过消息队列吗？主要用来解决什么问题？异步、削峰和解耦你能各举一个例子吗？
2. 你用的是哪个消息队列？为什么使用它而不用别的消息队列？
3. 为什么你一定要用消息队列？不用行不行？不用有什么缺点？
4. 在对接多个下游的时候，直接用 RPC 调用行不行？为什么？
5. 为什么说使用消息队列可以提高性能？
6. 为什么说使用消息队列可以提高扩展性？
7. 为什么说使用消息队列可以提高可用性？
8. 为什么秒杀场景中经常用消息队列？怎么用的？
9. 订单超时取消可以怎么实现？
10. 你了解事件驱动吗？
11. 什么是 SAGA 事务？怎么利用事件驱动来设计一个 SAGA 事务框架？

1. 你用过消息队列吗？主要用来解决什么问题？异步、削峰和解耦你能各举一个例子吗？

• 异步：将非关键任务异步处理。例如在电商平台中，用户下单后，需要发送订单确认短信，此类操作可以异步处理而不影响订单的主流程。
• 削峰：在高并发场景下，可以通过消息队列实现削峰填谷。例如秒杀活动期间，用户请求集中涌入，消息队列可以将请求排队，逐步发送给下游服务，避免服务崩溃。
• 解耦：实现不同系统间的解耦。比如，订单服务和库存服务之间通过消息队列传递信息，而不直接依赖。这样即使库存服务出现问题，订单服务依旧可以正常下单，将库存信息异步更新。

2. 你用的是哪个消息队列？为什么使用它而不用别的消息队列？

常见的消息队列有 RabbitMQ、Kafka、ActiveMQ、RocketMQ 等。选择消息队列通常取决于需求：

• RabbitMQ：适合复杂的路由和消息确认机制。
• Kafka：擅长处理高吞吐量的数据流，适用于日志和流数据处理。
• RocketMQ：高性能、低延迟，且支持事务消息，适合金融等场景。

3. 为什么你一定要用消息队列？不用行不行？不用有什么缺点？

消息队列的使用并不是必需的，但它能显著改善系统的性能、可用性和扩展性。
不用消息队列会导致：

• 耦合度高：服务之间紧密耦合，单个服务的变化会影响整个系统。
• 性能受限：系统无法削峰，短时间内大量请求会压垮服务。
• 扩展困难：无法轻松地增加或减少系统模块。

4. 在对接多个下游的时候，直接用 RPC 调用行不行？为什么？

直接用 RPC 调用多个下游服务可以实现，但会引入以下问题：

• 并发压力大：多服务依赖会增加系统复杂度。
• 性能受限：如果下游服务响应慢，会导致整体调用时间变长。
• 失败影响大：下游任一服务不可用，都会影响整体流程。

消息队列可以将调用解耦，各个下游服务根据自己的处理能力消费消息，从而减少影响。

5. 为什么说使用消息队列可以提高性能？

消息队列提供异步处理，避免主服务等待耗时的操作，且通过异步削峰填谷处理高并发请求，从而提高整体系统性能。

6. 为什么说使用消息队列可以提高扩展性？

消息队列允许各个系统模块独立扩展，而不需要改变其他模块的实现。比如，增加新的消费者或调整消费者数量，可以应对不断变化的业务需求。

7. 为什么说使用消息队列可以提高可用性？

使用消息队列，即使下游服务短时间内不可用，消息依然可以被保存在队列中。当下游服务恢复时，消息可以被继续消费，确保数据不丢失，提高系统的可靠性。

8. 为什么秒杀场景中经常用消息队列？怎么用的？

在秒杀场景中，消息队列用于削峰填谷。用户的秒杀请求进入消息队列，按顺序排队处理，从而避免流量高峰直接冲击数据库和业务服务，防止系统崩溃。可以设置消费者按一定速度读取消息来进行库存判断和订单创建。

9. 订单超时取消可以怎么实现？

可以使用延迟消息队列来实现订单超时取消。例如，当订单创建后，消息队列中的延迟消息在一段时间后触发检查，如果订单仍未支付，则自动取消订单。

10. 你了解事件驱动吗？

事件驱动是一种异步编程模式，事件发生时触发处理。消息队列是事件驱动的重要组成，可以在不同服务间传递事件，实现解耦和异步处理。

11. 什么是 SAGA 事务？怎么利用事件驱动来设计一个 SAGA 事务框架？

SAGA 事务是一种分布式事务管理模式，分为一系列的子事务，每个子事务要么成功要么补偿。
设计 SAGA 事务框架：可以使用事件驱动的方式，每个子事务完成时，通过消息队列通知下一个事务开始执行。如某子事务失败，发布回滚事件，按逆序触发补偿操作。这样，确保在分布式环境中保持数据一致性。

23｜延迟消息：怎么在 Kafka 上支持延迟消息？

1. 什么是延迟消息？你有没有用过？可以用来解决什么问题？
2. Kafka 支不支持延迟消息？为什么 Kafka 不支持？
3. RabbitMQ 支不支持延迟消息？怎么支持的？
4. RabbitMQ 的延迟消息解决方案有什么缺点？让你来改进，你会怎么办？
5. 什么是死信队列？什么是消息 ttl？
6. 如果要让 Kafka 支持延迟消息你会怎么做？你有几种方案？各有什么优缺点？
7. 在你的延迟消息队列方案里面，时间有多精确？比如说我希望在 10:00:00 发出来，你能保证这个一定恰好在这个时刻发出来吗？误差有多大？你能进一步提高时间精确性吗？
8. 在分区设置不同延迟时间的方案里，能不能支持随机延迟时间？
9. 在分区设置不同延迟时间的方案里，如果要是发生了 rebalance，会有什么后果？
10. 当你从准备转发消息到业务 topic（biz_topic）的时候失败了，有什么后果？怎么办？
11. 在你使用 MySQL 支持延迟消息的方案里，你怎么解决性能问题？
12. 如果要分库分表来解决 MYSQL 的性能问题，你会怎么分库分表？是分库还是分表？
13. 如果要是不同业务 topic 的并发量有区别，你分库分表怎么解决这种负载不均匀的问题？
14. 如果延迟消息还要求有序性，该怎么办？
15. 如果你已经将消息转发到了 biz_topic 上，但是更新数据库状态失败了怎么办？
16. 除了用 MySQL，可以考虑用别的中间件来实现延迟消息吗？

1. 什么是延迟消息？你有没有用过？可以用来解决什么问题？

延迟消息是一种在特定延迟时间后再发送给消费者的消息。常见的应用场景有订单超时取消、定时提醒、延迟执行任务等。

2. Kafka 支不支持延迟消息？为什么 Kafka 不支持？

Kafka 不原生支持延迟消息，因为 Kafka 的设计目标是高吞吐量和低延迟，为了保持性能，它采取的是顺序投递和即时处理的消息消费模型。

3. RabbitMQ 支不支持延迟消息？怎么支持的？

RabbitMQ 支持延迟消息，通过TTL（消息的生存时间）和死信队列实现。在消息的 TTL 到期后，未消费的消息会进入死信队列，在死信队列中可以设置为延迟消息投递给指定的消费者。

4. RabbitMQ 的延迟消息解决方案有什么缺点？让你来改进，你会怎么办？

RabbitMQ 的 TTL + 死信队列方式有以下缺点：

• 资源占用高：过多的延迟消息会占用内存。
• 缺乏精确性：每个消息的精确延迟控制不够。

改进方案可以是利用定时任务检查并消费到期消息，或者增加一个控制消息投递时间的插件，如 RabbitMQ Delayed Message Plugin。

5. 什么是死信队列？什么是消息 TTL？

• 死信队列：消息在原队列因超时、被拒绝或超出重试次数等情况转发到的特殊队列。
• 消息 TTL：消息的存活时间，到达 TTL 后，未被消费的消息将被移至死信队列或丢弃。

6. 如果要让 Kafka 支持延迟消息你会怎么做？你有几种方案？各有什么优缺点？

在 Kafka 中实现延迟消息，可以考虑以下几种方案：

方法一：分区延迟

在多个分区中设置不同的延迟等级，消费端控制不同分区的消息投递时间。

• 优点：简单实现。
• 缺点：延迟精度有限，不适合需要精确延迟的场景。

方法二：延迟轮询

消费者定期轮询，过滤超过设定延迟时间的消息进行消费。

• 优点：延迟控制较精确。
• 缺点：高频轮询可能影响性能。

方法三：借助 Redis/Zookeeper 等存储

将需要延迟的消息存入 Redis，记录到期时间，利用定时任务检查并投递。

• 优点：适合高精度控制。
• 缺点：实现复杂，增加了外部依赖。

7. 在你的延迟消息队列方案里面，时间有多精确？比如说我希望在 10:00:00 发出来，你能保证这个一定恰好在这个时刻发出来吗？误差有多大？你能进一步提高时间精确性吗？

延迟消息的精确度取决于轮询频率。一般来说，误差在秒级别，如果需要更高精度，可以通过增加轮询频率、调优消费间隔来控制。

8. 在分区设置不同延迟时间的方案里，能不能支持随机延迟时间？

无法支持完全的随机延迟时间。分区延迟方案的延迟是按固定时间段分配的，随机延迟可以考虑在每个分区基础上调整消费时间，但精度有限。

9. 在分区设置不同延迟时间的方案里，如果要是发生了 rebalance，会有什么后果？

发生 rebalance 时，消息分配将重新调整，可能导致消息的延迟被打乱、重复消费或不按时消费的情况。

10. 当你从准备转发消息到业务 topic（biz_topic）的时候失败了，有什么后果？怎么办？

如果失败，消息将丢失。可以通过幂等机制和重试策略来保证消息转发的可靠性。也可以利用事务机制，确保消息的转发成功后才提交。

11. 在你使用 MySQL 支持延迟消息的方案里，你怎么解决性能问题？

MySQL 中可以使用分片或分表的方式减少表中的数据量，降低单次查询压力，并定期删除已消费的历史记录。索引优化也有助于提高查询效率。

12. 如果要分库分表来解决 MySQL 的性能问题，你会怎么分库分表？是分库还是分表？

可采用分表方式，将延迟任务数据按时间分片，比如按天、小时等分片。对高并发的场景，还可以进行分库处理。

13. 如果要是不同业务 topic 的并发量有区别，你分库分表怎么解决这种负载不均匀的问题？

可以根据不同业务类型分表，合理分配各表的读写比例，保证分库分表后负载均衡。还可以通过动态扩容方式适应不同业务负载。

14. 如果延迟消息还要求有序性，该怎么办？

可采用单一分区实现顺序消费，或者通过队列优先级控制消息消费顺序，确保延迟消息按序处理。

15. 如果你已经将消息转发到了 biz_topic 上，但是更新数据库状态失败了怎么办？

可以使用重试机制，在更新失败后，重新更新状态表。若多次失败，可以进入死信队列，通过人工或补偿任务处理。

16. 除了用 MySQL，可以考虑用别的中间件来实现延迟消息吗？

可以考虑使用 Redis、RabbitMQ 等。Redis 的有序集合（zset）可以控制到期时间，RabbitMQ 的 TTL 和死信队列也可以实现延迟消息。

24｜消息积压：业务突然增长，导致消息消费不过来怎么办？

1. 一个分区可以有多个消费者吗？一个消费者可以消费多个分区吗？
2. 你业务里面的消息有多少个分区？你怎么计算出来的？它能撑住多大的读写压力？
3. 你遇到过消息积压吗？怎么发现的？为什么会积压？最后怎么解决的？
4. 为什么会出现消息积压？只要我容量规划好，肯定不会有消息积压，对不对？
5. 消息积压可以考虑怎么解决？
6. 增加消费者数量能不能解决消息积压问题？
7. 能不能通过限制发送者，让他们少发一点来解决消息积压问题？
8. 现在我发现分区数量不够了，但是运维又不准我增加新的分区，该怎么办？
9. 异步消费有什么缺陷？
10. 你怎么解决异步消费的消息丢失问题？你的方案会引起重复消费吗？
11. 在异步消费一批消息的时候，要是有部分消费失败了，怎么办？要不要提交？

1. 一个分区可以有多个消费者吗？一个消费者可以消费多个