关于Kafka high watermark的讨论2

  之前写过一篇关于Kafka High watermark的文章,引起的讨论不少:有赞扬之声,但更多的是针对文中的内容被challenge,于是下定决心找个晚上熬夜再看了一遍,昨晚挑灯通读了一遍确实发现不少错误。鉴于此我决定再写一篇博客重新梳理一下最新版本中High watermark(下称HW)的工作原理,也算是纠正之前文章中的错误。这次我不打算说leader epoch,而只是专门讨论HW、log end offset(日志末端位移,下称LEO)的事情。希望我能把整个流程交代清楚。也许这篇文章依然有很多问题,到时候就恳请各位多多批评指正了:)


  和之前第一篇一样,我首先给出与HW、LEO相关的副本角色定义:

  1. leader副本:分区leader所在broker上面的Replica副本对象,不断处理follower副本发送的FETCH请求
  2. follower副本:分区follower所在broker上面的Replica副本对象,不断地向leader副本发送FETCH请求
  3. ISR副本:这实际上是一个副本集合,包含leader副本和所有与leader副本保持同步的follower副本。如何判定保持同步:replica.lag.time.max.ms时间内follower副本未发送任何FETCH请求或未赶上leader副本LEO则判定为不同步

每个Replica对象都有很多属性或字段,和本文相关的是LEO、remote LEO和HW。

  1. LEO:日志末端位移(log end offset),记录了该Replica对象底层日志(log字段)中下一条消息的位移值。注意是下一条消息!也就是说,如果一个普通topic(非compact策略,即cleanup.policy != compact)的某个分区副本的LEO是10,倘若未发生任何消息删除操作,那么该副本当前保存了10条消息,位移值范围是[0, 9]。此时若有一个producer向该副本插入一条消息,则该条消息的位移值是10,而副本LEO值则更新成11。
  2. remote LEO:严格来说这是一个集合。leader副本所在broker的内存中维护了一个Partition对象来保存对应的分区信息,这个Partition中维护了一个Replica列表,保存了该分区所有的副本对象。除了leader Replica副本之外,该列表中其他Replica对象的LEO就被称为remote LEO,这些LEO值也是要被更新的。
  3. HW:上一篇中我是这么描述HW值的——“水位值,对于同一个副本对象而言其HW值不会大于LEO值。小于等于HW值的所有消息都被认为是‘已备份’的”—— 严格来说,我这里说错了。实际上HW值也是指向下一条消息,因此应该这样说:小于HW或在HW以下的消息被认为是“已备份的”。另外上篇文章中的配图也是错误的,如下所示

  之前文章中说HW是7时,位移介于[0, 7]的所有消息都是committed状态。这种说法是有问题的,实际上,如果要让[0, 7]的消息是committed状态,那么HW值应该是8。当然关于LEO的表述是正确的,即:LEO=15表示这个副本当前有15条消息,最新一条消息的位移是14。另外我们总说consumer是无法消费未提交消息的。这句话如果用以上名词来解读的话,应该表述为:consumer无法消费分区leader副本中位移值大于等于分区HW值的任何消息。这里需要特别注意分区HW值就是leader副本的HW值


说一些题外话~~~~~

  在判断能否消费某条消息时到底比较的是”小于HW“还是”小于等于HW",我个人倾向于认为是小于HW,即位移=HW值的消息是不能被消费的。我们可以从Log.scala的read方法签名中证明这点:

/**
   * Read messages from the log.
   *
   * @param startOffset The offset to begin reading at
   * @param maxLength The maximum number of bytes to read
   * @param maxOffset The offset to read up to, exclusive. (i.e. this offset NOT included in the resulting message set) <==== 注意这行!!!
   * @param minOneMessage If this is true, the first message will be returned even if it exceeds `maxLength` (if one exists)
   * @param isolationLevel The isolation level of the fetcher. The READ_UNCOMMITTED isolation level has the traditional
   *                       read semantics (e.g. consumers are limited to fetching up to the high watermark). In
   *                       READ_COMMITTED, consumers are limited to fetching up to the last stable offset. Additionally,
   *                       in READ_COMMITTED, the transaction index is consulted after fetching to collect the list
   *                       of aborted transactions in the fetch range which the consumer uses to filter the fetched
   *                       records before they are returned to the user. Note that fetches from followers always use
   *                       READ_UNCOMMITTED.
   * @throws OffsetOutOfRangeException If startOffset is beyond the log end offset or before the log start offset
   * @return The fetch data information including fetch starting offset metadata and messages read.
   */
  def read(startOffset: Long, maxLength: Int, maxOffset: Option[Long] = None, minOneMessage: Boolean = false,
           isolationLevel: IsolationLevel): FetchDataInfo = {
...
}

  参数maxOffset是exclusive的,也就是说这个位移上的消息是不会被读取的。下面这段代码证明了在实际调用过程中read的maxOffset也是传入的HW值:

