关于后端:刨根问底-Kafka面试过程真好使

大家好，这里是 菜农曰，欢送来到我的频道。

充斥寒气的互联网如何在面试中怀才不遇，平时积攒很重要，八股文更不能少！上面带来的这篇 Kafka 问答心愿可能在你的 offer 上削减一把🔥。

Kafka 最后是由 Linkedin 公司开发的，是一个分布式的、可扩大的、容错的、反对分区的（Partition）、多正本的（replica）、基于 Zookeeper 框架的公布 - 订阅音讯零碎，Kafka 适宜离线和在线音讯生产。它是分布式应用零碎中的重要组件之一，也被广泛应用于大数据处理。Kafka 是用 Scala 语言开发，它的 Java 版本称为 Jafka。Linkedin 于 2010 年将该零碎奉献给了 Apache 基金会并成为顶级开源我的项目之一。

Kafka 是个大家伙，本篇将通过 40 道问答作为路线，由浅入深，最大水平上笼罩整个 Kafka 的问答内容（预习+温习一步到位）

1、Kafka 的设计

Kafka 将音讯以 topic 为单位进行演绎，公布音讯的程序称为 Producer，生产音讯的程序称为 Consumer。它是以集群的形式运行，能够由一个或多个服务组成，每个服务叫做一个 Broker，Producer 通过网络将音讯发送到 kafka 集群，集群向消费者提供音讯，broker 在两头起到一个代理保留音讯的中转站。

Kafka 中重要的组件

1）Producer：音讯生产者，公布音讯到 Kafka 集群的终端或服务

2）Broker：一个 Kafka 节点就是一个 Broker，多个 Broker 可组成一个 Kafka 集群。

如果某个 Topic 下有 n 个 Partition 且集群有 n 个 Broker，那么每个 Broker 会存储该 Topic 下的一个 Partition

如果某个 Topic 下有 n 个 Partition 且集群中有 m+n 个 Broker，那么只有 n 个 Broker 会存储该 Topic 下的一个 Partition

如果某个 Topic 下有 n 个 Partition 且集群中的 Broker 数量小于 n，那么一个 Broker 会存储该 Topic 下的一个或多个 Partition，这种状况尽量避免，会导致集群数据不平衡

3）Topic：音讯主题，每条公布到 Kafka 集群的音讯都会归集于此，Kafka 是面向 Topic 的

4）Partition：Partition 是 Topic 在物理上的分区，一个 Topic 能够分为多个 Partition，每个 Partition 是一个有序的不可变的记录序列。繁多主题中的分区有序，但无奈保障主题中所有分区的音讯有序。

5）Consumer：从 Kafka 集群中生产音讯的终端或服务

6）Consumer Group：每个 Consumer 都属于一个 Consumer Group，每条音讯只能被 Consumer Group 中的一个 Consumer 生产，但能够被多个 Consumer Group 生产。

7）Replica：Partition 的正本，用来保障 Partition 的高可用性。

8）Controller： Kafka 集群中的其中一个服务器，用来进行 Leader election 以及各种 Failover 操作。

9）Zookeeper：Kafka 通过 Zookeeper 来存储集群中的 meta 音讯

2、Kafka 性能高起因

1. 利用了 PageCache 缓存
2. 磁盘程序写
3. 零拷贝技术
4. pull 拉模式

3、Kafka 文件高效存储设计原理

1. Kafka 把 Topic 中一个 Partition 大文件分成多个小文件段，通过多个小文件段，就容易定期革除或删除曾经生产实现的文件，缩小磁盘占用
2. 通过索引信息能够疾速定位 Message 和确定 response 的最大大小
3. 通过将索引元数据全副映射到 memory，能够防止 Segment 文件的磁盘 I / O 操作
4. 通过索引文件稠密存储，能够大幅升高索引文件元数据占用空间大小

4、Kafka 的优缺点

长处

