rabbitmq实现rpc模式的核心是通过回调队列（replyto）和关联标识（correlationid）模拟同步语义，客户端声明回调队列、设置消息属性并发送请求，服务端处理后按replyto和correlationid返回响应，客户端依correlationid匹配并配合超时机制确保可靠性。
RabbitMQ 实现 RPC 模式，核心是用消息队列模拟“请求-响应”同步语义，本质仍是异步通信，但通过两个关键机制让客户端能准确收回应答：回调队列（replyTo）和关联标识（correlationId）。它不依赖网络直连，也不需要服务端暴露 HTTP 接口，适合解耦、可靠、可伸缩的跨服务调用。
客户端要发带标记的请求
客户端不直接等待服务端返回，而是：
- 先声明一个临时或独占的回调队列（例如
amq.gen-xxxx），用于接收响应 - 构造请求消息时，在 BasicProperties 中设置：
- replyTo：填回调队列名，告诉服务端“结果请发到这里”
- correlationId：生成唯一字符串（如 UUID），标记本次请求身份
-
contentType：建议设为
application/json，便于序列化 - deliveryMode=2（可选）：确保请求消息持久化，避免服务端宕机丢请求
- 把消息发到预定义的请求队列（如
rpc_queue），然后在回调队列上阻塞或异步监听
服务端按需处理并原路返回
服务端持续监听请求队列，收到消息后：
- 解析业务参数（比如从 JSON body 提取数字计算斐波那契）
- 读取消息的 replyTo 和 correlationId 字段
- 将处理结果封装成新消息，使用相同的 correlationId，发送到 replyTo 指定的队列
- 建议设置 deliveryMode=2 和 contentType，保持响应一致性
客户端靠 correlationId 匹配响应
客户端从回调队列收到消息后，不是无条件接受，而是：
- 检查消息的 correlationId 是否与自己发出请求时设置的一致
- 一致则视为有效响应，返回给上层逻辑；不一致则忽略（可能是超时重发或其它请求的残留）
- 配合超时机制（如 Java 的
queueingConsumer.nextDelivery(timeout)或 Python 的await queue.get(timeout=...)），防止无限等待
注意事项与常见优化
实际落地时要注意几个易错点：
- 不要为每次请求都新建回调队列——效率低、资源浪费；推荐每个客户端复用一个独占队列
- correlationId 必须全局唯一且可追溯，建议用 UUID 或带时间戳的字符串，避免碰撞
- 服务端应做幂等处理，因为客户端可能因超时重发相同请求（相同 correlationId）
- 生产环境需配置死信队列（DLX）+ TTL，自动清理长期未消费的响应消息
- 若用 Spring AMQP，可借助
SimpleRpcServer和AmqpTemplate.convertSendAndReceive简化模板代码
