网站开发 职位描述,哪里有免费的网站模板下载,下载app免费下载软件,微信店铺怎么开核心概念
NameServer
nameserver是整个rocketmq的大脑#xff0c;是rocketmq的注册中心。broker在启动时向所有nameserver注册。生产者在发送消息之前先从 NameServer 获取 Broker 服务器地址列表(消费者一 样)#xff0c;然后根据负载均衡算法从列表中选择一台服务器进行消… 核心概念
NameServer
nameserver是整个rocketmq的大脑是rocketmq的注册中心。broker在启动时向所有nameserver注册。生产者在发送消息之前先从 NameServer 获取 Broker 服务器地址列表(消费者一 样)然后根据负载均衡算法从列表中选择一台服务器进行消息发送。NameServer 与每台 Broker 服务保持长连接并间隔 30S 检查 Broker 是否存活如果检测到 Broker 宕机则从路由注册表中将其移除。这样就可以实 现 RocketMQ 的高可用。类似kafka中zookeeper的作用
生产者
消费者
消息
字节数组
Broker
同kafka broker
整体运转
NameServer 先启动Broker 启动时向 NameServer 注册生产者在发送某个主题的消息之前先从 NamerServer 获取 Broker 服务器地址列表(有可能是集群)然后根据负载均衡算法从列表中选择一台 Broker 进行消息发送。NameServer 与每台 Broker 服务器保持长连接并间隔 30S 检测 Broker 是否存活如果检测到 Broker 宕机(使用心跳机制如果检测超过 120S)则从路由注册表中将其移除。消费者在订阅某个主题的消息之前从 NamerServer 获取 Broker 服务器地址列表(有可能是集群)但是消费者选择从 Broker 中订阅消息订阅 规则由 Broker 配置决定。 分组Group
生产者:标识发送同一类消息的 Producer通常发送逻辑一致。发送普通消息的时候仅标识使用并无特别用处。主要作用用于事务消息:
(事务消息中如果某条发送某条消息的 producer-A 宕机使得事务消息一直处于 PREPARED 状态并超时则 broker 会回查同一个 group 的其它 producer 确认这条消息应该 commit 还是 rollback)
消费者:标识一类 Consumer 的集合名称这类 Consumer 通常消费一类消息且消费逻辑一致。同一个 Consumer Group 下的各个实例将共同消费 topic 的消息起到负载均衡的作用。消费进度以 Consumer Group 为粒度管理不同 Consumer Group 之间消费进度彼此不受影响即消息 A 被 Consumer Group1 消费过也会再给 Consumer Group2 消费。 Topic主题
标识一类消息的逻辑名字消息的逻辑管理单位。无论消息生产还是消费都需要指定 Topic。区分消息的种类;一个发送者可以发送消息给一个或者多个 Topic;一个消息的接收者可以订阅一个或者多个 Topic 消息同Kafka topic 标签
RocketMQ支持再发送时给topic打tag同一个topic的消息虽然逻辑管理是一样的但消费topic1时如果你消费订阅的时候指定tagA那么tagB消息不会订阅
消息队列
同kafka partation简称 Queue 或 Q。消息物理管理单位。一个 Topic 将有若干个 Q。若一个 Topic 创建在不同的 Broker则不同的 broker 上都有若干 Q消息将物理地 存储落在不同 Broker 结点上具有水平扩展的能力。无论生产者还是消费者实际的生产和消费都是针对 Q 级别。例如 Producer 发送消息的时候会预先选择(默认轮询)好该 Topic 下面的某一条 Q 发送;Consumer 消费的时候也会负载均衡地分配若干个 Q只拉取对应 Q 的消息。每一条 message queue 均对应一个文件这个文件存储了实际消息的索引信息。并且即使文件被删除也能通过实际纯粹的消息文件(commit log) 恢复回来。
消息堆积如何解决
提高消费能力消费者扩容如果当前Topic的Message Queue的数量大于消费者数量就可以对消费者进行扩容增加消费者来提高消费能力尽快把积压的消息消费玩。消息迁移Queue扩容如果当前Topic的Message Queue的数量小于或者等于消费者数量这种情况再扩容消费者就没什么用就得考虑扩容Message Queue。可以新建一个临时的Topic临时的Topic多设置一些Message Queue然后先用一些消费者把消费的数据丢到临时的Topic因为不用业务处理只是转发一下消息还是很快的。接下来用扩容的消费者去消费新的Topic里的数据消费完了之后恢复原状。类似kafka的增加分区
顺序消息如何实现
顺序消息分为全局顺序消息和部分顺序消息全局顺序消息指某个 Topic 下的所有消息都要保证顺序部分顺序消息只要保证每一组消息被顺序消费即可比如订单消息只要保证同一个订单 ID 个消息能按顺序消费即可。 订单场景为例保证每个订单都保证创建、付款、完成的顺序且每个订单不能互相串联将不同订单的消息路由到不同的分区中。文档只是给出了Producer顺序的处理Consumer消费时通过一个分区只能有一个线程消费的方式来保证消息顺序 同kafka比如说我们建了一个 topic有三个 partition。生产者在写的时候其实可以指定一个 key比如说我们指定了某个订单 id 作为 key那么这个订单相关的数据一定会被分发到同一个 partition 中去而且这个 partition 中的数据一定是有顺序的。
全局顺序消息 要保证全局顺序消息 需要先把 Topic 的读写队列数设置为 一然后Producer Consumer 的并发设置也要是一。简单来说为了保证整个 Topic全局消息有序只能消除所有的并发处理各部分都设置成单线程处理 这时候就完全牺牲RocketMQ的高并发、高吞吐的特性了。
分布式事务
核心思路利用事务回查即rocketmq会定时遍历commitlog中的半事务消息RocketMQ不能保证消息不重复要再消费者端做好幂等性
半事务阶段
生产者发一条消息到rocketmq但该消息只存在commitlog中对消费者不可见
commit/rollback阶段
该阶段主要是把 prepared 消息保存到 consumeQueue 中即让消费端可以看到此消息也就是可以消费此消息。如果是 rollback 就不保存 Kafka与Rocketmq的区别
Broker差异
主从差异 kafka的master、slave是基于partition维度leader同步给follower而rocketmq是基于broker维度master同步给salve
刷盘 rocketmq支持同步刷盘每次消息刷盘之后再返回kafka内部partation支持异步同步数据
数据写入 kafka每个partition独占一个目录每个partition均有数据文件.logkafka的topic对应多个partitionrocketmq是每个topic共享一个数据文件commitlog Producer差异
发送方式 kafka默认使用异步发送的形式有一个memory buffer暂存消息同时会将多个消息整合成一个数据包发送这样能提高吞吐量但对消息的实效有些影响rocketmq可选择使用同步或者异步发送。
发送响应 kafka的发送ack支持三种设置消息存进memory buffer就返回等到leader收到消息返回等到leader和ISR的follower都收到消息返回当然kafka都是异步刷盘。rocketmq都需要等broker的响应确认有同步刷盘异步刷盘同步双写异步双写等策略相比于kafka多了一个同步刷盘。 Consumer差异
消息过滤 rocketmq的queue和kafka的partition对应但rocketmq的topic还能更加细分可对消息加tag同时订阅时也可指定特定的tag来对消息做更进一步的过滤。
有序消息 rocketmq支持全局有序和局部有序kafka也支持有序消息但是如果某个broker宕机了就不能在保证有序了
消费确认 rocketmq仅支持手动确认也就是消费完一条消息ack1会定期向broker同步消费进度或者在下一次pull时附带上offset。kafka支持定时确认拉取到消息自动确认和手动确认offset存在zookeeper上
事务支持 rocketmq利用事务回查实现分布式事务kafka不支持
