我的Kafka平凡之路
Posted 大数据Kafka技术分享
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了我的Kafka平凡之路相关的知识,希望对你有一定的参考价值。
不知不觉Kafka入门系列已经写到第11篇了。在这11篇入门文章中,关于Kafka的各种概念,组件,设计原理抑或是使用方法好似梅花间竹般地呈现给各位读者,也许给人有些许应接不暇之感。但是,今天我不打算去撰写任何的技术教程,只是单纯地回忆一下当初学习Kafka的经历,并希望我的这段经历可以给后面所有希望学习的朋友带来一些有益的思考。准备好了吗?我的Kafka平凡之路就是这样开始的。。。。
背景
记得那是3年前刚刚从IBM辞职跳槽去到公司S。对于只了解Oracle,IBM产品的我来说,互联网的一切于我都是懵懂的,不必说那些常见的互联网软件、架构,就是最简单的Maven我都从未用过。但现实从来都是残酷的,它不会给你时间让你去成长,它只会逼着你成长。就是在这样的背景下,我被分配到大数据组去参与研发我们的大数据实时处理平台,也正是在这个项目中我接触到了Kafka。其实最开始使用Kafka的时候,我并没有对它产生什么特别浓厚的兴趣,反而对于Storm的喜爱至今还令我印象深刻。和现在的流式处理框架的丰富程度相比,3年前的选择要少得多——要知道那个时候可没有现今如此多成熟的诸如Flink, Spark streaming(Spark是2014年3月才正式孵化成apache顶级项目)或是Beam这样的框架,于是该项目技术选型正式确立了Storm作为我们主要的流式数据处理平台。在项目开始的一段时间内,我怀着浓厚的兴趣开始了对于Storm源码的研究,但每每阅读Clojure编写的代码时,我总有这样的感慨:这是人能看懂的代码吗?!由于这种挫败的感觉日益强烈,我终于还是渐渐地放弃了对于Storm做深入研究的打算。
最正确的决定都是冲动之下做出的
某个午后,项目组中的某位工程师找到我身边的架构师:“咱们的Kafka集群日志中怎么区分业务方呢?”“根据client.id”架构师甚至没有多想一秒就脱口而出了这个答案。在那一刻,我震惊了! 虽然我早就知道这位架构师的基础非常好,但对于Kafka这次问题的解答实在太过酷炫。我清晰地记得就在那一瞬间,我暗自下定了决心:我一定也要成为这样的人,而且要做得比他还要好:我要钻研Kafka! Oh,my god,是的,就是这么个冲动的决定让我今天有了些资格写下这篇文章。时至今日我都无比庆幸那个午后做出的这个冲动决定。正如Adam Grant在《离经叛道》中所说:最正确的决定都是冲动之下做出的。诚不欺我!
Scala比Clojure 强不到哪去
想要深入钻研Kafka,不掌握Scala语言是不行的,毕竟Kafka就是使用Scala编写的。苦于当时没有合适的Scala中文书籍以及对于国内翻译质量的持续不信任,我只得自行下载了一本600多页的Scala原版书(Programming Scala Edition 2)进行学习。那真是一段难熬的岁月啊,不得不说,英文版纵然写得全面,但内容也确实是晦涩难懂,比如partially applied function和partial function的含义直至今天我都不是特别了解,还是要不断地翻阅资料才能依稀记得它们之间的区别。我很佩服自己当初坚持了下来了,600多页的英文文档我硬是啃下来了。对于Scala的初步掌握也让我觉得研究Kafka的时机到了。有意思的是,在之后通读Kafka的源码时我不禁大呼上当,Kafka代码中只使用了最简单的函数式编程, 后悔自己花了那么多的时间去学习Scala的FP编程,当然这是后话了。
钢笔墨水不够了
终于开始Kafka的学习了。当时我就笃定一定要读源码!毕竟不分析源码,很多问题你是搞不清楚的。记得那是元旦之后的某天,我对自己说我要花6个月的时间去通读Kafka的源码。其实说完这句话我就有点后悔了——因为长这么大,除了吃饭和睡觉之外好像还没有哪件事请能让我一直坚持6个月,但冲动之下做出的这个决定再一次被证明是正确的。我不但没有食言,还提前完成了任务。如果大家翻看我的博客一定可以看到那流水账一般的Kafka源码分析系列文章。但大家想不到的是,其实那些都是从我的手写阅读笔记中摘抄出来的。我家现在还放着我在读Kafka源码时手写的源码分析笔记,整整写满了一个笔记本。为此我还特意新买了2瓶英雄牌的墨水。细想来我读源码的方式真是low到家了,就是一行一行地写笔记。今天我再翻看这个笔记本时,还能看到当年写下的“val tp = TopicAndPartition(...) 就是构造一个TopicAndPartition对象”批注,唉,真是傻透了。不过就是靠着这么一行一行的傻文字,我发现自己慢慢开始理解Kafka源码了,也能够知道作者的意图以及每段代码实现的功能了。也是在那一刻,我突然发现,做这件事情好像还挺有成就感的。
二次回炉
随着在群里回答问题越来越手到擒来我逐渐停止了对于Kafka的学习,而此时我也跳槽到了下一家公司,一家与Kafka完全不搭边的公司。在那段时间内,我转去了Docker方面的研发,也逐渐淡出了Kafka群的讨论。半年之后当再次打开qq群时,我发现自己竟然已无法融入当初那得心应手的讨论之中了。这令我感到有一丝失落,我不想这么快就遗忘了自己曾经努力学到的东西,于是我再次打开了IDE开始了第二次Kafka源码之旅。又是一次痛苦的行程。。。随着新版本的不断更新以及新功能的加入,我需要学习的东西更多了。曾经逐行分析的producer被废弃了,新版本的consumer也出来了,甚至是服务器端底层的controller都重新设计了。。没办法,咬着牙继续一行一行地读着源代码。我仿佛单田芳口中的童林转大树一般,从刚开始的蒙头转向到后面的轻松自如,如今终于练就了“一看到错误基本上就能够定位到源文件”的本事。(好吧,如果您对本文的自吹自擂感到恶心,请于此处停止,因为后面可能更加严重:-)
加入社区
别看我研究了这么长时间的Kafka,加入到社区贡献代码以及帮助解决问题竟是最近的事情。我仍然记得当初发送邮件要求被加入到开发组时的惶恐,也记得第一次贡献代码时的那份惴惴不安;我记得为了研究某个Kafka issue曾忘记吃中饭的执着,也记得自己被标记为“Kafka contributor”时那一刻的喜悦。在混迹社区的日子里, 我逐渐地也认识了一些Kafka的committer们,比如Kafka Streams leader国璋兄(不是我非要套近乎,只是单纯地从长相上看他应该年长于我:-),他对于网上Kafka问题的权威解答令我受教良多,同时我也很感激他发出邀请请我去他们的公司共同参与Kafka的开发。还有Kafka的三个原作者之一Rao Jun,几次issue上的交流让我看到了这个原作者对于霸气的决断能力以及对于疑难问题原因的毒辣分析。当然还有非常敬业的Ijuma,他是我见过的最勤劳的Kafka committer了,没有之一。每当你不知道有谁能帮你review代码的时候,找他就对了。
结语
好了,说了这么多,绝对不是想吹嘘自己在Kafka方面有什么了不起的成就。我知道天外有天人外有人,自己要学习的东西太多太多。况且说出大天来,Kafka也不过是一软件而已,用它来定义事业成功不免显得格局太小。此时我只想送个大家一句话:聪明人要下死功夫。我已然不记得这是曾国藩说的还是季羡林说的,只是觉得,如果连我这么个不算太聪明的人都能取得这么一点点小小的成绩,那么诸位也一定取得更大的成功。
再次记住:聪明人要下死功夫! 与诸君共勉~~
以上是关于我的Kafka平凡之路的主要内容,如果未能解决你的问题,请参考以下文章