消费者生产的时候，须要指定去生产哪个Topic的音讯，比方TopicTest。和生产者一样，消费者也须要去NameServer拉取TopicTest对应的元数据信息。如上图所示，TopicTest对应这两个broker，每个broker都有两个MessageQueue，那消费者从哪里拉取数据呢？比方咱们有两个消费者，消费者在启动的时候，会向每个broker发送心跳包…

消费者在发送音讯的时候，有一个分组的概念。也就是说，有一个或者多个消费者的名称，是同一个，这些名称一样的消费者，组成了一个生产组。比方下图中，两个group_a是一个生产组，两个group_b是一个生产组。当broker有音讯a进来的时候，那这个音讯都会同时被这两个生产组所生产。咱们也看到了每个生产组是有多个消费者的…

在音讯一直的发送给Broker，Broker又一直的把音讯贮存在Commitlog文件、ConsumeQueue文件、IndexFile文件里，磁盘总会有用完的那一刻。

后面提到了ConsumeQueue和IndexFile是通过ReputMessageService线程异步同步commitlog日志文件信息的，如果Commitlog日志文件写入胜利后，Broker宕机，那就没方法进行同步了，导致Commitlog、ConsumeQueue、IndexFile文件数据不统一。那RocketMQ是怎么解决的呢？

consumequeue是音讯生产队列存储目录，比方咱们建了一个TopicTest，有四个MessageQueue，那在consumequeue目录下，就有一个TopicTest目录，TopicTest目录下还有0，1，2，3四个目录，对应着MessageQueue的个数。这些数字的上面的文件，就是实际上的数据。

同步刷盘的服务，也是一个线程，专门用来解决这些result。他保护着requestsWrite和requestsRead的链表。requestsWrite是放须要解决的result，requestsRead是放筹备解决的result。

为了保障音讯不失落，RocketMQ会把音讯进行长久化，也就是说，会把音讯写入commitlog的日志，这个目录是在store上面。每个日志大小为1G，所以commitlog会有多个磁盘文件，每个文件名是音讯的物理偏移量。

kafka是有Partition的概率，发送音讯的时候，跟进分区规定进行抉择哪个Partition，每个Partition都有本人对应的broker。

拉取的机会和Kafka — 元数据的拉取机会的相似，分为发消息的时候以及定时工作。拉取的流程获取topic的时候，先从缓存获取是否有这个topic对应的路由数据，如果有，就间接返回。如果本地缓存，那须要通过网络申请（Netty）去NameServer获取topic的路由数据。如果从NameServer拿到topic信息的话，就会把这个topic数据寄存…

ILeaseService接口定义了hasLease、startLeaseTask、lock、tryLocker、unlock、holdLock、hasHoldLock、queryLockedInstanceByNamePrefix办法