本文最后更新于 2 分钟前，文中所描述的信息可能已发生改变。
常见问题
MQ 的应用场景
- 削峰填谷：应用于高并发场景，对异步消息处理，削减瞬时流量压力，在低流量时，对积压消息进行处理，提高资源利用率；
- 系统解耦：基于发布/订阅模式，实现业务模块间的松耦合，提高系统扩展性与可维护性；
- 异步处理：适用于不需要立即返回结果的任务，提升接口响应速度与用户体验；
- 消息可靠性保障：通过持久化、确认机制、重试策略、防重复消费（幂等处理）等手段，确保消息不丢失、不乱序、不重复。
MQ 解耦和微服务解耦的区别？
- MQ 解耦主要针对消息层面，通过消息异步处理降低系统的直接依赖，适用于削峰填谷、事件驱动和异步处理场景；
- 微服务解耦主要针对架构层面，强调业务服务的边界清晰、独立部署和独立扩展；
- 微服务往往需要用过 MQ 进一步降低服务间的同步依赖。
| 对比维度 | MQ 解耦 | 微服务解耦 |
|---|---|---|
| 解耦对象 | 模块间的消息交互 | 服务之间的业务逻辑和功能 |
| 粒度 | 消息级别的解耦 | 系统架构级别的解耦 |
| 实现方式 | 借助 消息队列，通过异步消息传递将发送者和接收者解耦 | 借助 服务注册发现、API 网关、RPC 或 REST 接口等机制拆分和独立部署服务 |
| 同步/异步 | 以 异步交互 为主 | 以 同步调用 为主，也支持异步调用 |
| 适用场景 | 高并发削峰、事件驱动、异步处理 | 大型系统的模块拆分、职责边界清晰化、独立扩展和维护 |
| 耦合度变化 | 发送方只需关心消息格式，接收方变化对发送方无影响 | 服务之间通过接口契约绑定，接口变化可能需要协同调整 |
| 典型问题 | 消息可靠性、顺序性、重复消费、延迟处理 | 服务治理、接口版本兼容性、网络延迟、分布式事务 |
| 优势 | 异步高性能，系统更具弹性 | 架构清晰，便于独立扩展、部署和测试 |
| 限制 | 不适合同步强一致性需求 | 如果没有 MQ 结合，某些场景下无法应对流量激增或异步需求 |
发生消息堆积怎么处理
从生产端、消费端、队列本身入手， 消费端增加消费者， 生产端做一个回调缓冲（如果太多减少消息生产）， 队列进行消息压缩（我具体是说很多消息的 id 等属性重复在业务上可以接受压缩成一条）
- MQ 的消息怎么保证不丢失
RocketMQ
- RocketMQ 的延迟队列是怎么实现的？