文档提交之flush(五)

  本文承接文档提交之flush(四),继续依次介绍每一个流程点。

文档提交之flush的整体流程图

图1:

更新删除信息

图2:

  在执行更新删除信息的流程点之前,我们需要等待所有执行DWPT的doFlush()的线程执行完毕。

  为什么会有多线程执行执行DWPT的doFlush()的流程

  为什么需要等待所有执行DWPT的doFlush()的线程执行完毕

  可能会导致触发主动flush的线程已经执行完flush的工作,但其他线程中的DWPT还未生成一个段,无法保证线程A执行主动flush后应有的结果完整性。

  为什么还要更新删除信息

  在此流程点,删除信息同样被封装到一个FlushTicket中,跟之前文章中所有提及的FlushTicket不同的是,它其中的FlushedSegment对象是个null值,这个null很重要,在后面执行发布生成的段的流程中,根据FlushedSegment是否为null来区分两种不同作用的FlushTicket:

  我们结合文档提交之flush(四)中提到的生成出错的FlushTicket的情况,根据FlushedSegment跟FrozenBufferedUpdates不同可以归纳出在主动flush下FlushTicket的四种状态:

强制发布生成的段

图3:

  发布生成的段分为强制尝试两种情况,其区别在文档提交之flush(四)已介绍,不赘述,在本篇文章中主要介绍发布生成的段的流程。

  为什么在这个阶段要强制执行发布生成的段

发布生成的段的流程图

图4:

强制、尝试发布生成的段

图5:

  图5中,是否强制执行分别对应了强制发布生成的段以及尝试发布生成的段

  为什么要区分强制尝试

取出允许发布(publish)的FlushTicket

图6:

  图6中,从队列中取出一个FlushTicket,队列即Queue<FlushTicket> queue(见文档提交之flush(四)

  源码中判断FlushTicket是否能发布的条件如下:

发布FrozenBufferedUpdates、FlushedSegment

图7:

  图7中FlushedSegment和FrozenBufferedUpdates同时为空的条件的条件即上文中FlushTicket的状态三。

  由于篇幅原因,发布FrozenBufferedUpdatesFlushedSegment的流程将在下篇文章中展开介绍。

结语

  

点击下载附件