RocketMQ 深入分析 Offset 与 CommitLog

消息偏移量 Offset

message queue 是无限长的数组，一条消息进来下标就会涨1，下标就是 offset，消息在某个 MessageQueue 里的位置，通过 offset 的值可以定位到这条消息，或者指示 Consumer 从这条消息开始向后处理。
message queue 中的 maxOffset 表示消息的最大 offset，maxOffset 并不是最新的那条消息的 offset，而是最新消息的 offset+1，minOffset 则是现存在的最小 offset。
fileReserveTime=48 默认消息存储48小时后，消费会被物理地从磁盘删除，message queue 的 minOffset 也就对应增长。所以
比minOffset 还要小的那些消息已经不在 broker上了，就无法被消费

类型(父类是OffsetStore)：

• 本地文件类型
  DefaultMQPushConsumer 的 BROADCASTING 模式，各个 Consumer 没有互相干扰，使用 LoclaFileOffsetStore，把 Offset 存储在本地
• Broker 代存储类型
  DefaultMQPushConsumer 的 CLUSTERING 模式，由 Broker 端存储和控制 Offset 的值，使用 RemoteBrokerOffsetStore

作用

主要是记录消息的偏移量，有多个消费者进行消费

• 集群模式下采用 RemoteBrokerOffsetStore，broker 控制 offset 的值, 因为需要broker来控制并发消费
• 广播模式下采用 LocalFileOffsetStore，消费端存储, 由于在广播模式下, 每个consumer收到的消息都是全量的, 所以不需要将offset存储到broker控制并发, 存储到本地文件(offsets.json)就好.

建议采用 pushConsumer，RocketMQ 自动维护 OffsetStore，如果用另外一种 pullConsumer 需要自己进行维护 OffsetStore

消息存储 CommitLog

消息存储是由 ConsumeQueue 和 CommitLog 配合完成

• ConsumeQueue 是逻辑队列，CommitLog 是真正存储消息文件的，ConsumeQueue 存储的是指向物理存储的地址。
• Topic 下的每个 message queue 都有对应的 ConsumeQueue 文件，内容也会被持久化到磁盘。
  默认地址：store/consumequeue/{topicName}/{queueid}/fileName
• CommitLog：存储消息真正内容的文件。
  • 生成规则：
    每个文件的默认1G =1024 * 1024 * 1024，commitlog 的文件名 fileName，名字长度为20位，左边补零，剩余为起始偏移量；比如 00000000000000000000 代表了第一个文件，起始偏移量为0，文件大小为1G=1 073 741 824 Byte；当这个文件满了，第二个文件名字为00000000001073741824，起始偏移量为1073741824，消息存储的时候会顺序写入文件，当文件满了则写入下一个文件。
  • 判断消息存储在哪个 CommitLog 上
    例如 1073742827 为物理偏移量，则其对应的相对偏移量为 1003 = 1073742827 - 1073741824，并且该偏移量位于第二个 CommitLog。

Broker 里面一个 Topic 里面有多个 MesssageQueue，每个 MessageQueue 对应一个 ConsumeQueue，ConsumeQueue 里面记录的是消息在 CommitLog 里面的物理存储地址。