从本专栏开始，我将详细讲解分布式系统中常用的一种组件——消息中间件。目前工业环境常用的消息中间件主要有ActiveMQ、RabbitMQ、Kafka、RocketMQ。这四种消息中间件的优劣和使用场景，我会在专栏中进行对比，读者也可以先参照我的另一个专栏《分布式系统从理论到实战系列》对消息中间件的核心要点进行了解。

本章，我们来讲讲Broker是如何定时发送心跳到NameServer，让NameServer感知到Broker一直都存活着的。如果Broker一段时间内没有发送心跳到NameServer，那么NameServer是如何感知到Broker已经挂掉了呢？

对于Broker来说，注册流程的核心点就是基于底层的Netty API与NameServer建立Channel，然后发送注册请求；对于NameServer来说，也是基于内部的NettyServer服务器先接受请求，然后将请求转交给请求处理器组件处理，而请求处理器组件则是根据不同的请求类。

本章，我们详细讲解Broker的整个启动流程，在阅读Broker和Nameserver的源码过程中，我们一定要抓住开源框架运行的主体流程和核心组件，而不要陷入各种组件的细节里去。

在RocketMQ使用的时候，第一个步骤一定是先启动NameServer，那么我们就先来分析NameServer启动这块的源码。它最核心的就是基于Netty实现了一个网络服务器，然后监听默认的9876端口，这样就可以接收Broker和客户端的网络请求了。

本章，我们先来搭建RocketMQ的源码环境，因为RocketMQ源码本身是用Java编写的，所以整个过程还是比较简单的。

本章，我们就来看下如何通过RocketMQ来解决状态补偿问题。在RocketMQ中，有两种特殊类型的消息：定时消息和延时消息。

在RocketMQ中，提供了一种顺序消息类型。所谓顺序消息（FIFO 消息），是一种严格按照顺序来发布和消费的消息。顺序发布和顺序消费是指对于指定的一个Topic：生产者按照一定的先后顺序发布消息；消费者按照既定的先后顺序订阅消息，即先发布的消息一定会先被客户端接收到。

本章，我们来看下RocketMQ中的重复消费问题，并对RocketMQ重复投递消息的原理做了介绍，引出死信队列这一概念。

本章，我们将消息丢失的三类场景进行分析，并给出了一套消息零丢失的全链路解决方案，对RocketMQ中的事务消息机制原理进行详细讲解。