• 高性能、高吞吐量、低提早：Kafka 生产和生产音讯的速度都达到每秒 10 万级
• 高可用：所有音讯长久化存储到磁盘，并反对数据备份避免数据失落
• 高并发：反对数千个客户端同时读写
• 容错性：容许集群中节点失败（若正本数量为 n，则容许 n-1 个节点失败）
• 高扩展性：Kafka 集群反对热伸缩，毋庸停机

毛病

• 没有残缺的监控工具集
• 不反对通配符主题抉择

5、Kafka 的利用场景

1. 日志聚合：可收集各种服务的日志写入 kafka 的音讯队列进行存储
2. 音讯零碎：宽泛用于消息中间件
3. 零碎解耦：在重要操作实现后，发送音讯，由别的服务零碎来实现其余操作
4. 流量削峰：个别用于秒杀或抢购流动中，来缓冲网站短时间内高流量带来的压力
5. 异步解决：通过异步解决机制，能够把一个音讯放入队列中，但不立刻解决它，在须要的时候在进行解决

6、Kafka 中分区的概念

主题是一个逻辑上的概念，还能够细分为多个分区，一个分区只属于单个主题，很多时候也会把分区称为主题分区（Topic-Partition）。同一主题下的不同分区蕴含的音讯是不同的，分区在存储层面能够看做一个可追加的 日志文件，音讯在被追加到分区日志文件的时候都会调配一个特定的偏移量（offset）。offset 是音讯在分区中的惟一标识，kafka 通过它来保障音讯在分区内的程序性，不过 offset 并不逾越分区，也就是说，kafka 保障的是分区有序而不是主题有序。

在分区中又引入了多正本（replica）的概念，通过减少正本数量能够进步容灾能力。同一分区的不同正本中保留的是雷同的音讯。正本之间是一主多从的关系，其中主正本负责读写，从正本只负责音讯同步。正本处于不同的 broker 中，当主正本出现异常，便会在从正本中晋升一个为主正本。

7、Kafka 中分区的准则

1. 指明 Partition 的状况下，间接将指明的值作为 Partition 值
2. 没有指明 Partition 值但有 key 的状况下，将 key 的 Hash 值与 topic 的 Partition 值进行取余失去 Partition 值
3. 既没有 Partition 值又没有 key 值的状况下，第一次调用时随机生成一个整数（前面每次调用在这个整数上自增），将这个值与 Topic 可用的 Partition 总数取余失去 Parittion 值，也就是常说的 round-robin 算法

8、Kafka 为什么要把音讯分区

1. 不便在集群中扩大，每个 Partition 可用通过调整以适应它所在的机器，而一个 Topic 又能够有多个 Partition 组成，因而整个集群就能够适应任意大小的数据了
2. 能够进步并发，因为能够以 Partition 为单位进行读写

9、Kafka 中生产者运行流程

1. 一条音讯发过来首先会被封装成一个 ProducerRecord 对象
2. 对该对象进行序列化解决（能够应用默认，也能够自定义序列化）
3. 对音讯进行分区解决，分区的时候须要获取集群的元数据，决定这个音讯会被发送到哪个主题的哪个分区
4. 分好区的音讯不会间接发送到服务端，而是放入生产者的缓存区，多条音讯会被封装成一个批次（Batch），默认一个批次的大小是 16KB
5. Sender 线程启动当前会从缓存外面去获取能够发送的批次
6. Sender 线程把一个一个批次发送到服务端

10、Kafka 中的音讯封装

在 Kafka 中 Producer 能够 Batch 的形式推送数据达到提高效率的作用。Kafka Producer 能够将音讯在内存中累积到肯定数量后作为一个 Batch 发送申请。Batch 的数量大小能够通过 Producer 的参数进行管制，能够从三个维度进行管制

• 累计的音讯的数量（如 500 条）
• 累计的工夫距离（如 100ms）
• 累计的数据大小（如 64KB）

通过减少 Batch 的大小，能够缩小网络申请和磁盘 I / O 的频次，具体参数配置须要在效率和时效性做一个衡量。

11、Kafka 音讯的生产模式

Kafka 采纳大部分音讯零碎遵循的传统模式：Producer 将音讯推送到 Broker，Consumer 从 Broker 获取音讯。

