在 Node.js 环境下，你会采用哪些消息队列（MQ）或相关库来构建分布式系统，并说明其关键原理与应用场景？
考察说明
考察对 Node.js 中分布式消息队列选型、实现原理及实践要点的理解。
回答思路
- 【回答框架 1】在 Node.js 中实现分布式系统，常用消息队列如 RabbitMQ、Kafka 或 Redis Pub/Sub，以及 Bull 等库。MQ 核心作用是通过异步解耦、削峰填谷和可靠传输支撑分布式协作。
- 【回答框架 2】RabbitMQ 基于 AMQP 协议，支持多种交换机类型与路由规则，适合复杂路由和事务性消息；Kafka 以高吞吐、持久化和分区消费见长，适合日志与流处理。选择依据是吞吐、延迟、顺序性、持久化与运维成本。
- 【回答框架 3】使用 Node.js 时，常用库如 amqplib（RabbitMQ 官方客户端）、kafkajs（Kafka 客户端）或 ioredis（Redis 客户端）。同时需关注连接管理、重连、消息确认与失败重试机制。
- 【回答框架 4】实际方案中需考虑消息幂等性，例如为消息生成唯一 ID 并在消费者端做去重；同时关注背压处理，避免消费者过载，必要时设置消费并发上限。
- 【回答框架 5】最终方案需结合业务场景平衡一致性、可用性与性能，并在压测中验证吞吐和延迟指标，而非直接套用默认配置。
- 【关键点 1】RabbitMQ 适合复杂路由，Kafka 适合高吞吐流处理。
- 【关键点 2】Node.js 常用 amqplib、kafkajs 等库，需管理连接与重连。
- 【关键点 3】消息消费需实现幂等与去重，避免重复处理。
- 【关键点 4】关注背压和消费并发控制，防止消费者过载。
- 【易错点 1】将 MQ 直接等同于消息可靠性，忽略网络分区与节点故障风险。
- 【易错点 2】未做消息去重，导致重复消费引发数据不一致。
- 【易错点 3】盲目使用默认配置，未根据延迟与吞吐目标调整参数。