原 Kafka解惑之Old Producer(4)——Case Analysishttps://blog.csdn.net/u013256816/article/details/79237769版权声明:本文为博主原创文章,未经博主朱小厮允许不得转载。 https://blog.csdn.net/u013256816/article/details/79237769
欢迎支持笔者新作:《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》,同时欢迎关注笔者的微信公众号:朱小厮的博客。
上接:
Kafka解惑之Old Producer(1)—— Beginning
Kafka解惑之Old Producer(2)——Sync Analysis
Kafka解惑之Old Producer(3)——Async Analysis
在前面三篇文章中详细了解了Old Producer的内容,本文主要通过一个实际应用案例来加深各位对Old Producer的理解。
问题描述:线上由多台Kafka Broker组成的集群(Producer的metadata.broker.list参数设置的是所有broker的地址+端口号的列表),版本号为0.8.2.x,当一台Kafka Broker的硬盘发生故障导致系统崩溃,由于Kafka的HA的作用线上业务无明显异常,发送方和消费方的流量也与之前持稳,但是后面监测到每隔10分钟左右就有少量的消息发送的时延很大,而且有ERROR告警报出。
2018-01-30 00:53:20 -[ERROR] - [fetching topic metadata for topics [Set(hidden-topic)] from broker [ArrayBuffer(id:0,host:xxx.xxx.xxx.xxx,port:9092)] failed] - [kafka.utils.Logging$$anonfun$swallowError$1:106]
kafka.common.KafkaException: fetching topic metadata for topics [Set(hidden-topic)] from broker [ArrayBuffer(id:0,host:xxx.xxx.xxx.xxx,port:9092)] failed
at kafka.client.ClientUtils$.fetchTopicMetadata(ClientUtils.scala:72)
at kafka.producer.BrokerPartitionInfo.updateInfo(BrokerPartitionInfo.scala:82)
at kafka.producer.async.DefaultEventHandler$$anonfun$handle$1.apply$mcV$sp(DefaultEventHandler.scala:67)
at kafka.utils.Utils$.swallow(Utils.scala:172)
at kafka.utils.Logging$class.swallowError(Logging.scala:106)
at kafka.utils.Utils$.swallowError(Utils.scala:45)
at kafka.producer.async.DefaultEventHandler.handle(DefaultEventHandler.scala:67)
at kafka.producer.Producer.send(Producer.scala:77)
at kafka.javaapi.producer.Producer.send(Producer.scala:33)通过上面的异常栈我们可以发现在获取元数据的时候(kafka.client.ClientUtils$.fetchTopicMetadata)发生了异常,其实如果你对Kafka的配置参数足够了解的话,看到10分钟这个数值就可以联想到600*1000的某个参数,也就是topic.metadata.refresh.interval.ms。在DefaultEventHandler的handle()方法中,在调用dispatchSerializedData()方法预处理并发送消息之前就会有下面的一个if判断语言用来判断当前是否需要更新元数据:
while (remainingRetries > 0 && outstandingProduceRequests.nonEmpty) {
topicMetadataToRefresh ++= outstandingProduceRequests.map(_.topic)
if (topicMetadataRefreshInterval >= 0 &&
Time.SYSTEM.milliseconds - lastTopicMetadataRefreshTime > topicMetadataRefreshInterval) {
CoreUtils.swallowError(brokerPartitionInfo.updateInfo(topicMetadataToRefresh.toSet, correlationId.getAndIncrement))
sendPartitionPerTopicCache.clear()
topicMetadataToRefresh.clear
lastTopicMetadataRefreshTime = Time.SYSTEM.milliseconds
}
outstandingProduceRequests = dispatchSerializedData(outstandingProduceRequests)
上面代码中的topicMetadataRefreshInterval指的就是topic.metadata.refresh.interval.ms参数。如果topic.metadata.refresh.interval.ms这个参数设置为0,那么就意味着每次发送消息之前都需要拉取并更新元数据信息,更新元数据信息之后还要更新ProducerPool的内容,包括重建SyncProducer,那么这一番操作必然会有一定的延迟,当然这个延迟没有本文中所述问题中的延迟那么大。如果topic.metadata.refresh.interval.ms这个参数设置为负数,那么这个if条件语句就不能成立,也就是不会有定时更新元数据的操作,只有在获取元数据信息失败是才会请求完整的元数据信息。
本文中所述问题中采用的topic.metadata.refresh.interval.ms参数设置的是默认值大小,那么问题中还有一个细节:只有少量消息发送超时。为了进一步的一探究竟,我们来继续深究。当定时更新元数据信息条件满足时,就会调用brokerPartitionInfo.updateInfo的方法,更进取之后,实际上内部调用的是:ClientUtils.fetchTopicMetadata(topics, brokers, producerConfig, correlationId)来请求元数据信息,并获得TopicMetadataResponse来做更新。
TopicMetadataResponse中包含有broker的id、host、port,还有topic、topic中的partition、partition所对应的leader、AR和ISR等等,有兴趣的同学可以进一步翻阅kafka.api.TopicMetadataResponse这个类,主体代码只有30行左右,只要学一点Scala的构造函数相关的只是就能看懂。
我们回过头来再来进一步分析ClientUtils.fetchTopicMetadata这个方法,详细代码如下:
def fetchTopicMetadata(topics: Set[String], brokers: Seq[BrokerEndPoint], producerConfig: ProducerConfig, correlationId: Int): TopicMetadataResponse = {
var fetchMetaDataSucceeded: Boolean = false
var i: Int = 0
val topicMetadataRequest = new TopicMetadataRequest(TopicMetadataRequest.CurrentVersion, correlationId, producerConfig.clientId, topics.toSeq)
var topicMetadataResponse: TopicMetadataResponse = null
var t: Throwable = null
// shuffle the list of brokers before sending metadata requests so that most requests don't get routed to the
// same broker
val shuffledBrokers = Random.shuffle(brokers)
while(i < shuffledBrokers.size && !fetchMetaDataSucceeded) {
val producer: SyncProducer = ProducerPool.createSyncProducer(producerConfig, shuffledBrokers(i))
info("Fetching metadata from broker %s with correlation id %d for %d topic(s) %s".format(shuffledBrokers(i), correlationId, topics.size, topics))
try {
topicMetadataResponse = producer.send(topicMetadataRequest)
fetchMetaDataSucceeded = true
}
catch {
case e: Throwable =>
warn("Fetching topic metadata with correlation id %d for topics [%s] from broker [%s] failed"
.format(correlationId, topics, shuffledBrokers(i).toString), e)
t = e
} finally {
i = i + 1
producer.close()
}
}
if(!fetchMetaDataSucceeded) {
throw new KafkaException("fetching topic metadata for topics [%s] from broker [%s] failed".format(topics, shuffledBrokers), t)
} else {
debug("Successfully fetched metadata for %d topic(s) %s".format(topics.size, topics))
}
topicMetadataResponse
}
fetchTopicMetadata方法参数列表中brokers代表metadata.broker.list所配置的地址列表。可以看到方法中首先建立TopicMetadataRequest的请求,然后从brokers中随机挑选(做一个shuffle,然后从列表中的第一个开始取,也就是相当于随机)一个broker建立SyncProducer并发送TopicMetadataRequest请求,问题的关键就在这个随机挑选一个broker之上,如果正好随机到的是那台磁盘损毁而崩溃的机器,那么这个请求必定要等到设定的超时时间之后才能捕获异常:[ERROR] - [fetching topic metadata for topics [Set(hidden-topic)] from broker [ArrayBuffer(id:0,host:xxx.xxx.xxx.xxx,port:9092)] failed] ,进而再找到下一个broker重新发送TopicMetadataRequest请求。
上面提到了超时时间,这个超时时间是通过request.timeout.ms参数设定的,默认值为10000,也就是10s。具体指的是kafka.network.BlockingChannel中的channel.socket.connect(new InetSocketAddress(host, port), connectTimeoutMs)这段代码,参数connectTimeoutMs就是指request.timeout.ms。如果元数据的请求时打到那台崩溃的broker上的话,那么元数据的请求就要耗时10s以上,待元数据刷新后才能发送消息。这个request.timeout.ms参数才是导致文中开头有少量消息发送时延很大的原因。为了进一步验证结论是否正确,笔者将相关的类SyncProducer、BlockingChannel用Java重写了一遍,并测试出请求的耗时,当访问一个不存在的ip地址时,从发送请求到异常报出的耗时在10194ms。不过如果访问一个存在的ip地址时,但是没有kafka服务的话,从发送请求到返回的耗时只有1248ms,基本上减少了一个数量级,如果读者在遇到同样的问题时,不妨上线一台(随意一台能建立TCP连接的机器就好)与崩溃宕机的那台broker一样的ip地址的机器,上面无需运行kafka的服务,就能大大的降低发送消息的时延。这样可以流出更多的时间去定位、修复、重新上线那台崩溃的broker。
当然如果对时延过敏,还有一些其它的方法可以参考。比如metadata.broker.list配置的是一个类似虚IP(VIP)的话,可以在VIP的下游剔除掉这台broker,让VIP过来的请求不会落到崩溃的broker上。或者也可以通过topic.metadata.refresh.interval.ms参数来调节,比如设置为负数就可以免去定时刷新元数据的烦恼,不过在元数据变动的时候很难有效的感知其变化,通过定时重连之类的方法又显得有点奇葩。当然直接上线一台服务器,安装运行kafka服务,且设置这台kafka服务器的ip为崩溃的那台服务器的ip地址,不过这番操作比直接拉一台空机器的时效性要低一些,凡事在于抉择。
Old Producer拉取元数据信息以及发送消息是在同一个线程中的,这必然会引起局部消息的时延增大。不过在新版的KafkaProducer中,这些问题都已经迎刃而解,具体怎么处理,且看后面的文章分析。
欢迎支持笔者新作:《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》,同时欢迎关注笔者的微信公众号:朱小厮的博客。