DelayedOperationPurgatory--谜之炼狱

  • 在kafka中有很多操作需要延迟等待, 比如客户端发送数据到达leader后, 根据设置ack方式不同,需要等待其replicas返回ack, 那这个ack就需要延迟等待;对于一个拉取操作, 需要延迟等待期望拉取的字节数准备好;
  • 有延迟操作, 那必然会存在操作的超时处理. 还记得我们上一篇Kafka中的时间轮中对Timer的分析吧, 这里的延迟操作需要使用它来实现;

DelayedOperation
  • 所在文件: core/src/main/scala/kafka/server/DelayedOperation.scala
  • 这是个抽象类, 所有具体的延迟任务都需要继承这个类;
  • 同时每个延迟任务必然存在操作的超时, 那么其超时操作是通过将对象放到Kafka中的时间轮中的Timer中处理, 因此这个类又继承自TimerTask;
  • private val completed = new AtomicBoolean(false): 原子变量, 标识当前operation是否已完成;
  • def forceComplete(): Boolean: 强制完成操作;
if (completed.compareAndSet(false, true)) {
      // cancel the timeout timer
      cancel()
      onComplete()
      true
    } else {
      false
    }

分两种情况:

  1. 当前操作已经完成,则不再需要强制完成,返回false;
  2. 当前操作未完成, 则首先在Timer中取消这个定时任务, 然后回调onComplete
  • override def run(): Unit: 实现的是TimerTask的方法, 当超时时会执行此操作:
if (forceComplete())
      onExpiration()

里面的操作比较简单, 调用forceComplete, 如果成功,表明是真的超时了,回调onExpiration;

  • 需要由子类实现的方法:
  1. def onExpiration(): Unit: 超时后的回调处理;
  2. def onComplete(): Unit: 操作完成后的回调处理;
  3. def tryComplete(): Boolean: 在放入到Timer前, 先尝试着执行一下这个操作, 看是否可以完成, 如果可以就不用放到Timer里了, 这是为了确保任务都尽快完成作的一个优化;
Watchers
  • 所在文件: core/src/main/scala/kafka/server/DelayedOperation.scala
  • 对于一个延迟任务, 一般会有两个操作加持在身:
  1. 上面说的作为超时任务放在Timer中;
  2. 与某些事件关联在一起, 可以关联多个事件, 当这些事件中的某一个发生时, 这个任务即可认为是完成;这个就是 Watchers类要完成的工作;
  • class Watchers(val key: Any): 构造时需要一个参数key, 你可以理解成是一个事件;
  • private[this] val operations = new LinkedList[T](): 用于存放和这个key关联的所有操作,一个key可以关联多个操作, 同时一个操作也可以被多个key关联(即位于多个Watchers对象中)
  • def purgeCompleted(): Int: 删除链表中所有已经完成的操作
      var purged = 0
      operations synchronized {
        val iter = operations.iterator()
        while (iter.hasNext) {
          val curr = iter.next()
          if (curr.isCompleted) {
            iter.remove()
            purged += 1
          }
        }
      }
      if (operations.size == 0)
        removeKeyIfEmpty(key, this)

      purged
    }
  • def tryCompleteWatched(): Int:
     var completed = 0
      operations synchronized {
        val iter = operations.iterator()
        while (iter.hasNext) {
          val curr = iter.next()
          if (curr.isCompleted) {
            // another thread has completed this operation, just remove it
            iter.remove()
          } else if (curr synchronized curr.tryComplete()) {
            completed += 1
            iter.remove()
          }
        }
      }

      if (operations.size == 0)
        removeKeyIfEmpty(key, this)

      completed

扫描整个链表:

  1. 如果任务已完成,则移除;
  2. 如果任务未完成, 调用tryComplete尝试立即完成, 如果可以完成, 则移除;
  • 添加任务:
def watch(t: T) {
      operations synchronized operations.add(t)
    }
DelayedOperationPurgatory
  • 所在文件: core/src/main/scala/kafka/server/DelayedOperation.scala
  • 终于要揭开我们的谜之炼狱啦, 源码里的注释如下:

A helper purgatory class for bookkeeping delayed operations with a timeout, and expiring timed out operations

实际上就是用来通过TimerWatchers来管理一批延迟任务;

  • private[this] val timeoutTimer = new Timer(executor): 用来处理加入的作务的超时行为;
  • private val expirationReaper = new ExpiredOperationReaper():
private class ExpiredOperationReaper extends ShutdownableThread(
    "ExpirationReaper-%d".format(brokerId),
    false) {

    override def doWork() {
      timeoutTimer.advanceClock(200L)

      if (estimatedTotalOperations.get - delayed > purgeInterval) {
        estimatedTotalOperations.getAndSet(delayed)
        debug("Begin purging watch lists")
        val purged = allWatchers.map(_.purgeCompleted()).sum
        debug("Purged %d elements from watch lists.".format(purged))
      }
    }
  }
  1. timeoutTimer.advanceClock(200L): 驱动Timer向前走, pop出超时的延迟任务;
  2. val purged = allWatchers.map(_.purgeCompleted()).sum: 利用阈值(purgeInterval)来周期性地从Watchers中清理掉已经完成的任务;
  • def tryCompleteElseWatch(operation: T, watchKeys: Seq[Any]): Boolean: 将operation和一系列的事件(key)关联起来, 然后调用tryComplete尝试立即完成该操作,如果不能完成,加入到Timer中;

  • def checkAndComplete(key: Any): Int: 按key找到相应的Watchers对象, 然后调用其tryCompleteWatched(), 说明上面用;

简图:
DelayedOperation.png
基本上就是这些了

Kafka源码分析-汇总

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容