Kafka是如何处理客户端发送的数据的?

96
扫帚的影子
2017.09.04 23:25* 字数 1335

  • 客户端的ProduceRequest如何被Kafka服务端接收?又是如何处理? 消息是如何同步到复本节点的? 本篇文章都会讲到, 实际上就是综合运用了上面第三点中的内容
  • 上一节我们讲到所有的Request最终都会进入到KafkaApis::handle方法后根据requestId作分流处理, ProduceRequest也不例外;

Topic的Leader和Follower角色的创建

  • 之前在ReplicaManager源码解析2-LeaderAndIsr 请求响应中留了个尾巴,现在补上;
  • 通过Kafka集群建立过程分析我们知道,Kafkaf集群的Controller角色会监听zk上/brokers/topics节点的变化,当有新的topic信息被写入后,Controller开始处理新topic的创建工作;
  • Controller 使用Partition状态机Replica状态机来选出新topic的各个partiton的主,isr列表等信息;
  • Controller 将新topic的元信息通知给集群中所有的broker, 更新每台borker的Metadata cache;
  • Controller 将新topic的每个partiton的leader, isr , replica list信息通过LeaderAndIsr Request发送到对应的broker上;
  • ReplicaManager::becomeLeaderOrFollower 最终会处理Leader或Follower角色的创建或转换;
  • Leader角色的创建或转换:
    1. 停掉partition对应的复本同步线程; replicaFetcherManager.removeFetcherForPartitions(partitionState.keySet.map(new TopicAndPartition(_)))
    2. 将相应的partition转换成Leader
      partition.makeLeader(controllerId, partitionStateInfo, correlationId),其中最重要的是leaderReplica.convertHWToLocalOffsetMetadata(), 在Leader replica上生成新的high watermark;
  • Follower角色的创建或转换:
    1. 将相应的partition转换成Follower
      partition.makeFollower(controllerId, partitionStateInfo, correlationId)
    2. 停掉已存在的复本同步线程
      replicaFetcherManager.removeFetcherForPartitions(partitionsToMakeFollower.map(new TopicAndPartition(_)))
    3. 截断Log到当前Replica的high watermark
      logManager.truncateTo(partitionsToMakeFollower.map(partition => (new TopicAndPartition(partition), partition.getOrCreateReplica().highWatermark.messageOffset)).toMap)
    4. 重新开启当前有效复本的同步线程
      replicaFetcherManager.addFetcherForPartitions(partitionsToMakeFollowerWithLeaderAndOffset), 同步线程会不停发送FetchRequest到Leader来拉取新的消息

客户端消息的写入

  • kafka客户端的ProduceRequest只能发送给Topic的某一partition的Leader
  • ProduceRequest在Leader broker上的处理 KafkaApis::handleProducerRequest
    1. 使用authorizer先判断是否有未验证的RequestInfo
      val (authorizedRequestInfo, unauthorizedRequestInfo) = produceRequest.data.partition { case (topicAndPartition, _) => authorize(request.session, Write, new Resource(Topic, topicAndPartition.topic)) }
    2. 如果RequestInfo都是未验证的,则不会处理请求中的数据
      sendResponseCallback(Map.empty)
    3. 否则, 调用replicaManager来处理消息的写入;
    4. 流程图:
handlerequest.png
  • Leader通过调用ReplicaManager::appendMessages,将消息写入本地log文件(虽写入了log文件,但只是更新了LogEndOffset, 还并未更新HighWaterMark, 因此consumer此时无法消费到),同时根据客户端所使用的ack策略来等待写入复本;

    1. 等待复本同步的反馈,利用了延迟任务的方式,其具体实现可参考DelayedOperationPurgatory--谜之炼狱,
      val delayedProduce = new DelayedProduce(timeout, produceMetadata, this, responseCallback)
    2. 尝试是否可以立即完成上面1中的延迟任务,如果不行才将其加入到 delayedProducePurgatory中,
      delayedProducePurgatory.tryCompleteElseWatch(delayedProduce, producerRequestKeys)
    3. 当这个Partition在本地的isr中的replica的LEO都更新到大于等于Leader的LOE时,leader的HighWaterMark会被更新,此地对应的delayedProduce完成,对发送消息的客户端回response, 表明消息写入成功(这个下一小节后细说);
    4. 如果在delayedProduce没有正常完成前,其超时了,对发送消息的客户端回response, 表明消息写入失败;
  • Partition在本地的isr中的replica的LEO如何更新呢?

    1. 前面说过Follower在成为Follower的同时会开启ReplicaFetcherThread,通过向Leader发送FetchRequest请求来不断地从Leader来拉取同步最新数据, ReplicaManager::fetchMessage处理FetchRequest请求,从本地log文件中读取需要同步的数据,然后更新本地对应的Replica的LogEndOffset, 同时如果所有isr中的最小的LogEndOffset都已经大于当前Leader的HighWaterMark了, 那么Leader的HighWaterMark就可以更新了, 同时调用ReplicaManager::tryCompleteDelayedProduce(new TopicPartitionOperationKey(topicAndPartition))来完成对客户端发送消息的回应.
    2. 从上面的1中我们看到实际上发送FetchRequest的replica还未收到Response,这个Leader的HighWaterMark可能已经就更新了;
  • 对于Replica的FetchRequest的回应

    1. ReplicaManager::fetchMessage, 调用readFromLocalLog从本地log中读取消息后,先判断是否可以立即发送FetchRequest的response:
      if(timeout <= 0 || fetchInfo.size <= 0 || bytesReadable >= fetchMinBytes || errorReadingData)

    // respond immediately if
    // 1) fetch request does not want to wait
    // 2) fetch request does not require any data
    // 3) has enough data to respond
    // 4) some error happens while reading data

    1. 如查不能立即发送, 需要构造DelayedFetch来延迟发送FetchRequest的response,
      这可能是FetchRequset中所请求的Offset, FileSize在当前的Leader上还不能满足,需要等待; 当Replica::appendToLocaLog来处理ProduceRequest请求是会尝试完成此DelayedFetch;
Kafka源码分析-汇总
Kafka
Web note ad 1