[大数据]kafka论文解读对话

1. 你为什么要阅读kafka论文呢？

答：因为这个工具很流行，无处不在。

2. 论文网址在哪?

答：论文网址在这里 http://notes.stephenholiday.com/Kafka.pdf

3. 论文重点是哪一章？

答：第三部分。也就是描述整体设计那一部分。

4. 论文篇幅有多长？

答： 7页纸，而第3部分只有3页纸。个人以为是论文的核心。

5. 第三部分大致讲了哪几点呢？

答： 3.1 单broker的单分区的结构和设计思路，如何保证分区读写的高效率，3.2 消费者和生产者如何和多个broker交互，broker如何分发消息，3.3， 如何保证消息不丢失，也即是可靠性保证的设计。

5.1 看的人晕头转向的？

答：先说几个概念吧，broker，partition，topic， consumer，producer。 所谓的broker就是kafka的核心组成部分，kafka就是broker，topic就是主题，就是频道，就是一组消息的唯一ID，可以认为是分组的概念，consumer就是消息消费者，需要消息的地方， produer就是发消息的。
再说一个大的概念吧，消息，什么是消息？可以这么说，一条日志，一个可以被描述的、含有主谓宾的任何信息都是消息，因为可以被延迟执行，所以有了一个大缓存，这个大缓存很可靠，它可以保留消息很久而不丢失，这个大缓存既能处理实时消息，也能存储大规模的对实时性要求不高的消息，因为它的设计很好，它处理消息很高效，又安全，所以它啥场景都基本能对付，这么一个大缓存就是kafka。

6. kafka这个名字怎么来的？

答：kafka听上去像一个科学家的名字是吧？这个消息队列是LinkedIn内部开发的，然后开源了出来，鬼知道为什么叫kafka，也许是为了纪念某个人，也许是开发者乱想的，反正它让中国人听起来怪怪的。

7. 请回到主题上面来，请问kafka的核心部分都讲了什么？

答：核心部分正如我上面所说，分为三部分，分别是3.1单partition的设计，3.2 系统内部交互设计，3.3可靠性保证。他们三部分篇幅不一样，其中3.1和3.2占了第三部分篇幅的80%，而3.3则很短，我先从短的部分说起，这样先拿下一分先。

8. 那么请问kafka是如何保证可靠性的？

答：在原始论文中，提到了两个概念，“精确的一次发送消息”和“至少一次发送消息”。前者如何做到的呢？肯定我发送给你，你回复我一下，咱们就达成一致，确定我把这个消息送到了，这是可靠性保证。至少一次发送消息就是说，我发给你了，但是可能多次发给你，因为我不确定是否发给你了，就好比你吃药，你忘记是否吃药了，你不记得自己吃一次还是没吃，那么你就再吃一次。这个例子不是很准确，但是确实是这样的。kafka说，请你自己确保你只吃了一次，我可以把药无限次的给你。这和kafka的消息传输机制有关，我待会会讲，这样的设计是考虑到性价比的问题。

8.1 如果kafka消息保存到硬盘上出错了怎么办？

答：问得好，我还没说完。kafka自有办法，它使用了CRC机制。那么你又要问什么是CRC了，在这里，科普一下，如果你学过计算机网络，你可以知道字节传输的时候，01可能会发生变形，0变成1，1变成0，是小概率事件，但是会发生，因此有这么一个检测算法，也就是CRC，具体的思路不讲了，可以简单看看百度百科学习一下， https://baike.baidu.com/item/CRC/1453359 ，所以kafka保证了它自身把消息写到硬盘上的时候，有检查机制。

8.2 我有一个问题想问，kafka发送消息严格保证顺序吗？

答：kafka把消息分组成topic，topic又分成partition，为了并发嘛！同一个partition内部的消息是严格按照顺序发送的，但是不同partition之间是没法保证的。这得要应用自己保证。

8.3 等一下，我还想问一下，如果一个kafka机器崩溃了，消息是不是丢失了啊？

