理解成rocketmq本身,broker主要用于producer和consumer接收和发送消息;broker会定时向nameserver提交自己的信息;是消息中间件的消息存储、转发服务器;每个Broker节点,在启动时,都会遍历NameServer列表,与每个NameServer建立长连接,注册自己的信息,之后定时上报;
broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave;Master也可以部署多个,每个Broker与Name Server集群中的所有节点建立长连接,定时注册Topic信息到所有Name Server;
理解成zookeeper的效果,只是他没用zk,而是自己写了个nameserver来替代zk;底层由netty实现,提供了路由管理、服务注册、服务发现的功能,是一个无状态节点;nameserver是服务发现者,集群中各个角色(producer、broker、consumer等)都需要定时向nameserver上报自己的状态,以便互相发现彼此,超时不上报的话,nameserver会把它从列表中剔除;nameserver可以部署多个,当多个nameserver存在的时候,其他角色同时向他们上报信息,以保证高可用,;NameServer集群间互不通信,没有主备的概念;nameserver内存式存储,nameserver中的broker、topic等信息默认不会持久化,所以他是无状态节点;
消息的生产者随机选择其中一个NameServer节点建立长连接,获得Topic路由信息(包括topic下的queue,这些queue分布在哪些broker上等等);接下来向提供topic服务的master建立长连接(因为rocketmq只有master才能写消息),且定时向master发送心跳;
消息的消费者通过NameServer集群获得Topic的路由信息,连接到对应的Broker上消费消息;由于Master和Slave都可以读取消息,因此Consumer会与Master和Slave都建立连接进行消费消息;
一个Consumer Group下的多个Consumer以均摊方式消费消息,如果设置为广播方式,那么这个Consumer Group下的每个实例都消费全量数据;
每个主题可设置队列个数,自动创建主题时默认4个,需要顺序消费的消息发往同一队列,队列会平均分散在多个Broker上,Producer的发送机制保证消息尽量平均分布到所有队列中,最终效果就是所有消息都平均落在每个Broker上队列可以动态伸缩,扩大该topic的队列数;
1个Topic会被分为N个Queue,数量是可配置的;message本身其实是存储到queue上的,消费者消费的也是queue上的消息;比如1个topic4个queue,有5个Consumer都在消费这个topic,那么会有一个consumer浪费掉了,因为负载均衡策略,每个consumer消费1个queue,5>4,溢出1个,这个会不工作;
Topic的进一步细分标,每个发送的时候消息都能打tag,消费的时候可以根据tag进行过滤,选择性消费;
一个Consumer Group中的Consumer实例平均分摊消费消息;例如某个Topic有 9 条消息,其中一个Consumer Group有3个实例(可能是3个进程,或者3台机器),那举每个实例只消费其中的3消息;
一条消息被多个Consumer消费,即使返些Consumer属亍同一个Consumer Group,消息也会被 Consumer Group中的每个Consumer都消费一次,广播消费中的Consumer Group概念可以讣为在消息划分方面无意义;
消费消息的顺序要同収送消息的顺序一致,在RocketMQ中,主要指的是头部顺序,即一类消息为满足顺序性,必须Producer单线程顺序发送,且发送到同一个队列,这样Consumer就可以按照Producer发送的顺序去消费消息;
顺序消息的一种,正常情况下可以保证完全的顺序消息,但是一旦发生通信异常,Broker重启,由于队列总数发生发化,哈希取模后定位的队列会发化,产生短暂的消息顺序不一致;如果业务能容忍在集群异常情况(如某个Broker宕机或者重启)下,消息短暂的乱序,使用普通顺序方式比较合适;
顺序消息的一种,无论正常异常情况都能保证顺序,但是牺牲了分布式Failover特性,即Broker集群中只要有一台机器不可用,则整个集群都不可用,服务可用性大大降低;如果服务器部署为同步双写模式,此缺陷可通过备机自切切换为主避免,不过仍然会存在几分钟的服务不可用。(依赖同步双写,主备自动切换,自动切换功能目前还未实现)目前已知的应用只有数据库binlog同步强依赖严格顺序消息,其他应用绝大部分都可以容忍短暂乱序,推荐使用普通的顺序消息;