PDF《Kafka在LinkedIn公司的使用及维护实战》

Kafka在LinkedIn公司的使用及维护实战 Apache Kafka在LinkedIn和其他公司中是作为各种数据管道和异步消息的后端.

Netflix和Mi crosoft公司作为Kafka的重量级使用者(Four Comma Club,每天万亿级别的消息量),他们在Kafka Summit的分享也让人受益良多. 虽然Kafka有着极其稳定的架构,但是在每天万亿级别消息量的大规模下也会偶尔出现有趣 的bug.在本篇文章以及以后的几篇文章中会深度的分析过去几年在LinkedIn所遭遇的重大"危机 故障".在这里阐述Kafka的"重大"bug产生的根本原因(多种bug、不正常的客户端行为和监控不 当多种因素相互作用导致的)是"后见之明"(有点像"马后炮"的意思),但分享出来可以给广大同 仁以借鉴.本文将讲述如何探测、研究和修复这些问题,并总结出Kafka的一些特色以供将来消除 或者减缓类似的bug. Offset Rewinds Kafka的broker分配到每条消息的偏移量都是单调增加的,它会追加到每个topic的分区日志 .Kafka的consumer分发消费任务("fetch"请求)时会指定从哪个偏移位置(offset)开始消费. 当一个"fetch"请求所指的偏移量(offset)越界,将会收到OffsetOutOfRange错误回复.然后,c onsumer根据auto.offset.reset配置参数自动把偏移量重置为最小偏有效移量(the earliest valid offset)或者最新有效偏移量(the latest valid offset),见下图所标示.这种偏移量的重置对线 上应用有重大影响――重置为最小偏移量会引起重复消费数据;

重置为最新偏移量意味着有丢失 消息数据的潜在可能(偏移量重置到下次"fetch"请求之间到达到消息). Kafka的consumer会周期性地checkpoint每个topic分区消费者的偏移量(i.e. 位置信息). 当consumer因某种情况重启后,consumer能从最后一次checkpoint重新消费.比如,如果cons umer失败了,consumer会从最近一次checkpoint重新消费;

或者如果更多的分区加入到topic, 跨消费实例的分区分布发生变化,这时consumer也会从最近一次checkpoint重新消费.在Kafka 0.8.2中引入consumer的偏移量管理(offset management).早在2015年早期,Kafka的consu mer偏移量管理仍然还是个新功能,而且作者也会偶尔出现偏移量重置的现象.解决这个难题是 比较棘手的,也从而导致其他bug的修复,包含偏移量管理、日志压缩和监控. 如何发现Offset Rewinds Kafka的broker并未维护客户端的错误度量(比如,offset reset),但是有几个指标会出现 ,比如,当consumer失败后重置为最小偏移量时会有偏移量"倒回".服务端最明显的指标是:消1/7息输出量非常大,而相应的输入量并未增加,如下图所示: 客户端最明显的指标是consumer延迟突然增加,在这个故障中,作者注意到Kafka跨集群同 步(mirror maker,是Kafka内置的跨集群同步工具)延迟监控上出现"毛刺". 延迟监控有点棘手,因为并不是所有的延迟"毛刺"都会引起警报.延迟趋势监控是相当重要的, 你可以使用LinkedIn提供的延迟监控服务Burrow(Kafka消费延迟监测). 第一次"危机故障" CRT (Change Request Tracker)[]是LinkedIn持续集成发布平台,用来监控构建和发布服务 ,并发出邮件.在七月初,许多开发者(包括作者在内)反应收到重复的CRT邮件.与之相关的 原因是包含发布事件的Kafka topic复制管道出现偏移量重置. 偏移量重置(offset reset)的一个典型的原因是未知的leader选举.当一个分区的leader br oker失败,而其它复制副本也并未跟上,那就会发生这种情况.一个未同步的复制不得不接管lea der,同时导致日志截断.这意味着,正在读取日志尾部的consumer发生突然越界的错误.最好 的做法是监控集群的未知leader选举率.但是在七月份这次故障中并未看到任何未知leader选举 .