RocketMQ-RocketMQ高性能核心原理与源码剖析（中）

二.小试牛刀阶段

​ 开始理解一些比较简单的业务逻辑

3、Netty服务注册框架

1、关注重点

​ 网络通信服务是构建分布式应用的基础，也是我们去理解RocketMQ底层业务的基础。这里就重点梳理RocketMQ的这个服务注册框架，理解各个业务进程之间是如何进行RPC远程通信的。

​ Netty的所有远程通信功能都由remoting模块实现。RemotingServer模块里包含了RPC的服务端RemotingServer以及客户端RemotingClient。在RocketMQ中，涉及到的远程服务非常多，在RocketMQ中，NameServer主要是RPC的服务端RemotingServer，Broker对于客户端来说，是RPC的服务端RemotingServer，而对于NameServer来说，又是RPC的客户端。各种Client是RPC的客户端RemotingClient。

​ 需要理解的是，RocketMQ基于Netty保持客户端与服务端的长连接Channel。只要Channel是稳定的，那么即可以从客户端发请求到服务端，同样服务端也可以发请求到客户端。例如在事务消息场景中，就需要Broker多次主动向Producer发送请求确认事务的状态。所以，RemotingServer和RemotingClient都需要注册自己的服务。

2、源码重点

​ 1、哪些组件需要Netty服务端？哪些组件需要Netty客户端？ 比较好理解的，NameServer需要NettyServer。客户端，Producer和Consuer，需要NettyClient。Broker需要NettyServer响应客户端请求，需要NettyClient向NameServer注册心跳。但是有个问题， 事务消息的Producer也需要响应Broker的事务状态回查，他需要NettyServer吗？

NameServer不需要NettyClient，这也验证了之前介绍的NameServer之间不需要进行数据同步的说法。

​ 2、所有的RPC请求数据都封账成RemotingCommand对象。而每个处理消息的服务逻辑，都会封装成一个NettyRequestProcessor对象。

​ 3、服务端和客户端都维护一个processorTable，这是个HashMap。key是服务码requestCode，value是对应的运行单元 Pair<NettyRequestProcessor,ExecutorService>类型，包含了处理Processor和执行线程的线程池。具体的Processor，由业务系统自行注册。Broker服务注册见，BrokerController.registerProcessor()，客户端的服务注册见MQClientAPIImpl。NameServer则会注册一个大的DefaultRequestProcessor，统一处理所有服务。

​ 4、请求类型分为REQUEST和RESPONSE。这是为了支持异步的RPC调用。NettyServer处理完请求后，可以先缓存到responseTable中，等NettyClient下次来获取，这样就不用阻塞Channel了，可以提升请求吞吐量。猜一猜Producer的同步请求的流程是什么样的？

​ 5、重点理解remoting包中是如何实现全流程异步化。

整体RPC框架流程如下图：

​ RocketMQ使用Netty框架提供了一套基于服务码的服务注册机制，让各种不同的组件都可以按照自己的需求，注册自己的服务方法。RocketMQ的这一套服务注册机制，是非常简洁使用的。在使用Netty进行其他相关应用开发时，都可以借鉴他的这一套服务注册机制。例如要开发一个大型的IM项目，要加减好友、发送文本，图片，甚至红包、维护群聊信息等等各种各样的请求，这些请求如何封装，就可以很好的参考这个框架。

3、关于RocketMQ的同步结果推送与异步结果推送

​ RocketMQ的RemotingServer服务端，会维护一个responseTable，这是一个线程同步的Map结构。 key为请求的ID，value是异步的消息结果。ConcurrentMap<Integer /* opaque */, ResponseFuture> 。

​ 处理同步请求(NettyRemotingAbstract#invokeSyncImpl)时，处理的结果会存入responseTable，通过ResponseFuture提供一定的服务端异步处理支持，提升服务端的吞吐量。 请求返回后，立即从responseTable中移除请求记录。

​ 实际上，同步也是通过异步实现的。

//org.apache.rocketmq.remoting.netty.ResponseFuture
 //发送消息后，通过countDownLatch阻塞当前线程，造成同步等待的效果。
    public RemotingCommand waitResponse(final long timeoutMillis) throws InterruptedException {
        this.countDownLatch.await(timeoutMillis, TimeUnit.MILLISECONDS);
        return this.responseCommand;
    }
 //等待异步获取到消息后，再通过countDownLatch释放当前线程。
    public void putResponse(final RemotingCommand responseCommand) {
        this.responseCommand = responseCommand;
        this.countDownLatch.countDown();
    }

​ 处理异步请求(NettyRemotingAbstract#invokeAsyncImpl)时，处理的结果依然会存入responsTable，等待客户端后续再来请求结果。但是他保存的依然是一个ResponseFuture，也就是在客户端请求结果时再去获取真正的结果。 另外，在RemotingServer启动时，会启动一个定时的线程任务，不断扫描responseTable，将其中过期的response清除掉。

//org.apache.rocketmq.remoting.netty.NettyRemotingServer
this.timer.schedule