文章目录
概要
-
producer :生产者，将消息发送到Broker
-
topic:消息主题，用于消息的逻辑分类。Producer将消息发送到特定的Topic中，Consumer从指定的Topic中消费消息
-
broker:消息存储，存储和转发消息。
-
consumer:消费者，从Broker消费消息。
-
nameserver:mq注册中心，保存broker地址、topic、queue的信息，建立生产者、消费者、在启动的时候从nameserver获取对应的broker的信息。
-
Message Queue：消息队列，是Topic的物理实现。一个Topic可以有多个Queue，每个Queue都是单独的存储单元。Producer发送的消息会被存储到对应的Queue中，Consumer从指定的Queue中消费消息。
-
topic是消息的逻辑容器，用于分类消息，实现消息的订阅与发布。
-
messageQueue的组织方式：messageQueue是topic下的消息队列，负责存储消息，保证消息的顺序和负载均衡。
-
Topic与messageQueue的映射关系：每个Topic可以包含多个messageQueue，实现消息的分片存储和高效处理。
broker中的存储与索引：
- 消息存储机制：broker利用commitLog和consumeQueue实现消息的持久化存储。
- 消息的过滤策略：broker支持根据消息属性进行过滤，实现消息的高效路由。
- 索引文件结构：通过indexFile为消息建立索引，便于快速检索和定位消息。
集群高可用：
- producer：通过MQ的负载均衡模块选择相应的broker集群队列进行消息投递，投递的过程支持快速失败和重试
- 集群消费模式：集群消费模式下，消费者急群众的每个实例平均分摊消息，实现负载均衡。
- 广播消费模式：在广播消费模式中，消息会被推送给消费者急群众的每一个实例，确保消息无遗漏。
- consume：消费者集群支持以推拉两种模式对消息进行消费，同时也支持集群方式和广播方式的消费
- 集群模式：消费者集群中的每个实例平均分摊消息，提高效率。
- 广播消费：将消息发送给所有消费者实例，确保每个实例都能收到相同的消息。
- broker：主要负责消息的存储，投递和查询，是rockerMQ消息高可用不丢失的关键,支持主从模式，为了保证高可用需要用多节点多副本模式，如果确定消息完全不丢失，需要配置同步复制，如果需要保证性能可以配置异步复制模式，但是这种有丢消息的风险
- nameserver：注册中心、既可以管理broker建立心跳检测，还能告诉生产者、消费者broker的路由信息。
- 消费者角色与功能：消费者集群通过订阅主题，实时接收并处理消息。
- 负载均衡机制：在消费者集群中，负载均衡确保消息均匀分配给各个消费者实例
- 故障转移策略：当某个消费者实例出现故障时，故障转移策略能够保证消息处理的连续性。
各组件与nameServer关系：
- producer:与nameserver集群中的其中一个节点建立长链接，定期从nameserver获取topic的路由信息，并向提供topic的服务的master简历长链接，且定时向master发送心跳。
- consumer:与nameserver集群中的其中一个节点建立长链接,定期从nameserver获取topic的路由信息,并向提供topic的服务的master、salve长链接，且定时向master/salve发送心跳。这样consumer既可以从master也可以从salve订阅消息。
- broker:每个broker与nameServer集群中的所有节点建立长链接定时注册topic信息到所有nameServer上。
消息的应用场景和原理
- 顺序消息：顺序消息保证消息的消费顺序与发送顺序一致，适用于需要严格顺序执行的场景，像订单服务的流转。
- 定时、延时消息：定时消息允许消息在指定时间后被消费，而延时消息则在消息发送后一定时间再投递，用于到期关闭、提醒等。
- 事物消息：事物消息支持分布式事物、确保消息的发送和业务操作的原子性，适用于需要保证系统一致性的场景，如银行转账。
rocketmq原理
每个topic都有queeen里面放着索引offset、通过offset索引到真实消息对应的commitlog文件位置的起点然后读取到topic对应的实际内容，不用纠结是consumer queen还是message queen，有时我们需要消息的顺序必须是一致有序的（数据增量同步）。
要顺序消费，必须保证生产是顺序的，可以用单一的生产者、或串行排队生产还要设置相同的shardingkey，这样rockermq会把消息放在同一个queue里，保证消息顺序。消费者要保证消息是推、由服务端一条一条的发送，这样可以保证有序。拉需要业务自己保证有序性，另外合理设置重试次数，也会避免消费乱序。
延迟消息原理
- rockermq4.x只有延时消息。一共18个level，不支持自定义时间。
每个level都有一个特定的队列，定时去扫描，（不同的时间放在同一队列，比如有2秒的消息在1秒的前面、这两个消息都可以投递了、但第一个消息会先被投递，为了避免这类问题，设计了18个队列。） - rockermq5.x 支持了自定义时间。定时消息主要用于分布式任务调度。 定时消息和延时消息本质上是存储在2个文件里，一个文件是索引，一个文件是消息内容，索引的文件里按照最近两天的所有时间点已经划分了相应的格子。需要投递的消息会索引到这个格子，两天之后这些格子会被重新覆盖，这样只要索引到相应的位置定时任务就会知道什么时候投递这些消息。
- 采用时间轮的设计
- 时间轮通过环形结构存储定时任务，利用指针移动来触发到期任务，提高效率。
- 不同层级代表不同的时间精度，支持不同的时间粒度的消息。
- 时间轮设计允许灵活调整定时精度，满足不同业务场景下对消息精度的需求。
- 采用时间轮的设计
RocketMQ事物消息
通过TransactionListener实现
- 向broker发送一个半消息未prepared状态
- broker将消息持久存储在事物消息日志中，此时该消息还不能被消费者看到。
- 告诉消息发送方半事物消息发送成功
- 执行本地任务，提交本地事物或者回滚。
- broker提交本地半消息或者回滚。
- 未收到需要提交还是回滚则需要回查调用方是否成功，调用方查询本地是否成功，告知broker本地事物执行结果。
- broker如果commit则把半消息还原成完整消息发送给消费者
- 半消息如果超过72小时则删除。
消息不丢失
生产者开启同步模式，发送到broker，broker会先将消息存储到内存，然后同步刷盘落库后，返回生产者，生产者拿到sendResult。
如果不开启同步使用异步，则需要重写sendCallBack的onsuccess和onException,用于给broker回调成功确认或者失败后重新发送。如果broker是集群，集群之间同步采用的是异步，则要修改同步方式为同步完成后再返回。
消费端使用用ACK机制来确保消息消费，可以消费完再ACK，或者为了吞吐量可以先将消息持久化，然后返回后再进行消费。
消息堆积
- 增加消费者
- 提升消费速度
- 降低生产者投递速度
- 消息过期清理
- 调整配置的参数：拉取消息时间间隔、消费模式改为推。
- 增加topic队列数
重试机制
- RocketMQ消息重新投递的次数和一直失败后的处理机制如下：
-
消息重新投递次数
RocketMQ默认允许每条消息最多重试16次。这个重试次数是针对消费端而言的，即当消费者消费消息失败时，RocketMQ会自动将消息重新投递给消费者进行重试。 -
重试时间间隔
每次重试的间隔时间会逐渐增加，初始的延迟可能较短（如30秒），之后每次重试的间隔时间会逐渐延长，直到最后一次可能达到2小时。具体的重试时间间隔取决于RocketMQ的配置和版本，但通常遵循一个递增的延迟策略。 -
一直失败后的处理
如果消息在达到最大重试次数（默认为16次）后仍然消费失败，RocketMQ将不再继续投递该消息给消费者。此时，消息将被视为“死信”，并被放入一个特殊的队列中，称为死信队列（Dead-Letter Queue，DLQ）。死信队列的名称通常遵循“%DLQ%+ConsumerGroup”的格式，其中ConsumerGroup是消费组的名称。 -
死信队列的处理
死信队列中的消息不会再被消费者正常消费。这些消息需要由系统管理员或开发人员手动处理。处理死信队列中的消息通常涉及以下几个步骤：
-
识别问题：首先，需要分析为什么这些消息会进入死信队列，是消息本身的问题还是消费者处理逻辑的问题。
处理消息：根据问题的原因，对死信队列中的消息进行处理。这可能包括修复消息、重新发送消息到正确的队列、或者将消息记录到日志中以便后续分析。
优化系统：根据处理死信队列的经验，优化消息处理逻辑或系统配置，以减少未来消息进入死信队列的可能性。
注意事项
消息重试机制是RocketMQ保证消息可靠性的重要手段之一，但也可能导致消息处理延迟增加。
在设计消息处理逻辑时，应考虑到消息可能失败并需要重试的情况，并采取相应的容错措施。
定期检查和处理死信队列是维护消息系统健康运行的重要任务之一。
rocketmq 集群各broker之间是怎么来怎么来实现的同步复制与故障恢复
-
同步复制
- 在RocketMQ集群中，Broker之间的同步复制主要通过主从架构实现。这种架构确保了消息在写入主Broker后，能够同步到从Broker，从而保证数据的冗余和可靠性。
- 数据写入：
- 当生产者发送消息到Broker时，消息首先被写入主Broker的CommitLog（提交日志）中。
- CommitLog是RocketMQ存储消息数据的主要文件，每条消息都会先写入到CommitLog中。
- 同步到从Broker：
- 主Broker在写入CommitLog后，会根据配置（如同步复制或异步复制）将消息同步到从Broker。
- 在同步复制模式下，主Broker会等待从Broker确认消息已写入其CommitLog后，才向生产者返回写入成功的响应。
- 这种模式保证了数据在主从Broker之间的一致性，但可能会降低写入的性能。
- 数据冗余：
- 通过主从复制，RocketMQ实现了数据的冗余存储，从而提高了系统的容错能力。
-
故障恢复
当集群中的某个Broker发生故障时，RocketMQ通过以下机制实现故障恢复：- 主从切换：
- 如果主Broker发生故障，从Broker将自动或手动（取决于配置）接管主Broker的角色，继续处理消息。
- 在主从切换过程中，RocketMQ会确保数据的连续性和一致性，从而避免消息丢失或重复。
- 数据恢复：
- 如果从Broker中的CommitLog数据丢失或损坏，可以通过主Broker或其他可用的从Broker中的数据进行恢复。
- RocketMQ支持从ConsumeQueue（消费队列）和IndexFile（索引文件）中重新构建数据，以恢复丢失的消息。
- 消费者重试：
- 在Broker故障期间，消费者可能会遇到无法获取消息的情况。RocketMQ的消费者机制支持自动重试，确保在Broker恢复后能够继续消费消息。
- 集群重新平衡：
- 当集群中的Broker数量发生变化时（如增加或减少节点），RocketMQ会自动进行集群重新平衡，以优化资源分配和负载均衡。
扫一扫
1432
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
