RocketMQ整体结构
Broker
Broker是RocketMQ的核心,提供了消息的接收,存储,拉取等功能,一般都需要保证Broker的高可用,所以会配置Broker Slave,当Master挂掉之后,consumer然后消费Slave;
broker面向producer和consumer接收和发送消息
向nameserver提交自己的信息
是消息中间件的消息存储、转发服务器。
每个broker节点,在启动时,都会遍历nameserver列表,与每个nameserver建立长连接,注册自己的信息,之后定时上报。
Broker集群
Broker高可用,可以配成Master和Slave,Master可写可读,Slave只可以读,Master将写入的数据同步给Slave。
1、一个Master可以对应多个Slave,但是一个Slave只能对应一个Master
2、Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义BrokerId为0表示Master,非0表示Slave。
Master多机负载,可以部署多个broker,每个Broker与nameserver集群中的所有节点建立长连接,定时注册Topic信息到所有nameserver。
Producer
消息的生产者,通过集群中的其中一个节点(随机选择)与NameServer建立长连接,获得Topic的路由信息,包括Topic下面有哪些Queue,这些Queue分布在哪些Broker上,并向提供Topic服务的Broker Master,Slave建立连接。
Consumer
消息的消费者,通过NameServer集群获得Topic的路由信息,连接到对应的Broker上消费消息,并向提供Topic服务的Broker Master,Slave建立连接;
NameServer
可以理解为消息队列的协调者,底层由netty实现,提供了路由管理、注册服务、服务发现的功能,是一个无状态节点,并且多个NameServer直接并没有通信,可以横向扩展多台,Broker会和每一台NameServer建立长连接。Broker向它注册路由信息,同时Client向其获取路由信息。
nameserver是服务发现者,集群中各个角色(producer,broker、consumer等)都需要定时向nameserver上报自己的状态,以便互相发现彼此,超时不上报的话,nameserver会把它从列表中剔除。
nameserver可以部署多个,当多个nameserver存在的时候,其他角色同时向他们上报信息,以保证高可用。
nameserver集群间互不通信,没有主备的概念
nameserver内存式存储,nameserver中的broker、topic等信息默认不会持久化。
为什么不用zookeeper?:rocketmq希望为了提高性能,CAP定理,用户端的负载均衡。
Topic和Message Queue
topic,用来区分不同类型的消息,发送和接收消息前都需要先创建topic,针对topic来发送和接收消息,为了提高性能和吞吐量,引入message queue,一个topic可以设置一个或多个message queue,有点类似kafka的分区(partition),这样消息就可以并行往各个message queue发送消息,消费者也可以并行的从多个message queue读取消息。