选rpc还是消息队列取决于是否需实时响应、下游是否动态可变、流量是否需缓冲及是否接受最终一致性；rpc适用于强依赖同步结果的场景，mq适用于解耦、削峰、异步和最终一致场景。
业务中选 RPC 还是消息队列，关键不在“技术先进”，而在“谁需要等结果、谁该知道谁、流量能不能扛住”。两者不是替代关系，而是分工明确的协作关系。
调用方必须立刻拿到结果时，用 RPC
比如用户提交订单后，系统要校验库存是否充足、优惠券是否有效、地址是否合规——这些判断必须同步返回错误码或成功标识，前端才能决定跳转页面还是弹窗提示。RPC 天然支持请求-响应模型，接口定义清晰，调用像本地方法一样直观。消息队列做不到这点：发完就不管，无法保证消费者已处理，更无法把“库存不足”这种具体错误原路返回给下单接口。
常见场景包括：
- 登录鉴权（需实时返回 token 或拒绝原因）
- 支付扣款（需确认资金冻结是否成功）
- 搜索查询（用户等着看结果，不能异步通知）
下游服务不固定、可能新增或下线时，用消息队列
比如订单创建成功后，要通知积分系统加积分、物流系统预生成运单、风控系统做反作弊扫描。未来还可能接入短信平台、推荐系统、BI 数据埋点。如果全用 RPC，每新增一个下游，下单服务就得改代码、加调用逻辑、处理超时和失败重试——耦合度高、发布风险大。而 MQ 只需让新服务订阅“order.created”这个 Topic，生产者完全无感。
优势体现在：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 上游不依赖下游存活（积分服务宕机，订单仍可创建）
- 新增消费者无需改动已有服务
- 天然支持一对多、广播、延迟/重试等扩展能力
瞬时流量远超下游处理能力时，必须用消息队列
秒杀场景下，1 秒涌入 5 万下单请求，但库存服务每秒只能处理 2000 次扣减。若全部走同步 RPC，大量请求会在网关或库存服务前堆积，引发雪崩。MQ 充当缓冲区：下单服务快速写入消息并返回“已受理”，库存服务按自身节奏消费，削峰填谷。RPC 没有存储层，压力会直接传导到 Provider，无法缓解突发流量。
这类场景还包括：
- 日志采集（海量日志先入队，再批量落库）
- 报表生成（触发后异步跑批，完成后邮件通知）
- 文件转码（上传后发消息，后台服务拉取处理）
需要最终一致性而非强一致时，优先消息队列
跨服务更新多个数据源（如订单表 + 库存表 + 用户余额表），用分布式事务成本高、性能差。更轻量的做法是：本地事务写订单表 + 写一条“待发送”的消息记录（本地消息表），再由定时任务或监听器将消息投递到 MQ；下游服务消费后更新各自数据。哪怕某次消费失败，也能靠重试保障最终一致。RPC 很难自然支撑这种“发出去、慢慢办、办完算数”的模式。
适用模式：
- 订单状态变更后更新 ES 搜索索引
- 用户注册后异步初始化默认配置
- 退款成功后异步通知财务系统对账
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
