rocketMQ的架构原理和读写逻辑

NameServer:无状态节点，集群部署，节点之间无任何信息同步，支持横向拓展；

producer & consumer也是无状态的，每一个producer之间 ，每一个consumer之间都不会通信， 每个producer和consumer内部都有自己的一套负载均衡的算法 ，默认的选择策略： 已发送的消息数量对queuecount取mod .

1、启动NameServer，NameServer起来后监听端口，等待Broker、Producer、 Consumer连上来，相当于一个路由控制中心。
2、Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。【当broker服务启动后，会向namesrv注册信息，比如broker中的 主题、消费偏移量、队列、ip、端口等，由broker的心跳发送到namesrv。broker cluster中的每一个节点都会注册到namesrv上；】broker消息存储涉及3个重要的存储文件，分别是CommitLog、ConsumeQueue、IndexFile； 
CommitLog：消息存储的主体，存入不同的topic消息，是磁盘顺序写进的，当消息消费后，72小时 后会被delete；
ConsumeQueue：消息消费队列，引入的目的主要是提高消息消费的性能，ConsumeQueue（逻辑消费队列）作为消费消息的索引，保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值。consumequeue文件可以看成是基于topic的commitlog索引文件
IndexFile（索引文件）提供了一种可以通过key或时间区间来查询消息的方法，类似hashmap，另外查询方式msgid：MessageId的长度总共有16字节，其中包含了消息存储主机地址（IP地址和端口），消息Commit Log offset

3、收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
4、Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
5、Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息