面试系列之-rocketmq组件及关系
组件
broker
理解成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;
nameserver
理解成zookeeper的效果,只是他没用zk,而是自己写了个nameserver来替代zk;底层由netty实现,提供了路由管理、服务注册、服务发现的功能,是一个无状态节点;nameserver是服务发现者,集群中各个角色(producer、broker、consumer等)都需要定时向nameserver上报自己的状态,以便互相发现彼此,超时不上报的话,nameserver会把它从列表中剔除;nameserver可以部署多个,当多个nameserver存在的时候,其他角色同时向他们上报信息,以保证高可用,;NameServer集群间互不通信,没有主备的概念;nameserver内存式存储,nameserver中的broker、topic等信息默认不会持久化,所以他是无状态节点;
NameServer路由注册、删除机制
- Broker每30秒向NameServer发送心跳包,心跳包中包含topic的路由信息;
- NarneServer收到Broker心跳包后,更新brokerLiveTable中的信息, 特别记录心跳时间lastUpdateTime;
- NarneServer每隔10s扫描brokerLiveTable, 检 测表中上次收到心跳包的时间,比较当前时间与上一次时间,如果超过120s,则认为broker不可用,移除路由表中与该broker相关的所有信息;
- 消息生产者拉取主题的路由信息,即消息生产者并不会立即感知Broker服务器的新增与删除;
producer
消息的生产者随机选择其中一个NameServer节点建立长连接,获得Topic路由信息(包括topic下的queue,这些queue分布在哪些broker上等等);接下来向提供topic服务的master建立长连接(因为rocketmq只有master才能写消息),且定时向master发送心跳;
Producer Group
- 标识一类Producer;
- 可以通过运维工具查询返个収送消息应用下有多个Producer实例;
- 发送分布式事务消息时,如果Producer中途意外宕机,Broker会主动回调Producer Group内的任意一台机器来确认事务状态;
consumer
消息的消费者通过NameServer集群获得Topic的路由信息,连接到对应的Broker上消费消息;由于Master和Slave都可以读取消息,因此Consumer会与Master和Slave都建立连接进行消费消息;
Consumer Group
一个Consumer Group下的多个Consumer以均摊方式消费消息,如果设置为广播方式,那么这个Consumer Group下的每个实例都消费全量数据;
组件交互的核心流程
- Broker都注册到Nameserver上;
- Producer发消息的时候会从Nameserver上获取发消息的topic信息;
- Producer向提供服务的所有master建立长连接,且定时向master发送心跳;
- Consumer通过NameServer集群获得Topic的路由信息;
- Consumer会与所有的Master和所有的Slave都建立连接进行监听新消息;
核心概念
queue
每个主题可设置队列个数,自动创建主题时默认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个,这个会不工作;
tag
Topic的进一步细分标,每个发送的时候消息都能打tag,消费的时候可以根据tag进行过滤,选择性消费;
消费模式
集群模式(Clustering)
- 每条消息只需要被处理一次,broker只会把消息发送给消费集群中的一个消费者;
- 在消息重投时,不能保证路由到同一台机器上;
- 消费状态由broker维护;
一个Consumer Group中的Consumer实例平均分摊消费消息;例如某个Topic有 9 条消息,其中一个Consumer Group有3个实例(可能是3个进程,或者3台机器),那举每个实例只消费其中的3消息;
广播模式(Broadcasting)
- 消费进度由consumer维护;
- 保证每个消费者都消费一次消息;
- 消费失败的消息不会重投;
一条消息被多个Consumer消费,即使返些Consumer属亍同一个Consumer Group,消息也会被 Consumer Group中的每个Consumer都消费一次,广播消费中的Consumer Group概念可以讣为在消息划分方面无意义;
顺序消息
消费消息的顺序要同収送消息的顺序一致,在RocketMQ中,主要指的是头部顺序,即一类消息为满足顺序性,必须Producer单线程顺序发送,且发送到同一个队列,这样Consumer就可以按照Producer发送的顺序去消费消息;
普通顺序消息
顺序消息的一种,正常情况下可以保证完全的顺序消息,但是一旦发生通信异常,Broker重启,由于队列总数发生发化,哈希取模后定位的队列会发化,产生短暂的消息顺序不一致;如果业务能容忍在集群异常情况(如某个Broker宕机或者重启)下,消息短暂的乱序,使用普通顺序方式比较合适;
严格顺序消息
顺序消息的一种,无论正常异常情况都能保证顺序,但是牺牲了分布式Failover特性,即Broker集群中只要有一台机器不可用,则整个集群都不可用,服务可用性大大降低;如果服务器部署为同步双写模式,此缺陷可通过备机自切切换为主避免,不过仍然会存在几分钟的服务不可用。(依赖同步双写,主备自动切换,自动切换功能目前还未实现)目前已知的应用只有数据库binlog同步强依赖严格顺序消息,其他应用绝大部分都可以容忍短暂乱序,推荐使用普通的顺序消息;
相关文章
- [宝塔面板] 客服系统适配宝塔面板,实现软件商店=>导入项目=>一键部署私有云在线客服系统
- 从内存管理原理,窥探OS内存管理机制
- 基于多源数据画像的失败用例智能分析
- 快来一起玩转LiteOS组件:RHas
- 谁说count(*) 性能最差,我需要跟你聊聊
- Hive UDF,就这
- 5步带你掌握工作流Activiti框架的使用
- 带你认识FusionInsight Flink:既能批处理,又能流处理
- 物联网平台分为几层,你了解吗
- 没想到,学棋五年的我竟然输给了昇腾CANN!
- 译文丨伯克利对serverless的看法:简化云编程
- 据说有人面试栽在了Thread类的stop()方法和interrupt()方法上
- 湖仓一体天花板,大数据一站式SQL分析技术实践
- 一键抠除路人甲,昇腾CANN带你识破神秘的“AI消除术”
- VRAR产业峰会暨第二届华为VR开发应用大赛颁奖典礼在和平区成功举办!
- 带你认识传统语音识别技术
- 基于机器学习和TFIDF的情感分类算法,详解自然语言处理
- 一图解析MySQL执行查询全流程
- 带你认识7种云化测试武器
- Hive on Spark和Spark sql on Hive,你能分的清楚么