共计 3848 个字符，预计需要花费 10 分钟才能阅读完成。
本文首发于公众号：五分钟学大数据
在面试的时候，发现很多面试官特地爱问 Kafka 相干的问题，这也不难理解，谁让 Kafka 是大数据畛域中音讯队列的 惟一王者，单机十万级别的吞吐量，毫秒级别的提早，这种天生的分布式音讯队列，谁能不爱？
在最近的一场面试中，有个面试官看到简历中的我的项目上写 Kafka 了，就间接开问 Kafka，其余问题根本没问。上面来看下面试官的 Kafka 八连问：
（以下答案是面试完之后整顿而成，理论面试时只答复了大概三分之一）
1. 为什么要应用 kafka？
- 缓冲和削峰：上游数据时有突发流量，上游可能扛不住，或者上游没有足够多的机器来保障冗余，kafka 在两头能够起到一个缓冲的作用，把音讯暂存在 kafka 中，上游服务就能够依照本人的节奏进行缓缓解决。
- 解耦和扩展性：我的项目开始的时候，并不能确定具体需要。音讯队列能够作为一个接口层，解耦重要的业务流程。只须要恪守约定，针对数据编程即可获取扩大能力。
- 冗余：能够采纳一对多的形式，一个生产者公布音讯，能够被多个订阅 topic 的服务生产到，供多个毫无关联的业务应用。
- 健壮性：音讯队列能够沉积申请，所以生产端业务即便短时间死掉，也不会影响次要业务的失常进行。
- 异步通信：很多时候，用户不想也不须要立刻解决音讯。音讯队列提供了异步解决机制，容许用户把一个音讯放入队列，但并不立刻解决它。想向队列中放入多少音讯就放多少，而后在须要的时候再去解决它们。
2. Kafka 生产过的音讯如何再生产？
kafka 生产音讯的 offset 是定义在 zookeeper 中的，如果想反复生产 kafka 的音讯，能够在 redis 中本人记录 offset 的 checkpoint 点（n 个），当想反复生产音讯时，通过读取 redis 中的 checkpoint 点进行 zookeeper 的 offset 重设，这样就能够达到反复生产音讯的目标了
3. kafka 的数据是放在磁盘上还是内存上，为什么速度会快？
kafka 应用的是磁盘存储。
速度快是因为：
- 程序写入：因为硬盘是机械构造，每次读写都会寻址 -> 写入，其中寻址是一个“机械动作”，它是耗时的。所以硬盘“厌恶”随机 I /O，喜爱程序 I /O。为了进步读写硬盘的速度，Kafka 就是应用程序 I /O。
- Memory Mapped Files（内存映射文件）：64 位操作系统中个别能够示意 20G 的数据文件，它的工作原理是间接利用操作系统的 Page 来实现文件到物理内存的间接映射。实现映射之后你对物理内存的操作会被同步到硬盘上。
- Kafka 高效文件存储设计：Kafka 把 topic 中一个 parition 大文件分成多个小文件段，通过多个小文件段，就容易定期革除或删除曾经生产完文件，缩小磁盘占用。通过索引信息能够疾速定位
message 和确定 response 的 大 小。通过 index 元数据全副映射到 memory（内存映射文件），
能够防止 segment file 的 IO 磁盘操作。通过索引文件稠密存储，能够大幅升高 index 文件元数据占用空间大小。
注：
- Kafka 解决查问效率的伎俩之一是将数据文件分段，比方有 100 条 Message，它们的 offset 是从 0 到 99。假如将数据文件分成 5 段，第一段为 0 -19，第二段为 20-39，以此类推，每段放在一个独自的数据文件外面，数据文件以该段中 小的 offset 命名。这样在查找指定 offset 的
Message 的时候，用二分查找就能够定位到该 Message 在哪个段中。
- 为数据文件建 索引数据文件分段 使得能够在一个较小的数据文件中查找对应 offset 的 Message 了，然而这仍然须要程序扫描能力找到对应 offset 的 Message。
为了进一步提高查找的效率，Kafka 为每个分段后的数据文件建设了索引文件，文件名与数据文件的名字是一样的，只是文件扩大名为.index。
4. Kafka 数据怎么保障不失落？
分三个点说，一个是生产者端，一个消费者端，一个 broker 端。
- 生产者数据的不失落
kafka 的 ack 机制：在 kafka 发送数据的时候，每次发送音讯都会有一个确认反馈机制，确保音讯失常的可能被收到，其中状态有 0，1，-1。
如果是同步模式：
ack 设置为 0，危险很大，个别不倡议设置为 0。即便设置为 1，也会随着 leader 宕机失落数据。所以如果要严格保障生产端数据不失落，可设置为 -1。
如果是异步模式：
也会思考 ack 的状态，除此之外，异步模式下的有个 buffer，通过 buffer 来进行控制数据的发送，有两个值来进行管制，工夫阈值与音讯的数量阈值，如果 buffer 满了数据还没有发送进来，有个选项是配置是否立刻清空 buffer。能够设置为 -1，永恒阻塞，也就数据不再生产。异步模式下，即便设置为 -1。也可能因为程序员的不迷信操作，操作数据失落，比方 kill -9，但这是特地的例外情况。
注：
ack=0：producer 不期待 broker 同步实现的确认，持续发送下一条 (批) 信息。
ack=1（默认）：producer 要期待 leader 胜利收到数据并失去确认，才发送下一条 message。
ack=-1：producer 失去 follwer 确认，才发送下一条数据。
- 消费者数据的不失落
通过 offset commit 来保证数据的不失落，kafka 本人记录了每次生产的 offset 数值，下次持续生产的时候，会接着上次的 offset 进行生产。
而 offset 的信息在 kafka0.8 版本之前保留在 zookeeper 中，在 0.8 版本之后保留到 topic 中，即便消费者在运行过程中挂掉了，再次启动的时候会找到 offset 的值，找到之前生产音讯的地位，接着生产，因为 offset 的信息写入的时候并不是每条音讯生产实现后都写入的，所以这种状况有可能会造成反复生产，然而不会失落音讯。
惟一例外的状况是，咱们在程序中给本来做不同性能的两个 consumer 组设置
KafkaSpoutConfig.bulider.setGroupid 的时候设置成了一样的 groupid，这种状况会导致这两个组共享同一份数据，就会产生组 A 生产 partition1，partition2 中的音讯，组 B 生产 partition3 的音讯，这样每个组生产的音讯都会失落，都是不残缺的。为了保障每个组都独享一份音讯数据，groupid 肯定不要反复才行。
- kafka 集群中的 broker 的数据不失落
每个 broker 中的 partition 咱们个别都会设置有 replication（正本）的个数，生产者写入的时候首先依据散发策略（有 partition 按 partition，有 key 按 key，都没有轮询）写入到 leader 中，follower（正本）再跟 leader 同步数据，这样有了备份，也能够保障音讯数据的不失落。
5. 采集数据为什么抉择 kafka？
采集层 次要能够应用 Flume, Kafka 等技术。
Flume：Flume 是管道流形式，提供了很多的默认实现，让用户通过参数部署，及扩大 API.
Kafka：Kafka 是一个可长久化的分布式的音讯队列。Kafka 是一个十分通用的零碎。你能够有许多生产者和很多的消费者共享多个主题 Topics。
相比之下,Flume 是一个专用工具被设计为旨在往 HDFS，HBase 发送数据。它对 HDFS 有非凡的优化，并且集成了 Hadoop 的平安个性。
所以，Cloudera 倡议如果数据被多个零碎生产的话，应用 kafka；如果数据被设计给 Hadoop 应用，应用 Flume。
6. kafka 重启是否会导致数据失落？
- kafka 是将数据写到磁盘的，个别数据不会失落。
- 然而在重启 kafka 过程中，如果有消费者生产音讯，那么 kafka 如果来不及提交 offset，可能会造成数据的不精确（失落或者反复生产）。
7. kafka 宕机了如何解决？
- 先思考业务是否受到影响
kafka 宕机了，首先咱们思考的问题应该是所提供的服务是否因为宕机的机器而受到影响，如果服务提供没问题，如果实现做好了集群的容灾机制，那么这块就不必放心了。
- 节点排错与复原
想要复原集群的节点，次要的步骤就是通过日志剖析来查看节点宕机的起因，从而解决，从新复原节点。
8. 为什么 Kafka 不反对读写拆散？
在 Kafka 中，生产者写入音讯、消费者读取音讯的操作都是与 leader 正本进行交互的，从 而实现的是一种 主写主读 的生产生产模型。
Kafka 并不反对 主写从读，因为主写从读有 2 个很显著的毛病:
- 数据一致性问题：数据从主节点转到从节点必然会有一个延时的工夫窗口，这个工夫 窗口会导致主从节点之间的数据不统一。某一时刻，在主节点和从节点中 A 数据的值都为 X，之后将主节点中 A 的值批改为 Y，那么在这个变更告诉到从节点之前，利用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不统一的问题。
- 延时问题：相似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程须要经验 网络→主节点内存→网络→从节点内存 这几个阶段，整个过程会消耗肯定的工夫。而在 Kafka 中，主从同步会比 Redis 更加耗时，它须要经验 网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘 这几个阶段。对延时敏感的利用而言，主写从读的性能并不太实用。
而 kafka 的 主写主读 的长处就很多了：
- 能够简化代码的实现逻辑，缩小出错的可能;
- 将负载粒度细化均摊，与主写从读相比，不仅负载效力更好，而且对用户可控;
- 没有延时的影响;
- 在正本稳固的状况下，不会呈现数据不统一的状况。