如果采纳 Push 模式，则 Consumer 难以解决不同速率的上游推送音讯。

采纳 Pull 模式的益处是 Consumer 能够自主决定是否批量的从 Broker 拉取数据。Pull 模式有个毛病是，如果 Broker 没有可供生产的音讯，将导致 Consumer 一直在循环中轮询，直到新音讯达到。为了防止这点，Kafka 有个参数能够让 Consumer 阻塞直到新音讯达到。

12、Kafka 如何实现负载平衡与故障转移

负载平衡是指让零碎的负载依据肯定的规定平衡地调配在所有参加工作的服务器上，从而最大限度保证系统整体运行效率与稳定性

负载平衡

Kakfa 的负载平衡就是每个 Broker 都有均等的机会为 Kafka 的客户端（生产者与消费者）提供服务，能够负载扩散到所有集群中的机器上。Kafka 通过智能化的分区领导者选举来实现负载平衡，提供智能化的 Leader 选举算法，可在集群的所有机器上平均扩散各个 Partition 的 Leader，从而整体上实现负载平衡。

故障转移

Kafka 的故障转移是通过应用 会话机制 实现的，每台 Kafka 服务器启动后会以会话的模式把本人注册到 Zookeeper 服务器上。一旦服务器运行呈现问题，就会导致与 Zookeeper 的会话不能维持从而超时断连，此时 Kafka 集群会选举出另一台服务器来齐全代替这台服务器持续提供服务。

13、Kafka 中 Zookeeper 的作用

Kafka 是一个应用 Zookeeper 构建的分布式系统。Kafka 的各 Broker 在启动时都要在 Zookeeper 上注册，由 Zookeeper 对立协调治理。如果任何节点失败，可通过 Zookeeper 从先前提交的偏移量中复原，因为它会做周期性提交偏移量工作。同一个 Topic 的音讯会被分成多个分区并将其散布在多个 Broker 上，这些分区信息及与 Broker 的对应关系也是 Zookeeper 在保护。

14、Kafka 提供了哪些零碎工具

• Kafka 迁徙工具：它有助于将代理从一个版本迁徙到另一个版本
• Mirror Maker：Mirror Maker 工具有助于将一个 Kafka 集群的镜像提供给另一个
• 消费者查看：对于指定的主题集和消费者组，可显示主题、分区、所有者

15、Kafka 中消费者与消费者组的关系与负载平衡实现

Consumer Group 是 Kafka 独有的可扩大且具备容错性的消费者机制。一个组内能够有多个 Consumer，它们共享一个全局惟一的 Group ID。组内的所有 Consumer 协调在一起来生产订阅主题（Topic）内的所有分区（Partition）。当然，每个 Partition 只能由同一个 Consumer Group 内的一个 Consumer 来生产。生产组内的消费者能够应用多线程的形式实现，消费者的数量通常不超过分区的数量，且二者最好放弃整数倍的关系，这样不会造成有闲暇的消费者。

Consumer 订阅的是 Topic 的 Partition，而不是 Message。所以在同一时间点上，订阅到同一个分区的 Consumer 必然属于不同的 Consumer Group

Consumer Group 与 Consumer 的关系是动静保护的，当一个 Consumer 过程挂掉或者是卡住时，该 Consumer 所订阅的 Partition 会被重新分配到改选内的其余 Consumer 上，当一个 Consumer 退出到一个 Consumer Group 中时，同样会从其余的 Consumer 中调配出一个或者多个 Partition 到这个新退出的 Consumer。

负载平衡

当启动一个 Consumer 时，会指定它要退出的 Group，应用的配置项是：Group.id

为了维持 Consumer 与 Consumer Group 之间的关系，Consumer 会周期性地发送 hearbeat 到 coodinator（协调者），如果有 hearbeat 超时或未收到 hearbeat，coordinator 会认为该 Consumer 曾经退出，那么它所订阅的 Partition 会调配到同一组内的其余 Consumer 上，这个过程称为 rebalance（再均衡）

16、Kafka 中音讯偏移的作用

