知技所以然-优快云博客

原创 RocketMQ的注册中心NameServer解析

NameServer设计追求的是简单的原则。总结下来几点：NameServer通常也是集群的方式部署，通过其上述的启动代码，我们可以看出，各实例间相互不进行信息通讯，每个NameServer节点都是对等存在，保存完整的路由信息，若其中一台NameServer实例down机了，不会影响整体的运行。Broker是连接每一个NameServer实例，发送注册信息与心跳，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。

2024-12-22 16:33:56 752

原创 RocketMQ消费进度管理解析

RocketMQ 的生产者和消费者在进行消息收发时，必然会涉及以下场景，消息先生产后订阅或先订阅后生产。这两种情况下，消费者端启动后从哪里开始消费？如何标记已消费的消息？这些都是由RocketMQ 的消费进度管理机制来定义实现的。消费者启动后从哪里开始消费消息？消费者每次消费成功后如何标记消息状态，确保下次不会再重复处理该消息？某消息被指定消费者消费过一次后，如果业务出现异常需要做故障恢复，该消息能否被重新消费？当消息堆积时，而这些消息如果又不重要，如何设置重置消费位点，从而不消费这些消息?

2024-12-11 22:03:32 1290

原创 RocketMQ消息者PULL请求模式拉取消息

RocketMQ消费者PULL请求模式拉取消息，是通过消费者端与服务端Broker的多个线程进行配合，做到消息拉取的及时与减少拉取的Broker性能损耗（通过长连接）。消费者处理发起拉取请求的线程PullMessageService服务端Broker处理未拉取到消息的hold线程PullRequestHoldService服务端Broker消息写入后的重放后的线程ReputMessageService。

2024-11-23 22:57:02 1468

原创 RocketMQ消费者POP请求模式负载均衡实现

分析了RocketMQ在3.x/4.x版本分析了基于消费队列粒度的消息消费负载均衡策略（即一个队列只能分配给消费分组中的一个消费者），这种设计会带来下面的情况：若消费分组对应的消费者数量大于消费队列数，可能会出现部分消费者无绑定消费队列的情况（消费者空转，空闲无法消费到消息）。若某个消费者实例由于物理资源规格不一致或者其他某些原因引起的消费慢，会存在当前消费者绑定的一些消费队列出现消息堆积。而对于流式处理、聚合计算场景，需要明确地对消息进行聚合、批处理时，更适合使用这种消费队列粒度的负载均衡策略。

2024-11-20 22:07:57 973

原创 RocketMQ消费者PULL请求模式负载均衡

PULL请求模式是指：在一个消费分组，消息消费时以消费队列粒度进行消费，即内共享消费场景下，消费者分组内多个消费者共同分担消息，消息按照哪种逻辑分配给哪个消费者，就是由消费者负载均衡策略所决定的，在该模式下负载均衡保证同一个消费队列仅被一个消费分组内的一个消费者处理，该策略的实现依赖消费者和服务端的信息协商机制，RocketMQ 并不能保证协商结果完全强一致。若消费队列数小于消费者数量，可能会出现部分消费者无绑定消费队列的情况（导致消费者空转，无法消费到消息）。

2024-11-16 23:03:04 1359

原创 RocketMQ消费者启动源码解析

把DefaultMQPushConsumer对象中的订阅关系缓存Map subscription复制到RebalancePushImpl对象中的进行订阅关系缓存ConcurrentMap subscriptionInner；流控时设置的每个队列中的消息个数只能为[1,65535]（默认为1000，因为一次批量拉取消息可能不精确）；

2024-11-14 22:03:22 1296

原创 RocketMQ消息过滤实现原理

因为boker端只判断的tags的hashcode值，可能存在不同的tags哈希值相同，在消费者端处理拉取结果的方法 PullApiWrapper#processPullResult 中，再次根据tags的字符串进行精确判断，判断tags字符串值缓存Set中是否包含消息的 tags值，则返回给消费者消费。若消费者只需要关注部分消息，可通过设置订阅消息过滤条件在RocketMQ服务端进行过滤，只获取到需要关注的消息子集，避免接收到大量无效的消息。当前实例加锁后，发送心跳把订阅信息给所有的broker服务器。

2024-11-10 22:31:40 1412

原创 RocketMQ延迟消息实现原理（下）

这几个线程配合执行的流程图如下所示：分析了rocketmq4.x版本中支持的默认级别的延迟消息的实现原理，默认的延迟级别无法满足用户对任意秒级时间的诉求，rocketmq5版本中支持了定时任意秒级时间的，所以本文一起来看支持任意秒级时间的定时消息的实现原理。

2024-11-06 22:03:48 1032

原创 RocketMQ延迟消息实现原理（上）

上面发送代码中设置的等级5对应的就是延迟1m的设置，具体等级的设置与延迟的时间对应关系，是在rocketmq启动的时候就会加载解析上面的配置信息，进行延迟等级与时间的映射，具体有两块地方用到这个配置，分别是消息存储与定时调度。可以看到相对于发送普通消息，增加了设置延迟等级这个属性，这个延迟等级是个int类型的属性，在发送的消息中是放到消息的扩展属性中的，key：DELAY，value：xx（等级值，如上面的5）将消息再次存入到commitlog中，并异步转发到对应的消息队列上，此时消费者可以消息到消息。

2024-11-02 13:03:53 996

lizhonghai0209的博客