郑奇煌，目前就职于杭州某互联网风控公司。主要专注于大数据、流计算和中间件，他希望自己能在技术的道路上越走越远，用技术为社会创造价值和财富。
时常更新个人的博客（zqhxuyuan.github.io）,分享技术学习心得。
访谈实录：
怎么对Kafka产生兴趣的？
最早，我是通过Zhuang Xiaodan在Github上改造的
metaq
和Liu Ady的
jafka
才接触到Kafka的，但并没有就此开始做深入的研究。
我在工作当中的主要任务是大数据Spark的开发，一些流任务的处理会借用Kafka。因为业务主要使用了Scala语言开发，我就想着学习一个Scala相关的开源项目。对于我来说，Spark的一些概念很难，于是就选了Kafka作为研究对象，相对来说Kafka的概念还是比较容易理解的。
决定写《Kafka技术内幕》的原因是什么？
在学习了很多关于Kafka的优秀资料以后，比如
郭俊
和
李志涛
两位的博客，我想要更加深入地理解背后的技术原理，所以决定去研究源码。断断续续看了一个多月，画了很多图，就把学习笔记放在了博客上，从读者的留言反馈上看，效果还不错。也许是头脑一时发热也许是内心某种追求的激励，在2016年六七月份的时候，我联系了图灵的编辑王军花，表达了想要写书的意思。她还是很鼓励我写作的，认为这本书可以填补国内还没有出版过Kafka相关书籍的空白。当时，除了英文版的
Learning Kafka
之外，确实没有其他比较完整的资料了，所以这些更坚定了我写书的决心。
怎么定义“在技术上有追求的人”？在技术领域，你有哪些尊敬的人？
我觉得“对技术有追求的人”是能够利用技术为社会创造出价值和财富的人，他们推动着社会不断进步。相比这些人，我觉得自己目前还只是“码农”一枚，在精深技术的道路上还有走很长、很曲折的一段。就我所在的圈子来说，我比较崇（膜）拜Linux之父Linus和乔布斯这样的大神~
Kafka是一个什么样的工具？擅长做什么？
最开始的时候，Kafka的定位是一个消息中间件。你把消息放进去，然后另一个人从里面取出消息进行消费，甚至许多不同的人都可以取出相同的消息。Kafka主要擅长做消息生产和消费的解耦，即使消费者消费太慢了也不会影响到生产者。它的主要应用有日志收集、性能度量、网站监控等，比如把日志、性能信息等放入Kafka，再通过其他程序对数据进行分析。在最新的版本中，Kafka已经是一个成熟的流式数据处理平台了，并且也支持外部数据库导入导出到Kafka。
可以说，图解IT技术是《Kafka技术内幕》的一大特色。书中的图都是你自己绘制的吗？使用了哪些绘图工具？相比文字，绘图有哪些更高的要求？
书里面的图片有近400幅，全部是用Mac的Keynote做的。除了准确表达程序的执行步骤之外，图片能简明扼要地呈现。相比文字，用图片表达，比如不同组件之间的关联关系或是某一个变量存在的含义，更容易上读者理解接受。
听说你在写作过程中经历了重重的困难，三改稿件。跟我们分享下遇到的那些困难，以及不断修改稿件的原因？
第一稿的内容太多，代码和图片都过于详细，于是在第二稿的时候，我删掉了一些比较简单的代码和图片。删减工作并不是想象的那样简单，我必须增加过渡性的铺垫说明。另外，我是边研究源码边写作的，这虽然保证了准确性，却对写作有一定的牵制。有些源码理解起来比较困难，还得参考相关的测试用例，一点一点啃下官方的英文设计文档。有些地方会有理解不准确，就推翻重写。比如，在消费组的状态机这块，原先画的流程图太长，后来自己看起来都有困难，于是重新对这部分进行了拆解。
整体结构上，我一开始设计的顺序是生产者、Broker、消费者。原因是，介绍完Broker的数据结构，再理解消费者会比较简单。后来发现，把生产者和消费者作为客户端一起分析的话，组织结构会更好，我又把消费者移到了Broker前面。这么一调整，就要求对消费者中涉及的Broker知识提前做出简单介绍和修改。
另外，我是利用业余时间写作的，进度上确实有点慢。在这里，也对编辑的工作和耐心表示由衷的感谢，也对网络上一些网友的期待表示感谢，期望本书不会让你们失望。读者如果对本书有什么意见，都可以在图灵社区提出来。
你是一个“完美主义者”吗？认可某件事情的标准有哪些？
我觉得，既然选择了一件事情，就要弄懂它的所有细节，去深究它的实现原理。认可事情的话，我的理解是，你开发出来的某款软件用起来容易上手。当然这是相对的，你肯定要花时间去深入研究背后的技术，再困难的事情最终也一定都可以解决。
如何看待由代码堆叠而来的源码分析？
其实，有关源码分析的书籍最（被）忌（骂）代码太多。在《Kafka技术内幕》这本书里面，我已经尽量避免大段大段的代码，并且没有直接粘贴代码段的情况。我建议读者尽量打开IDE，跟随作者一起阅读源码，这种效果是最好的。
其实，我因为本书没有更多的实战部分，总觉得有很多遗憾。Linux OpenMessaging规范发起人冯嘉曾建议我在书里加上cruise-control、RocketMQ等内容，我也一开始就打算加上流处理框架与Kafka的整合，但因为书太厚了，只能忍痛割爱。如果再版的话，我会加进
相关的内容。
你曾经阅读过Hadoop、HBase、Storm等的源码，对源码研究有哪些体会？
最早，我是看蔡斌的《Hadoop技术内幕》入门大数据的，一边看书一边研究源码，还整理了八百多页的学习笔记。当时还兴冲冲地在微博上发布了#图说Hadoop源码#（现在链接失效了）的系列文章，作为粉丝的深夜福利（笑）。
分布式文件系统看完后，我结合《HBase权威指南》学习了分布式存储框架HBase(0.94)。接着，主要是结合hseagle和fxjwind两位的博客研究分布式计算Storm的源码。当然，这几个开源项目看到最后，有些部分是没有深入进去的，不过总的收获还是蛮大的。
研究源码的时候，我倾向先学习一些优秀的博客文章，然后结合自己的理解，总结成视觉型的流程图，还要写学习笔记。说来也巧，学习完这几个开源项目，我用到的画图工具一般都是系统自带的工具，比如Window的Office/PlantUML，Ubuntu的LibreOffice，GoogleDoc，Mac的Keynote。
另外，读源码难免会遇到一些难点，这时候可以参考测试用例。开源项目的测试用例一般都是很完整的。还要订阅官方的邮件，开发人员会很耐心并且及时地解答你的问题。我在测试Kafka Streams时遇到的一些问题，就是Kafka的开发人员帮忙解决的。
请介绍下Kafka的编译原理？
Kafka首先是一个分布式的消息队列，消息队列的客户端包括生产者和消费者。开发者使用Kafka非常简单，生产者发布消息到Kafka的某个主题，消费者从Kafka的指定主题获取消息并进行消费。消息队列的服务端则是由代理节点、控制器、ZooKeeper等组件构成的，服务端的代理节点是一个集群，它实现了消息队列的的负载均衡、故障容错、副本复制等功能。
Kafka还是一个流式数据处理平台（Kafka Streams），提供了一种轻量级的流计算解决方案，部署和使用都非常简单，直接启动一个普通的Java应用程序即可。消息进入Kafka后，应用程序利用这个轻量级的库通过流计算的算子，可以做到流式地、实时地消息处理。
除此之外，为了对接不同的数据源，Kafka还支持连接器（Kafka Connect）。这样，从数据源产生数据到Kafka、实时处理流式数据、结果数据同步到目标数据源，都是围绕着Kafka这个生态系统构建的，我们可以看到Kafka从消息队列到流式数据处理平台，是在一步步成长壮大的。