答：你是不是想说kafka有没有类似于 GFS之类的机制。遗憾的告诉你，论文里没有说它有冗余备份机制，但是既然作者把设计思路都说了，你应该可以自己实现一下不是吗？

9 那么请你接下来讲一讲一个partition的内部结构？

答：好的。partition 的设计至关重要。kafka首先有topic的概念，一个producer想发布消息，则开辟一个topic，那么为什么有partition的概念呢？一个topic代表的消息可能太多了，所以要存放起来不方便，于是拆分成 partition 分在不同的机器上存放。一个partition，是一个逻辑意义上的日志？（论文里没搞明白为什么这么说。懂的同学请告知一下），partition的体积会越来越大，然后会拆分成一个一个固定体积大小的文件放在硬盘上，比如这个体积是 1GB,这个固定大小的文件，我们管它叫 segement，也就是段。 kafka中的消息是没有一个明确的ID来标识的，而是靠它在这个partition中的逻辑偏移量，什么是逻辑偏移量？假如一个消息第一个放在这个partition中，长度为100Bytes，那么他的逻辑偏移量就是0，第二个消息再放进来，它的逻辑偏移量就是100。也就是说，kafka只能是顺序获取消息，不能随机访问消息。

9.1 举一个例子吧，如果一个请求过来，想找某个partition内部的偏移量为10000的，长度1000KB的消息，那么kafka会怎么做?

答：因为它的消息是不断增加的，所以它会把消息切成很多segement，然后它会在内存中有一个数据结构，类似于一个数组，记录每个segment内部的最开始的消息偏移量。 请求过来，它就会查当前最后一个小于10000的segement，然后从里面取出数据，发送给请求方。

9.2 我问累了，你随便说点什么吧。

答：我也有点疲惫了。说点轻松的吧，关于kafka如何进行高效传输的。

9.3 kafka是如何做到高效传输的呢？

答：答案就是一次多传点。一个传它几十个消息。打个比方，你要去买东西，你会攒几天再去一次超市，而不是每次想买什么就赶紧跑去买对吧，kafka也是这样做的，尽量一次多传多条消息过去。咱刚说了，kafka是一个大缓存，消费是主动拉消息的，生产者是主动推消息的，kafka就是一个消息中转站，生产者和消费者都尽量一次多推和拉消息。

9.4 你说的这个也是平平无奇啊！这个道理赞都懂，需要你讲吗？

答：确实，简单的道理大家都懂，所以也没什么好说的。那我就讲一下kafka不一样的地方吧。

9.5 你说?

答：kafka 自身不设计缓存。一般的应用为了高效的读写，都会设计一个应用内的缓存。经典的比如某些日志库啊，它为了高效的写日志，不会每次生产出一条日志都去写一次磁盘，它会设计一个缓存，等写了很多日志，它才把内容写到磁盘上去。 kafka反其道而行之。按理来说，kafka作为一个大缓存，它有一个应用场景是这样的，很多消费者订阅同一个消息，每个消息他们都要有一份，那么是不是说可以在kafka内部开一个缓存呢？kafka说，不用，我们就用操作系统内部的页缓存就行了，实践证明，kafka使用操作系统缓存确实效果还行，免去了自己再搞一个缓存，节省内存，而且因为kafka纯粹是一个消息分发的东西，它没有复杂的逻辑，基本上消息都是整页整页的直接使用操作系统的内存，所以它不用单独再设计一个缓存。它在论文中是刻意这么强调了的。

9.6 kafka的意思是，其实应用级缓存是个多余的东西？

答：照它的意思，是这样的。

9.7 那么是不是其他的应用也不需要设计应用级缓存，就直接可以用操作系统缓存呢？

答：不可。具体问题具体分析。kafka读取消息都是大块内存读取的，刚好契合操作系统页内存，而且它是线性连续读取的，有的应用的缓存是随机读取的，而且缓存的内容体积各异，有的内容就几个字节，必须得缓存了。

9.8 所以说kafka故意不用应用级缓存是很高明了？

答：能不人云亦云，而且确实有效，怎么能不说是高明呢？

9.9 kafka还有什么高效传输的秘密吗？

