书接上文，当消息存储到文件后，并没有看到他与消费者有相关操作？那么消费者改如何获取呢？
image.png
在前文中讲述了文件落盘，在log中还包含一个提交服务。CommitRealTimeService，用于将已经落盘的数据进行提交到分配索引中（pos）。也即当我们落盘后需要经过CommitRealTimeService才能继续处理。
image.png
image.png
image.png
如果是主从。
image.png
提交如下：
image.png
至此提交完成，writeBuffer是否存在来判断是否直接以WROTE_POSITION_UPDATER作为pos，否则以COMMITTED_POSITION_UPDATER为pos。此处大量篇幅讲述pos主要在于后面派发时会使用到。
image.png
此服务非常重要，用于消息的派发。
image.png
image.png
image.png
image.png
image.png
image.png
image.png
存在三个派发器，此处以CommitLogDispatcherBuildConsumeQueue进行讲解，该派发器用于处理消息到消费队列的过程。
image.png
image.png
image.png
还是比较简单的，就是从map中获取。
image.png
当然再启动是也会从文件中加载该map。
image.png
image.png
至此后续所有操作都将进入消费队列consumeQueue对象。
image.png
image.png
image.png
至此将消息加入到消费队列中。
消息消费在mq中存在两种模式1、消费端维护pos通过pull获取消息 2.pop弹出最新消息两种模式。
第一种 PullMessageProcessor
image.png
image.png
image.png
image.png
image.png
至此消息已经获取完成。还需要讲解得是，当获取完消息后需要记录消费偏移，为Pop模式做记录，pull模式由用户维护偏移，而pop模式则由服务端做记录。
image.png
image.png
image.png
至此更新到map中。目前看他是通过内存进行记录的，实际它存在对应的文件。
image.png
每十秒存储一次。
image.png
写入文件。
image.png
提供offset存储文件位置。
第二种 PopMessageProcessor
image.png
image.png
image.png
image.png
