关于消费者的Rebalance过程，入口在RebalanceService，这是个线程，默认每隔20s做一次rebalance。 我们追进来，看一下RebalanceImpl的doRebalance方法： 这里可以看到，对所有Consumer端维护的Topic都进行rebala…

消费者拉取消息，使用的是PullMessageProcessor，看一下processRequest方法，一开始初始化response的相关数据，然后是校验，我们具体看一下： 第一和第三步校验的内容比较简单，我们主要看第二步，即校验consumer配置的部分： 这里有个小细节，…

继续上一篇我们说了broker的消息存储过程，这一篇我们看一下消息在broker上以何种形式存储。 消息的存储最终通过CommitLog这个类来做，CommitLog，MappedFileQueue和MappedFile这三个类抽象了存储过程中的相关概念，对应关系如下：Comm…

我们下面两篇文章看消费者。消息队列主要就是生产和消费两端，但是其实rocketmq还有很重要的两个部分是broker和nameserver，broker中有真正的消息，nameserver是一个类似注册中心的角色。broker中存储的消息结构复杂，我们后面再看，先看拉取。 消费…

具体的发送demo我就不贴了，直接到里面去看实现了。 看到DefaultMQProducerImpl的sendDefaultImpl方法，这个方法非常的长，中间涉及到多个过程，比如拉取topic路由信息等，我们一部分一部分来看，先看开头部分： 一开始的部分比较简单，首先做一些基…

rocketmq只支持固定精度的定时消息，如果要支持任意的时间精度，需要在broker层面做消息排序，如果要持久化，那么将产生巨大的开销。 延迟级别我就不列举了。 这篇文章除了讲解定时消息，还会连带讲解一下ReputMessageService、ConsumeQueue和消息重…

三种刷盘策略性能依次降低。 先看刷盘策略被初始化的部分： 这里初始化了两个FlushCommitLogService，第一个是根据刷盘策略来的，第二个固定是CommitRealTimeService，也就是我们说的性能最好的刷盘策略。 后面会讲到作用。 我们先看第二和第三种刷盘…

Filtersrv负责自定义代码过滤Consumer从Broker拉去的消息。在没有Filtersrv的情况下，拉取消息很简单，就是直接连接Broker进行拉取即可。如果有了Filtersrv，则拉取是： Consumer ——> Filtersrv ——> Broker 对应…

普通顺序消息：Producer将相关联的消息发送到相同的消息队列。 严格顺序消息：在 普通顺序消息 的基础上，Consumer严格顺序消费。 目前已知的严格顺序消息，只使用在数据库binlog同步中。 普通顺序消息是使用MessageQueueSelector来实现的： 以上的…