答：kafka充分利用了Linux操作系统的一个系统接口，这个接口叫 sendfile，它可以直接把一个硬盘文件加载到 file channnel 的东西里，然后直接把file channel的内容写到一个 socket 文件里面去，也就是说，它充分利用了操作系统内部提供的高性能接口，而免去了在内存中拷贝字节的过程。我们设计底层应用，自然要关注操作系统提供的福利，跟上操作系统进步的步伐，才不至于掉队啊。

9.10 我还看到kafka 是一个无状态的服务？

答：是的，stateless，这个词我们很熟悉了。在 http 设计的时候，我们就知道，http 最亮点的设计就是无状态。http本身没有状态，如何记录状态交给上层的应用本身去做。在很多网站交互中，我们必须知道用户是否登录，这个时候，聪明的IT工程师在无状态的http服务上设计出 cookie和session的概念，证明了无状态的底层服务其实是没啥问题的，设计简单的，可操作的。http 的无状态大放异彩，kafka这个学生也不笨。kafka的设计思路，是把所有的消息都存起来，当然不是存到天荒地老，存个7天以内的消息，然后通过一种机制让消费者保存消费偏移即可，从而实现了记忆消费到哪里。

请我们记住，无状态设计，这个在系统架构级别设计的理念，会时不时的碰到。

10 你刚才讲了3.1的内容，请继续讲3.2的内容吧！

答：好的。3.2讲了kafka和 消费者，生产者之间如何交互的，这个是一个非常精彩的部分，弄懂了基本上kafka就没有什么秘密了。

10.1 那请开始吧！

答：这部分大概讲了 zookeeper，kafka，生产者，消费者。各个实体之间是如何交互的。以及partition和topic的关系，如果围绕着 partition 进行操作的。

10.2 partition和topic的关系是什么？

答：我在上面说，topic的消息会越来越大，一台机器可能会存不下，于是拆分成多个partition存放。那么是不是说，一个topic拆分成多个partition是为了方便存放呢？这里我也不是很清楚。论文里并没有清楚的描述出来。但是它说，一个生产者可以自己选择往哪个partition里写，什么意思呢？如果一个topic有多个partition，那么每个partition都可以接受写入，每个partition之间是没有先后顺序的，也就是说，partition之间是平等的，不是追加写入的。甚至可以这么理解，partition是子topic,是更小的粒度划分。
再说了个通俗易懂的例子吧，topic是一家连锁酒店，partition是很多分店，你想住哪家分店住哪家，但总归你是住进了他家的酒店，就好比一个consumer订阅了一个topic，你是这家酒店的顾客就完了。

10.3 什么是 消费者组？

答：customer group，翻译过来是消费者组。作为消息组的 topic，可以理解，那么消费者组又是什么呢？他存在的意义是什么？我认为论文这块没有讲清楚，实在是太单薄了，后续还需要继续学习一下。

10.4 kafka为什么要使用zookeeper?

答：kafka是一个没有master节点的系统。它说，有master节点就要考虑master节点的容灾，不错。提出一个解决方案就必要提出解决方案本身的问题，然后再去解决解决方案引出的问题，形成一个套娃过程。所以，要master节点是干什么用呢，如果没有master节点，又该如何实现类似的功能呢？其实master节点的作用就是保存元信息，在这里，zookeeper，一个雅虎开源的协作和同步系统，实际上在kafka里扮演了master的角色。kafka的意思是，我是没有中心节点的，其实意思是说，我自己不设计中心节点，我用zookeeper做中心节点。无主设计真的无主吗？其实是相对的，是一种说法而已。

10.5 zookeeper，是怎么在kafka中扮演角色的？

答：zookeeper，动物园管理员，这个名字源于很多大数据的项目都喜欢用动物起名字，于是雅虎内部开发这个系统的时候说，我们该叫什么名字呢？不如就叫动物园管理员吧，我们管理这些动物（项目），一个非常自信和基础的服务。zookeeper怎没用，我这里不细说了，下期有空写关于读zookeeper论文的一些分享。