生产过程中给分区中的音讯提供一个程序 ID 号，称之为偏移量，偏移量的次要作用为了惟一地区别分区中的每条音讯。Kafka 的存储文件都是依照 offset.kafka 来命名

17、生产过程中何时会产生 QueueFullExpection 以及如何解决

何时产生

当生产者试图发送音讯的速度快于 Broker 能够解决的速度时，通常会产生 QueueFullException

如何解决

首先先进行判断生产者是否可能降低生产速率，如果生产者不能阻止这种状况，为了解决减少的负载，用户须要增加足够的 Broker。或者抉择生产阻塞，设置Queue.enQueueTimeout.ms 为 -1，通过这样解决，如果队列已满的状况，生产者将组织而不是删除音讯。或者容忍这种异样，进行音讯抛弃。

18、Consumer 如何生产指定分区音讯

Cosumer 生产音讯时，想 Broker 收回 fetch 申请去生产特定分区的音讯，Consumer 能够通过指定音讯在日志中的偏移量 offset，就能够从这个地位开始音讯音讯，Consumer 领有了 offset 的控制权，也能够向后回滚去从新生产之前的音讯。

也能够应用 seek(Long topicPartition) 来指定生产的地位。

19、Replica、Leader 和 Follower 三者的概念

Kafka 中的 Partition 是有序消息日志，为了实现高可用性，须要采纳备份机制，将雷同的数据复制到多个 Broker 上，而这些备份日志就是 Replica，目标是为了 避免数据失落。

所有 Partition 的正本默认状况下都会平均地散布到所有 Broker 上, 一旦领导者正本所在的 Broker 宕机，Kafka 会从追随者正本中选举出新的领导者持续提供服务。

Leader： 正本中的领导者。负责对外提供服务，与客户端进行交互。生产者总是向 Leader 正本些音讯，消费者总是从 Leader 读音讯

Follower： 正本中的追随者。被动地追寻 Leader，不能与外界进行交付。只是向 Leader 发送音讯，申请 Leader 把最新生产的音讯发给它，进而放弃同步。

20、Replica 的重要性

Replica 能够确保公布的音讯不会失落，保障了 Kafka 的高可用性。并且能够在产生任何机器谬误、程序谬误或软件降级、扩容时都能生产应用。

21、Kafka 中的 Geo-Replication 是什么

Kafka 官网提供了 MirrorMaker 组件，作为跨集群的流数据同步计划。借助 MirrorMaker，音讯能够跨多个数据中心或云区域进行复制。您能够在被动 / 被动场景中将其用于备份和复原，或者在被动 / 被动计划中将数据搁置得更凑近用户，或反对数据本地化要求。

它的实现原理比较简单，就是通过从源集群生产音讯，而后将音讯生产到指标集群，即一般的音讯生产和生产。用户只有通过简略的 Consumer 配置和 Producer 配置，而后启动 Mirror，就能够实现集群之间的准实时的数据同步.

22、Kafka 中 AR、ISR、OSR 三者的概念

• AR：分区中所有正本称为 AR
• ISR：所有与主正本放弃肯定水平同步的正本（包含主正本）称为 ISR
• OSR：与主正本滞后过多的正本组成 OSR

23、分区正本什么状况下会从 ISR 中剔出

Leader 会保护一个与本人根本放弃同步的 Replica 列表，该列表称为 ISR，每个 Partition 都会有一个 ISR，而且是由 Leader 动静保护。所谓动静保护，就是说如果一个 Follower 比一个 Leader 落后太多，或者超过肯定工夫未发动数据复制申请，则 Leader 将其从 ISR 中移除。当 ISR 中所有 Replica 都向 Leader 发送 ACK（Acknowledgement 确认）时，Leader 才 commit。

24、分区正本中的 Leader 如果宕机但 ISR 却为空该如何解决

能够通过配置unclean.leader.election：

• true：容许 OSR 成为 Leader，然而 OSR 的音讯较为滞后，可能会呈现音讯不统一的问题
• false：会始终期待旧 leader 恢复正常，升高了可用性

