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建立连接通道,开始消费消息