CommitLog

Producer发送过来的消息是存储在CommitLog中，Producer端每次发送过来的消息是不等长的，每写满1G就会新建一个CommitLog文件继续写入。

那Consumer消费的时候，怎么获取到消息呢？直接从CommitLog中查询消息的话是低效的，RocketMQ作为一个高性能、高吞吐的消息中间件肯定不会采用这个方案，而是使用ConsumerQueue。

ConsumerQueue

ConsumerQueue也是文件，当Broker收到一条消息，写入CommitLog的同时，也会一条ConsumerQueue记录，保存这条消息在CommitLog中的offset、消息大小、对应的Tag的hash值。

每个MessageQueue都会对应一个ConsumerQueue文件，每个ConsumerQueue文件可写30W条消息，超过之后再新建ConsumerQueue文件继续写入。

主从复制

Broker中有两种角色：Master、Slave，Master用于处理生产者、消费者的请求以及消息的存储，Slave从Master中同步所有数据，有以下两个作用：

  1. 保证Broker高可用：作为Master的数据副本，当Master宕机后，消费者可以连接Slave继续消费，避免单点故障
  2. 保证Broker高性能：当Master负载高的时候，Master会建议消费者从Slave上拉取消息，分担Master压力

Broker主从同步的方式有两种：

  1. 同步复制：生产者发送消息到Master，然后Master将消息同步发送到Slave才算发送完成
  2. 异步复制：生产者发送消息到Master即完成，再由异步线程异步发送到Slave

Broker主从同步的数据主要是配置数据和消息数据

标签: none

添加新评论