25、如何判断一个 Broker 是否还无效

1. Broker 必须能够保护和 ZooKeeper 的连贯，Zookeeper 通过心跳机制查看每个结点的连贯。
2. 如果 Broker 是个 Follower，它必须能及时同步 Leader 的写操作，延时不能太久。

26、Kafka 可接管的音讯最大默认多少字节，如何批改

Kafka 能够接管的最大音讯默认为 1000000 字节，如果想调整它的大小，可在 Broker 中批改配置参数：Message.max.bytes的值

但要留神的是，批改这个值，还要同时留神其余对应的参数值是正确的，否则就可能引发一些零碎异样。首先这个值要比生产端的 fetch.Message.max.bytes（默认值 1MB，示意消费者能读取的最大音讯的字节数）参数值要小才是正确的设置，否则 Broker 就会因为生产端无奈应用这个音讯而挂起。

27、Kafka 的 ACK 机制

Kafka 的 Producer 有三种 ack 机制，参数值有 0、1 和 -1

• 0： 相当于异步操作，Producer 不须要 Leader 给予回复，发送完就认为胜利，持续发送下一条（批）Message。此机制具备最低提早，然而持久性可靠性也最差，当服务器产生故障时，很可能产生数据失落。
• 1： Kafka 默认的设置。示意 Producer 要 Leader 确认已胜利接收数据才发送下一条（批）Message。不过 Leader 宕机，Follower 尚未复制的状况下，数据就会失落。此机制提供了较好的持久性和较低的提早性。
• -1： Leader 接管到音讯之后，还必须要求 ISR 列表里跟 Leader 放弃同步的那些 Follower 都确认音讯已同步，Producer 才发送下一条（批）Message。此机制持久性可靠性最好，但延时性最差。

28、Kafka 的 consumer 如何生产数据

在 Kafka 中，Producers 将音讯推送给 Broker 端，在 Consumer 和 Broker 建设连贯之后，会被动去 Pull（或者说 Fetch）音讯。这种模式有些长处，首先 Consumer 端能够依据本人的生产能力适时的去 fetch 音讯并解决，且能够管制音讯生产的进度（offset）；此外，消费者能够管制每次生产的数，实现批量生产。

29、Kafka 提供的 API 有哪些

Kafka 提供了两套 Consumer API，分为 High-level API 和 Sample API

Sample API

这是一个底层 API，它维持了一个与繁多 Broker 的连贯，并且这个 API 是齐全无状态的，每次申请都须要指定 offset 值，因而这套 API 也是最灵便的。

High-level API

该 API 封装了对集群中一系列 Broker 的拜访，能够通明地生产下一个 Topic，它本人保护了已生产音讯的状态，即每次生产的都会下一个音讯。High-level API 还反对以组的模式生产 Topic，如果 Consumers 有同一个组名，那么 Kafka 就相当于一个队列音讯服务，而各个 Consumer 平衡地生产相应 Partition 中的数据。若 Consumers 有不同的组名，那么此时 Kafka 就相当于一个播送服务，会把 Topic 中的所有音讯播送到每个 Consumer

30、Kafka 的 Topic 中 Partition 数据是怎么存储到磁盘的

Topic 中的多个 Partition 以文件夹的模式保留到 Broker，每个分区序号从 0 递增，且音讯有序。Partition 文件下有多个 Segment（xxx.index，xxx.log），Segment 文件里的大小和配置文件大小统一。默认为 1GB，但能够依据理论须要批改。如果大小大于 1GB 时，会滚动一个新的 Segment 并且以上一个 Segment 最初一条音讯的偏移量命名。

31、Kafka 创立 Topic 后如何将分区搁置到不同的 Broker 中

Kafka 创立 Topic 将分区搁置到不同的 Broker 时遵循以下规定：