10.6 请详细讲一下zookeeper都用来干什么吧？

答：zookeepr的作用是：1.监听kafka节点也就是broker的数量， consumer的数量变化， 2. 当数量变化的时候触发负载均衡，3.记录消费者订阅的partition和消费偏移。

每一台机器，包括consumer和broker启动的时候，都要去zookeeper上登记。 broker 登记留下的信息是，它的IP地址和端口号，哪些topic的partition存放在它上面，消费者登记的信息包括，它属于哪个组，它订阅了哪些消息。而consumer group，消费者组作为一个实体也在 zookeeper上 留下了一条登记信息，它所包括的内容有，组内订阅的partition，这个partition的消费偏移。
除了partition的消费便宜是永久保存的之外，其他所有的登记信息都是临时的，会随着它关联的实体的下线而消失。

10.7 论文中大段描述了如何进行负载均衡的，你可以讲一下吗？

答：这块花了我很长的时间，我希望这块可以认真分享一下。想要说清楚所谓的负载均衡，我们必须搞清楚 consumer group ，topic， partition 之间的关系。
首先回答一下 刚才上面的一个疑问，为啥要有consumer group这个东西，consumer group 肯定是一组相似的 consumer 组成的。
然后又有一个设计原则，不同的 partition 只能被一个组内的一个 consumer 所拥有，也就是消费。 partition 是用来给 topic进行负载均衡用的，为了提高topic的并发量，所以要给 topic 下设置很多的 partition。然后一个topic被很多个consumer同时订阅，所以我们会把这个topic下的 partition 一对一的分配给这些个 consumer。我打个比方吧，加入有一地方，这个地方有男有女，我们会给一个男子分配一个女子，这样他们就组成了一对，一个男子不能同时和多个女子保持关系，反之同理。放在这个地方，一个 topic就是一个地方，一个 partition就是一个男或者女，一个consumer就是另外一个性别，爱怎么安排怎么安排吧，一个consumer group 就是一堆待分配的单身集合，反正就是这么一个逐一匹配的道理。每当有不同的 consumer加入或者 broker 加入的时候，数量就会不平衡，那么就会引发新一轮的重新分配的过程。

回到正题，因为网络存在延迟， 一个consumer可能会去消费一个被其他consumer拥有的 partition，那么基于抢占允许的原则，前一个consumer放弃它所拥有的所有 partition, 相当于重置，然后重新加入这个 consumer group,进行新的负载均衡的步骤。

10.8 基于zookeeper的kafka结点之间是如何交互的呢？还需要补充吗？

答：基本上， kafka结点的交互是围绕着zookeeper这个元数据存储工具来展开的，他们的交互是清楚的，简单的。
论文上基本就说了这些内容，没有什么好补充的了。

11 关于kafka你还要说什么？

答：简介的设计才是王道，kafka体现出来了。它实现了个消息队列，可以支持实时低延迟需求，同时它也支持那种批量的数据密集型的任务，得益于它简洁的设计和对性能的追求，kafka成为了最流行的消息队列。我们应该努力学习这种设计思路。kafka的成功还在于它的专注，我们可以看论文第二部分,传统消息队列的问题，就在于什么都想干，什么都未必干得好的事，比较紧的耦合吧，kafka没什么负担。

12 还有吗？

答：没有了，论文呢的解读就到了这里了，希望下次可以继续解读优秀的系统设计论文。下次准备解读 zookeeper，bigtable，raft 等等。

13 等一下，关请问阅读论文过程中，有什么技巧吗？阅读完论文又怎能怎么样呢？

答：技巧就是，硬啃，提高英语水平，合理跳过看不懂的地方，回头再解决疑难问题。论文中总有疏漏，总有讲不清的地方，这个习惯就好了。 读完论文啥都不能干，除非你去阅读一个kafka的源代码实现，对了，kafka本身有几个缺陷待完善，有兴趣可以看每个公司内部的实现源码，应该也是很有趣和挑战的。
学习终归是为了增长知识和应用到实践中，希望可以在实践中去验证这些知识。