1、启动NameServer,NameServer启动后开始监听端口，等待broker，producer，consumer连接
2、启动broker时，broker会和所有的NameServer建立并保持长链接，然后每隔30s向NameServer定时发送心跳包
3、发送消息前，可以先创建Topic，创建Topic时需要指定该topic要存储在哪些broker上，同时也会将topic和broker的关系写入到NameServer，不过这步并不是必需的，也可以在发送消息时自动创建topic
手动创建Topic有两种模式：
1）集群模式：该模式下创建的Topic在该集群中，所有Broker的Queue数量是相同的。
2）Broker模式：该模式下创建的Topic在该集群中，每个Broker的Queue数量可以不同。
自动创建Topic时，默认采用Broker模式，会为每个Broker默认创建4个Queue
4、producer发送消息，启动时与NameServer集群中的其中一台建立长链接，并从NameServer中获取路由信息，即当前发送的Topic和Queue与Broker的地址(IP+Port)的映射关系。然后根据算法策略从队列选择一个Queue，与队列所在的broker建立长链接从而向broker发送消息。在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每隔30s从NameServer更新一个路由信息。
5、Consumer和Producer类似。和其中一个NameServer建立长链接，获取其所订阅的Topic信息，然后根据算法策略从路由信息中获取到所要消费的Queue，然后和broker建立长链接，开始消费其中的消息。Consumer在获取到路由信息后，也会每隔30s从NameServer更新一次路由信息，不过和Producer不同的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态。
读/写队列：从物理上来讲，读和写是同一个队列，不存在读写队列的数据同步问题，读/写队列是逻辑上进行区分的概念。一般情况下，读/写队列数量是相同的。也有特殊情况：
例如：创建Topic时设置的写队列数量为8，读队列数量为4，则会创建8个队列，分别是0~7，Producer会将消息写入到8个队列中，而Consumer只会消费0~3队列中的消息，剩下的消息是不会被消费的。
再如：创建Topic时设置的写队列数量为4，读队列数量为8，则会创建8个队列，分别是0~7，Producer会将消息写入到4个队列中，而Consumer会消费0~7队列中的消息，但因为4~7是没有消息的，则若Consumer Groups中有两个Consumer，其中一个是没有消息可消费的。
这样设计的目的是为了方便Queue的缩容
例如：原来创建的Topic有16个Queue，如何能使Queue缩容为8个，而且不丢失信息？
答：可以动态修改队列数量为8.首先读队列的数量不变，此时新的消息只能写入前八个队列，而消费的仍然是16个队列中的数据。当发现8个Queue中的数据都消费完成后，再修改读队列的数量为8.