在用户空间创建好epoll对象后，就会向其注册socket，并设置好感兴趣的事件。这个步骤是epoll的核心，是后续调用的epoll_wait打下基础。在该系统调用中会为socket设置回调函数，这样事件就绪时会自动修改epoll中的事件列表，而不用用户进程的介入，这也是为什么epoll很高效的原因。
在Linux中，不管是在服务端，还是在客户端，都会通过调用recv或recvfrom系统调用来获取对方发送来的数据，如果有数据，那么就读取并交给用户线程来处理，但如果没有数据线程则会阻塞。本文就来分析一下recv系统调用的执行过程。
epoll_wait是epoll的核心，用来获取注册到该epoll上的就绪事件。在Linux中的recv系统调用一文中分析了传统的阻塞IO是怎么进行阻塞和唤醒的，而epoll_wait也是可以限时阻塞的，那通过本文的分析可以对比一下两者的执行过程有什么区别。
NettyRemotingServer是RocketMQ中Netty服务器的实现，封装了与Netty相关的组件。如服务端启动器、事件循环组、通道处理器及其执行器组。Nameserver和broker都会依赖该组件来实现网络通信和事件处理。本文就来分析一下该组件的实现原理。
在RocketMQ中，nameserver会负责管理broker和消息主题。本文会分析RocketMQ中nameserver的创建和启动过程。
在RocketMQ中，broker提供消息存储服务。生产者生成消息和消费者消费消息都要与broker进行交互。本文先来分析一下broker的创建和启动过程。
在前面介绍创建过程时，讲到会创建Netty客户端、以及一些其他服务。那么在启动过程中，就要启动该客户端和这些服务，包括消息拉取、再均衡、消息推送服务；除此以外，还要启动一些定时任务，比如发送心跳给broker。本文就来分析一下具体的实现过程。
MQClientInstance是RocketMQ中客户端实现，生产者和消费者都要依靠它。它内部封装了Netty客户端，实现了nameserver和broker交互的底层细节，为上层应用提供了统一的接口。本文就来分析一下该客户端的创建过程。
在RocketMQ中，支持两种消息消费模式，即PULL（拉模式）和PUSH（推模式），PUSH模式的效果类似broker将消息推送到消费者客户端，不过这是一种伪推送，是基于对PULL模式的封装来实现的。本文先来梳理一下消费者的创建和启动过程，从而能够更好理解消息的拉取过程。