本文共 1817 字,大约阅读时间需要 6 分钟。
rocketMq topic路由的注册,相当于dubbo来说 (实时模式),采用的是拉取模式
使用拉模式的缺点
消息发送的流程包括
Commitlog
消息存储文件:所有的主题消息随着到达Broker的顺序写入commitlog文件,每一个文件默认为一个G,文件使用该存储信息的第一个全局偏移量来命名文件,这样设计主要是为了方便根据消息偏移量快速定位到所在的物理位置,使用顺序写ConsumeQueue
消息消费队列文件,是Commitlog文件基于Topic的索引文件,主要用于消费者根据Topic消费消息,其组织方式为/topic/queue,同一个队列中存在多种文件,每一个条目使用固定长度(8字节commitlog物理偏移量,4字节消息长度,8字节tag hascode),主要存储hashcode,可以使用访问数组下标的方式快速定位indexFile
基于物理磁盘实现Hash索引,其文件由40字节的文件头,500w的哈希槽,每一个hash槽位4个字节,最后由2000万个index条目,每一个条目由20字节组成,基于文件的hash索引消息消费通常考虑消息队列负载,消费模式,消息过滤,消息消费,拉取机制,消息进度反馈,消息消费限流等方面
消息队列负载
集群内的消费者共同承担主题下面的所有消息的消费,即一条消息只能被集群中的一个消费者消费。其队列负载原则是一个消费者可以承担同一个主题下的多个消息消费队列,但是同一个消息消费队列同一时间只允许被分配给一个消费者 消息消费模式 集群消费和广播消费 消息拉取模式 推,拉,本质为拉 消息消费 顺序消息,并发消息,每一个消费者使用独立的线程池来拉取消费端的限流主要包括两个维度
主要为了保护消费者不会因为内存溢出而溢出, 例如调用消息服务没有超时时间可能会导致消息堆积
消息堆积数量
消息超过1000条会触发流控,具体做法是放弃本次拉取,延迟50ms后将该任务放进pullRequestQueue,会打应消费端日志 消息堆积大小 超过10M触发并发拉取和消费的核心
pullMessageService线程和RebalanceService线程的交互 每一个消费组一个线程池,用来异步处理消息 消费进度反馈读写分离,不提供主从切换
消费流程
主从服务器在运行过程中,消费者一般从主服务器拉取,当主服务器积压的消息超过物理内存的40%,建议从从服务器拉取
当消息消费者向服务器拉取消息之后有一下情况
转载地址:http://ynkgn.baihongyu.com/