1、kafka 的 ack 机制

request.required.acks 有三个值 0 1 -1

• 0:生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候 就会丢数据
• 1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader 挂掉后他 不确保是否复制完成新 leader 也会导致数据丢失
• -1：同样在 1 的基础上 服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出 的 ack，这样数据不会丢失

2、partition 的数据如何保存到硬盘

• topic 中的多个 partition 以文件夹的形式保存到 broker，每个分区序号从 0 递增， 且消息有序
• Partition 文件夹下有多个 segment（xxx.index，xxx.log） segment 文件里的 大小和配置文件大小一致可以根据要求修改
• 默认为 1g 如果大小大于 1g 时，会滚动一个新的 segment 并且以 上一个 segment 最后一条消息的偏移量命名

3、.Kafka 与传统消息系统之间有三个关键区别

• (1).Kafka 持久化日志，这些日志可以被重复读取和无限期保留
• (2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据 提升容错能力和高可用性
• (3).Kafka 支持实时的流式处理

4、Kafka 高效文件存储设计特点：

• (1).Kafka 把 topic 中一个 parition 大文件分成多个小文件段，通过多个小文件段，就容易定 期清除或删除已经消费完文件，减少磁盘占用。
• (2).通过索引信息可以快速定位 message 和确定 response 的最大大小。
• (3).通过 index 元数据全部映射到 memory，可以避免 segment file 的 IO 磁盘操作。
• (4).通过索引文件稀疏存储，可以大幅降低 index 文件元数据占用空间大小。
• (5). 顺序刷盘

5、Kafa consumer 是否可以消费指定分区消息？

Kafa consumer 消费消息时，向 broker 发出"fetch"请求去消费特定分区的消息，consumer 指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer 拥有 了 offset 的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的；
消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（offset）的位置 等到下次消费时，他会接着上次位置继续消费
一个消费者组中的一个分片对应一个消费者成员，他能保证每个消费者成员都能访问，如 果组中成员太多会有空闲的成员

6、Kafka 消息是采用 Pull 模式，还是 Push 模式？

• Kafka 最初考虑的问题是，customer 应该从 brokes 拉取消息还是 brokers 将消息推送到 consumer，也就是 pull 还 push。
• 在这方面，Kafka 遵循了一种大部分消息系统共同的传统 的设计：producer 将消息推送到 broker，consumer 从 broker 拉取消息
• 一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式，将消息推送到下游的 consumer。
  这样做有好处也有坏处：由 broker 决定消息推送的速率，对于不同消费速率的 consumer 就不太好处理了。消息系统都致力于让 consumer 以最大的速率最快速的消费消 息，但不幸的是，push 模式下，当 broker 推送的速率远大于 consumer 消费的速率时， consumer 恐怕就要崩溃了。
• 最终 Kafka 还是选取了传统的 pull 模式
• Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据。
  Push 模式必须在不知道下游 consumer 消费能力和消费策略的情况下决定是立即推送每条消息还 是缓存之后批量推送。
• 如果为了避免 consumer 崩溃而采用较低的推送速率，将可能导致一 次只推送较少的消息而造成浪费。
  Pull 模式下，consumer 就可以根据自己的消费能力去决定这些策略
  Pull 有个缺点是，如果 broker 没有可供消费的消息，将导致 consumer 不断在循环中轮询， 直到新消息到 t 达。为了避免这点，Kafka 有个参数可以让 consumer 阻塞直到新消息到达 (当然也可以阻塞直到消息的数量达到某个特定的量这样就可以批量发

7、producer 是否直接将数据发送到 broker 的 leader(主节点)？

• producer 直接将数据发送到 broker 的 leader(主节点)，不需要在多个节点进行分发，为了 帮助 producer 做到这点，所有的 Kafka 节点都可以及时的告知:哪些节点是活动的，目标 topic 目标分区的 leader 在哪。这样 producer 就可以直接将消息发送到目的地了

• 生产者决定数据产生到集群的哪个 partition 中
  每一条消息都是以（key，value）格式
  Key 是由生产者发送数据传入
  所以生产者（key）决定了数据产生到集群的哪个 partition

8、.Kafka 判断一个节点是否还活着有那两个条件？

• （1）节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连 接
• （2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久

9、Kafka 创建 Topic 时如何将分区放置到不同的 Broker 中

• 副本因子不能大于 Broker 的个数；
• 第一个分区（编号为 0）的第一个副本放置位置是随机从 brokerList 选择的；
• 其他分区的第一个副本放置位置相对于第 0 个分区依次往后移。也就是如果我们有 5 个 Broker，5 个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五 个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，依次类推；
• 剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是 随机产生的

# kafka