def read(tp: TopicPartition, fetchInfo: PartitionData, limitBytes: Int, minOneMessage: Boolean): LogReadResult = {
......
		val initialHighWatermark = localReplica.highWatermark.messageOffset  // <==== 注意这行!
......
        val maxOffsetOpt = if (readOnlyCommitted) // follower拉取消息一定拉取committed的
          Some(lastStableOffset.getOrElse(initialHighWatermark))
        else
          None
......
            val fetch = log.read(offset, adjustedFetchSize, maxOffsetOpt, minOneMessage, isolationLevel)
......
}  

  不过LogSegment.scala的read方法并未严格实现这一点,貌似又支持读取offset=HW值的消息,如下所示:

def read(startOffset: Long, maxOffset: Option[Long], maxSize: Int, maxPosition: Long = size,
           minOneMessage: Boolean = false): FetchDataInfo = {
......
    val fetchSize: Int = maxOffset match {
      case None =>
        // no max offset, just read until the max position
        min((maxPosition - startPosition).toInt, adjustedMaxSize)
      case Some(offset) =>
        if (offset < startOffset) // 并未比较相等的情况,也就是说startOffset = HW值的话也可继续读取数据
          return FetchDataInfo(offsetMetadata, MemoryRecords.EMPTY, firstEntryIncomplete = false)
        val mapping = translateOffset(offset, startPosition)
        ......
    }
......
}  

  虽然在后面代码中加入了HW位移值对应物理文件位置是否真实存在的判断逻辑,但毕竟做了一次物理文件位置的转换操作(调用LogSegment#translateOffset),应该说是做了一些无用功的——后续我可能会提一个jira跟社区讨论一下此事,不过目前我们还是先认定HW值处的消息是不能被消费的。


  在讨论HW、LEO工作原理的时候,下面这张图能够很好地解释leader副本对象和follower副本对象的主要区别: 

 

   如前所述,所有的副本对象都保存在分区Partition对象的一个列表中。为了区别leader副本和follower副本,上图中我还是把它们拆开分别表示,这样会更加清晰一些。图中灰色字段表示不会被更新,也就是说leader Replica对象是不会更新remote HW值的(这里的remote含义与remote LEO相同)。有了这些概念我们现在可以讨论更新时机的问题了:

一、上图右边的follower Replica对象何时更新LEO?

  Follower副本使用专属线程不断地向leader副本所在broker发送FETCH请求,然后leader发送FETCH response给follower。Follower拿到response之后取出里面的数据写入到本地底层日志中,在该过程中其LEO值会被更新。

二、上图左边的leader Replica对象何时更新LEO?

  和follower Replica更新LEO道理相同,leader写底层日志时就会自动地更新它的LEO值。对于leader来说何时会写底层日志呢?最容易想到的一个场景就是producer生产消息时。由此可见,不管是在leader端还是在 follower端,只有写入本地底层日志时才会触发对本地Replica对象上LEO值的更新。

三、上图左下的Other Replicas何时更新LEO?

  首先思考一下为什么leader Partition对象需要保存所有Replica副本的LEO?事实上,它们的主要作用是帮助leader Replica对象确定其HW值之用,而由于leader Replica的HW值就是整个分区的HW值,故这些other Replicas实际上是用来确定分区HW值的。Other Replicas LEO值是在leader端broker处理FETCH请求过程中被更新的。当follower发送一个FETCH请求时,它会告诉leader要从那个位移值开始读取,即FetchRequest中的fetchOffset字段。leader端在更新Other Replicas的LEO时会将其更新成这个fetchOffset值。

四、上图右上的follower Replica对象何时更新HW?

  Follower Replica对象更新HW是在其更新本地LEO之后。一旦follower向本地日志写完数据后它就会尝试更新其HW值。具体算法是取本地LEO与FETCH response中HW值的较小值,因此follower Replica的HW值不会大于其本地LEO值。

五、上图左上的leader Replica对象何时更新HW?

  前面说过了, leader Replica的HW值实际上就是分区的HW值,因此何时更新该值才是我们最关心的,因为它将直接影响分区数据对于consumer的可见性。以下4种情况Kafka会尝试去更新leader Replica对象的HW值:

  1. 该Replica成为leader Replica时:当某个Replica成为分区的leader副本后,Kafka会尝试去更新其HW值
  2. Broker崩溃导致副本被踢出ISR时:此时Kafka会执行ISR的缩减操作,故必须要检查下分区HW值是否需要更新
  3. Producer向leader Replica写入消息时:写入消息会更新leader Replica的LEO,故有必要检查下其HW值是否需要修改
  4. Leader Replica处理FETCH请求时:Leader Replica处理FETCH请求时在更新完Other Replicas的LEO后会尝试更新其HW值 

  上面的条件揭示了一个重要的事实:如果没有出现broker failure或leader变更等情形,分区HW值更新时机只可能有两个:1. leader broker处理PRODUCE请求;2. leader broker处理FETCH请求。Leader Replica HW值变更的算法很简单:首先找出leader Partition对象保存的所有与leader Replica保持同步的Replica对象(leader Replica + other Replicas)的LEO值,然后选择其中航最小的LEO值作为分区HW值。这里的同步判断条件有两个:

  1. 该副本在ISR中
  2. 该副本LEO落后于leader Replica LEO的时间≤ replica.lag.time.max.ms

   乍看上去好像这两个条件说的是一回事,毕竟ISR的定义就是第二个条件描述的那样。但在某些情况下Kafka的确可能出现follower副本已经“追上”了leader的进度,但却不在ISR中——比如某个从failure中恢复的副本。如果Kafka只判断第一个条件的话,确定分区HW值时就不会考虑这些未在ISR中的副本,但这些副本已经具备了“立刻进入ISR”的资格,因此就可能出现分区HW值越过ISR中副本LEO的情况——这肯定是不允许的,因为超过ISR副本LEO的那些消息属于未提交消息。

  在举实际例子之前,我们先确认一下这些更新步骤的顺序。首先是处理PRODUCE请求的逻辑顺序:

之后是leader端broker处理FETCH请求:

最后是follower端broker处理FETCH response:

  下面举个一个实际的例子,该例子中的topic是单分区,副本因子是2。我们首先看下当producer发送一条消息时,leader/follower端broker的副本对象到底会发生什么事情以及分区HW是如何被更新的。首先是初始状态:

此时producer给该topic分区发送了一条消息。此时的状态如下图所示:

 

如上图所见,producer发送消息成功后(假设acks=1, leader成功写入即返回),follower发来了新的FECTH请求,依然请求fetchOffset = 0的数据。和上次不同的是,这次是有数据可以读取的,因此整个处理流程如下图:

 显然,现在leader和follower都保存了位移是0的这条消息,但两边的HW值都没有被更新,它们需要在下一轮FETCH请求处理中被更新,如下图所示:

  简单解释一下, 第二轮FETCH请求中,follower发送fetchOffset = 1的FETCH请求——因为fetchOffset = 0的消息已经成功写入follower本地日志了,所以这次请求fetchOffset = 1的数据了。Leader端broker接收到FETCH请求后首先会更新other replicas中的LEO值,即将remote LEO更新成1,然后更新分区HW值为1——具体的更新规则参见上面的解释。做完这些之后将当前分区HW值(1)封装进FETCH response发送给follower。Follower端broker接收到FETCH response之后从中提取出当前分区HW值1,然后与自己的LEO值比较,从而将自己的HW值更新成1,至此完整的HW、LEO更新周期结束。

  由上面的分析可知,两边HW值的更新是在后面一轮(如果有多个follower副本,也许是多轮)FETCH请求处理中完成的,这种“时间”上的错配也是导致出现各种“数据丢失”或“数据不一致”的原因。基于此社区才引入了leader epoch机制试图规避因使用HW而带来的这个问题。不过本文并不关注leader epoch,只是单纯希望我能把HW、LEO这件事情讲明白。

posted @ 2018-09-04 14:47 huxihx 阅读(...) 评论(...) 编辑 收藏