这个特性是微众向开源社区提供的基于RocketMQ实现的同步调用的场景，属于远程调用的一个场景，对比诸如Doubbo, Feign等RPC远程调用功能。
1、为何会有request-reply这样的场景？
RocketMQ作为分布式消息中间件的核心能力应该是解耦，削峰等等的场景，同步调用无疑弱化了这些耀眼的能力，咋看起来有些‘不务正业’。但是，所有的产品的出现都有它的适用的场景以及必要，不会空穴来风。
-
从实践的角度而言，属于金融科技领域，不是相关从业者不做评论。
-
从产品设计的角度而言，相比较Doubbo这样的产品，它有何优势？
-
Doubbo远程调用的核心是上游服务->下游服务，属于及时响应类别，服务的重试不由业务方控制，但是调用链短。 -
request-reply核心上游服务投递消息后进入等待被通知的状态，下游服务拥有了消息队列的部分能力，比如消息重试。这些能力无疑让request-reply有了更多的灵活性以及想象空间，但是整个调用链路也更长了。其次有了Broker服务存储中心，整个调用过程的交互都被记录在案，天然支持了日志分析的能力。
-
这样比较太过于粗浅，但是不耽误我们以简单的方式去理解它们。二者都是极为优秀的工业级产品，都有各自无懈可击的优势。但是由于出现的背景不尽相同，即便相同的能力也是由不同的能力叠加而成，所以分析的时候不妨也以装箱拆箱的思路来分析不同的组件组合成的效果之间的差异性。
2、如何实现？
实现的思路其实不复杂。
image.png
几个核心点：
- 生产者投递到服务端是异步投递，投递后进入线程阻塞的状态
- 消费者消费成功后会投递消息到服务端，服务端再找到特定的客户端进行通知
- 生产者被唤醒（超时或者通知）
核心的类与方法：
DefaultMQProducerImpl#request()
RequestResponseFuture#waitResponseMessage()#putResponseMessage()
MessageUtil#createReplyMessage()
ReplyMessageProcessor#processReplyMessageRequest()
ClientRemotingProcessor#receiveReplyMessage()
网友评论