1. 正本因子不能大于 Broker 的个数。
2. 第一个分区（编号为 0）的第一个正本搁置地位是随机从 Broker List 中抉择的。
3. 其余分区的第一个正本搁置地位绝对于第 0 个分区顺次往后移。也就是如果有 3 个 Broker，3 个分区，假如第一个分区放在第二个 Broker 上，那么第二个分区将会放在第三个 Broker 上；第三个分区将会放在第一个 Broker 上，更多 Broker 与更多分区依此类推。残余的副本相对于第一个正本搁置地位其实是由 nextReplicaShift 决定的，而这个数也是随机产生的。

32、Kafka 的日志保留期与数据清理策略

概念

保留期内保留了 Kafka 群集中的所有已公布音讯，超过保期的数据将被按清理策略进行清理。默认保留工夫是 7 天，如果想批改工夫，在 server.properties 里更改参数log.retention.hours/minutes/ms 的值便可。

清理策略

• 删除： log.cleanup.policy=delete 示意启用删除策略，这也是默认策略。一开始只是标记为 delete，文件无奈被索引。只有过了 log.Segment.delete.delay.ms 这个参数设置的工夫，才会真正被删除。
• 压缩： log.cleanup.policy=compact 示意启用压缩策略，将数据压缩，只保留每个 Key 最初一个版本的数据。首先在 Broker 的配置中设置log.cleaner.enable=true 启用 cleaner，这个默认是敞开的。

33、Kafka 日志存储的 Message 是什么格局

Kafka 一个 Message 由 固定长度的 header和 一个变长的音讯体 body组成。将 Message 存储在日志时采纳不同于 Producer 发送的音讯格局。每个日志文件都是一个 log entries（日志项）序列：

1. 每一个 log entry 蕴含一个四字节整型数（Message 长度，值为 1 +4+N）。
2. 1 个字节的 magic，magic 示意本次公布 Kafka 服务程序协定版本号。
3. 4 个字节的 CRC32 值，CRC32 用于校验 Message。
4. 最终是 N 个字节的音讯数据。每条音讯都有一个以后 Partition 下惟一的 64 位 offset。

Kafka 没有限定单个音讯的大小，但个别举荐音讯大小不要超过 1MB，通常个别音讯大小都在 1～10KB 之间。

34、Kafka 是否反对多租户隔离

多租户技术（multi-tenancy technology）是一种软件架构技术，它是实现如何在多用户的环境下共用雷同的零碎或程序组件，并且仍可确保各用户间数据的隔离性。

解决方案

通过配置哪个主题能够生产或生产数据来启用多租户，也有对配额的操作反对。管理员能够对申请定义和强制配额，以管制客户端应用的 Broker 资源。

35、Kafka 的日志分段策略与刷新策略

日志分段（Segment）策略

1. log.roll.hours/ms：日志滚动的周期时间，达到指定周期时间时，强制生成一个新的 Segment，默认值 168h（7day）。
2. log.Segment.bytes：每个 Segment 的最大容量。达到指定容量时，将强制生成一个新的 Segment。默认值 1GB（- 1 代表不限度）。
3. log.retention.check.interval.ms：日志片段文件查看的周期时间。默认值 60000ms。

日志刷新策略

Kafka 的日志实际上是开始是在缓存中的，而后依据理论参数配置的策略定期一批一批写入到日志文件中，以进步吞吐量。

1. log.flush.interval.Messages：音讯达到多少条时将数据写入到日志文件。默认值为 10000。
2. log.flush.interval.ms：当达到该工夫时，强制执行一次 flush。默认值为 null。
3. log.flush.scheduler.interval.ms：周期性查看，是否须要将信息 flush。默认为很大的值。

36、Kafka 中如何进行主从同步

Kafka 动静保护了一个同步状态的正本的汇合（a set of In-SyncReplicas），简称 ISR，在这个汇合中的结点都是和 Leader 放弃高度一致的，任何一条音讯只有被这个汇合中的每个结点读取并追加到日志中，才会向内部告诉“这个音讯曾经被提交”。

kafka 通过配置 producer.type 来确定是异步还是同步，默认是同步

同步复制

