网站的风格设计包括哪些内容,wordpress wp-json,惠州专业网站建设公司哪里有,wordpress 加视频Broker的关机恢复机制
概述
Broker关机恢复是指恢复CommitLog、Consume Queue、Index File等数据文件。Broker关机分为正常调用命令关机和异常被迫进程终止关机两种情况。恢复过程的设计目标是使正常停止的进程实现零数据丢失#xff0c;异常停止的进程实现最少量的数据丢失…Broker的关机恢复机制
概述
Broker关机恢复是指恢复CommitLog、Consume Queue、Index File等数据文件。Broker关机分为正常调用命令关机和异常被迫进程终止关机两种情况。恢复过程的设计目标是使正常停止的进程实现零数据丢失异常停止的进程实现最少量的数据丢失与关机恢复相关的主要文件有两个:abort和checkpoint.
abort文件
abort是一个空文件标记当前Broker是否正常关机Broker进程正常启动的时候创建该文件。Broker进程正常停止后该文件就会删除如果异常退出则文件依旧存在创建和删除的过程如图
abort文件创建流程 aboirt文件删除流程
Checkpoint文件
checkpoint是检查点文件保存Broker最后正常存储各种数据的时间在重启Broker时恢复程序知道从什么时候恢复数据。检查点逻辑由StoreCheckpoint类实现。 在StoreCheckpoint类中保存了3个时间更新过程如图.
physicMsgTimestamp:最后一条已存储CommitLog的消息的存储时间logicsMsgTimestamp:最后一条已存储Consume Queue的消息的存储时间indexMsgTimestamp:最后一条已存储IndexFile的消息的存储时间physicMsgTimestamp和logicsMsgTimestamp的更新都是在数据存储成功后进行的过程比较简单。而indexMsgTimestamp的逻辑是在Index File刷盘时被更新的Index File刷盘方法IndexService.flush()。 从上述代码可以看到在IndexFile刷盘后已刷盘文件文件的最后存储消息时间被赋值给indexMsgTimestamp,并对Checkpoint文件进行刷盘。 注:IndexFile的刷盘设计和CommitLog、Consume Queue刷盘的方式不同容易被忽略
Broker关机恢复流程
Broker在启动时会初始化abort、checkpoint两个文件。正常关闭进程时会删除abort文件将checkpoint文件刷盘异常关闭时通常来不及删除abort文件。由此在重新启动Broker时会根据abort判断是否需要异常停止进程而后恢复数据。Broker启动时会启动存储服务DefaultMessageStore.存储服务在初始化时执行load方法加载全部数据这里主要分析数据加载流程。Broker关机的恢复过程可以分为以下几步.
第一步:Broker异常退出检查。如果abort文件存在说明上次是异常退出的。第二步:加载延迟消息的位点信息。ScheduleMessageService服务通过继承和重写ConfigManager,调用load()方法从磁盘加载延迟位点文件的内容并根据配置项messageDelayLevel初始化延迟级别第三步:加载全部CommitLog文件(#1部分)。通过读取CommitLog目录下的所有文件依次加载每个CommitLog为MappedFile,并且设置写指针、已刷盘指针、已提交指针使所有指针都指向该文件的最末位.CommitLog文件加载代码如图。如果文件大小已配置的大小不一致恢复时 就直接被忽略所以在重启时不要修改mappedFileSizeCommitLog(默认是1G)参数的值否则数据无法恢复 第四步:加载全部Consume Queue文件及数据(如图#2、#3)。调用loadConsumeQueue方法读取./consumequeue/Topic/queueId/目录加载全部Topic、queueId作为ConsumeQueue对象再调用load()方法初始化每一个ConsumeQueue 第五步:初始化Checkpoint文件为StoreCheckpoint对象并且初始化三个数据:physicMsgTimestamp、logicsMsgTimestsamp和indexMsgTimestamp. 初始化StoreCheckpoint对象 在StoreCheckpoint构造方法中初始化三个时间戳 第六步:加载IndexFile索引(#4部分)。加载./index目录下的全部索引文件如果上次进程异常退出并且索引文件操作的最后时间戳大于Checkpoint中保存的时间则说明当前文件有部分数据可能存在错误须立即销毁文件第七步:恢复全部数据(#5部分)lastExitOKTrue表示上次进程正常退出。全部恢复数据主要恢复ConsumeQueue、CommitLog、内存中的consumeQueueTable并纠正Consume Queue中的最新位点值。 recoverCOnsumeQueue()方法通过循环所有Topic对应的ConsumeQueue依次调用ConsumeQUeue.recover()方法执行数据恢复 recoverNormally()方法在Broker正常关闭后重启执行CommitLog恢复(#5,2)对于CommitLog恢复数据这里有一个小技巧正常恢复是从倒数第三个文件开始直到最后一个文件。正常恢复是假定数据都是正常的大部分场景都关心最新的消息所以恢复最新的三个文件到内存中消息量大小为3GB,当然如果恢复文件个数做成可配置的就更好了 recoverAbnormally()方法在Broker异常关闭后重启时执行CommitLog恢复(#5.3)CommitLog异常恢复是从最后一个文件开始反向恢复到第一个文件。因为当进程异常停止后最容易出错的是最新的某些文件。所以异常恢复时RocketMQ从最后一个文件开始,倒序找第一个正常的文件开始恢复。
CommitLog.isMappedFileMatchedRecover()方法判断文件是否正常整个方法的重点在于只要文件的最后消息的存储时间都小于在Checkpoint保存的对应时间那么该文件并未损坏。
CommitLog恢复完毕会将该文件中的消息重新分发创建ConsumeQueue和IndexFile。分发全部消息还是部分消息时根据duplicationEnable的值(默认为False)来判断的 recoverTopicQueueTable():纠正Consume Queue中最小消费位点和恢复ComitLog内存中的TopicTable(#5.4)