Producer 会先通过 Zookeeper 辨认到 Leader，而后向 Leader 发送音讯，Leader 收到音讯后写入到本地 log 文件。这个时候 Follower 再向 Leader Pull 音讯，Pull 回来的音讯会写入的本地 log 中，写入实现后会向 Leader 发送 Ack 回执，等到 Leader 收到所有 Follower 的回执之后，才会向 Producer 回传 Ack。

异步复制

Kafka 中 Producer 异步发送音讯是基于同步发送音讯的接口来实现的，异步发送音讯的实现很简略，客户端音讯发送过去当前，会先放入一个 BlackingQueue 队列中而后就返回了。Producer 再开启一个线程 ProducerSendTread 一直从队列中取出音讯，而后调用同步发送音讯的接口将音讯发送给 Broker。

Producer 的这种在内存缓存音讯，当累计达到阀值时批量发送申请，小数据 I / O 太多，会拖慢整体的网络提早，批量提早发送事实上晋升了网络效率。然而如果在达到阀值前，Producer 不可用了，缓存的数据将会失落。

37、Kafka 中什么状况下会呈现音讯失落 / 不统一的问题

音讯发送时

音讯发送有两种形式：同步 - sync 和 异步 - async。默认是同步的形式，能够通过 producer.type 属性进行配置，kafka 也能够通过配置 acks 属性来确认音讯的生产

• 0：示意不进行音讯接管是否胜利的确认
• 1：示意当 leader 接管胜利时的确认
• -1：示意 leader 和 follower 都接管胜利的确认

当 acks = 0 时，不和 Kafka 进行音讯接管确认，可能会因为网络异样，缓冲区满的问题，导致音讯失落

当 acks = 1 时，只有 leader 同步胜利而 follower 尚未实现同步，如果 leader 挂了，就会造成数据失落

音讯生产时

Kafka 有两个音讯生产的 consumer 接口，别离是 low-level 和 hign-level

1. low-level：消费者本人保护 offset 等值，能够实现对 kafka 的齐全管制
2. high-level：封装了对 partition 和 offset，应用简略

如果应用高级接口，可能存在一个消费者提取了一个音讯后便提交了 offset，那么还没来得及生产就曾经挂了，下次生产时的数据就是 offset + 1 的地位，那么原先 offset 的数据就失落了。

38、Kafka 作为流解决平台的特点

流解决就是间断、实时、并发和以逐条记录的形式解决数据的意思。Kafka 是一个分布式流解决平台，它的高吞吐量、低延时、高可靠性、容错性、高可扩展性都使得 Kafka 非常适合作为流式平台。

1. 它是一个简略的、轻量级的 Java 类库，可能被集成到任何 Java 利用中
2. 除了 Kafka 之外没有任何其余的依赖，利用 Kafka 的分区模型反对程度扩容和保障程序性
3. 反对本地状态容错，能够执行十分疾速无效的有状态操作
4. 反对 eexactly-once 语义
5. 反对一次解决一条记录，实现 ms 级的提早

39、消费者故障，呈现活锁问题如何解决

活锁的概念：消费者继续的维持心跳，但没有进行音讯解决。

为了预防消费者在这种状况始终持有分区，通常会利用 max.poll.interval.ms沉闷检测机制，如果调用 Poll 的频率大于最大距离，那么消费者将会被动来到生产组，以便其余消费者接管该分区

40、Kafa 中如何保障程序生产

Kafka 的生产单元是 Partition，同一个 Partition 应用 offset 作为惟一标识保障程序性，但这只是保障了在 Partition 外部的程序性而不是 Topic 中的程序，因而咱们须要将所有音讯发往对立 Partition 能力保障音讯程序生产，那么能够在发送的时候指定 MessageKey，同一个 key 的音讯会发到同一个 Partition 中。

以上便是本篇的全部内容，不要空谈，不要贪懒，和小菜一起做个 吹着牛 X 做架构 的程序猿吧~ 点个关注做个伴，让小菜不再孤独。咱们下文见！

明天的你多致力一点，今天的你就能少说一句求人的话！

我是小菜，一个和你一起变强的男人。 💋

微信公众号已开启，菜农曰，没关注的同学们记得关注哦！