重磅！2025秋招大数据面经来袭！！

为了帮助更多的学子拿到心仪的offer，进入到梦中情司，特此分享大数据相关的面经，可用于大数据开发、数据仓库、数据分析等岗位，

补充：kafka中的事件流

事件流是指以事件流的形式从事件源，例如数据库/传感器/移动设备等实时捕获数据的做法，持久存储这些事件流供以后检索，实时和回顾性的操作处理和相应事件流，后续根据事件流流到不同的目标技术中，确保将正确的信息放在正确的位置

Tips：事件流处理可以用来干什么？

1、实时处理付款和金融交易银行

2、实时跟踪和监控汽车卡车和物流行业

3、持续捕获和分析来自IoT设备的传感器数据

4、持续收集客户互动和订单并实时做出反应

5、监测住院护理的患者并预测病情变化，以确保在紧急状态下得到及时治疗

83、介绍下Kafka，Kafka的作用?Kafka的组件?适用场景?

Kafka是一个高吞吐量、可扩展的分布式消息传递系统，在处理实时流式数据，并能够保证持久性和容错性

可用于数据管道、流分析和数据继承和关键任务应用（发布/订阅模式）

发布/订阅模式：

可以有多个topic主题、消费者消费数据之后，不删除数据、每个消费者相互独立，都可以消费数据

生产者和消费者之间通过一个容器来解决强耦合问题，两者并不直接通信，而是通过阻塞队列来进行通信，生产者生产完数据不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列中取，起到了一个削峰的作用

84、Kafka作为消息队列，它可解决什么样的问题?

异步：允许用户把一个消息放入队列，但并不立即处理他们，需要的时候再去处理

消峰：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况

解耦：消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，允许独立扩展或者修改两边的处理过程，只要确保他们遵守同样的接口约束

85、说下Kafka架构

消息：作为一个事件流平台，kafka中的一条消息包括了key-value timestamp

生产者：消息的生产者，就是向Kafka broker发消息的客户端

消费者：订阅生产者发布的消息，或者消费topic中的消息，消费者只需要订阅topic，不需要关注kafka集群内实例对partition的分配

消费组：有多个消费者组成，消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内的消费者消费；消费者组之间互不影响；所以消费者组逻辑上是一个订阅者

broker：一台Kafka服务器就是一个broker，一个broker可以容纳多个topic

topic：一个队列，生产者和消费者面向的都是一个topic，用于存储不同类别的消息

partition：一个非常大的toipc可以分布到多个broker，一个topic可以分为多个partition

replication：每个partition分区可以有多个副本，分布在不同的broker上，类比HDFS中的副本机制

leader：每个partition有多个副本，其中有且仅有一个作为leader，leader是当前负责数据读写的partition，只有leader才能进行数据读写，follower副本只做备份使用

follower：follower跟随leader，所有写请求都通过leader路由，数据变更会广播给所有的follower，两者保持数据同步，如果leader失效，则会从follower中选举出一个新的leader；follower需要不断向leader发出申请，进行数据的同步

topic是逻辑上的概念，partition是物理上的概念，每个partition对应一个log文件，而log文件中存储的就是producer产生的数据，partition产生的数据会被不断的添加到log文件的末端，且每条数据都有自己的offset；

注：下图表示该topic有四个分区，p1-p4，两个不同生产者客户端通过网络将事件写入主题的分区，相互独立地向主题发布新的事件，具有相同键的事件写入统一分区；

消费者组：每个消费者属于一个特定的消费者组，多个消费者可以属于同一个消费者组

kafka消息存放在partition的日志中，同一条消息可以被不同的消费者组消费

但在同一个消费者组中，partition内的消息只由组内的某一个消费者实例绑定消费

当消费者组中消费者实例初次连接 Kafka 时，分配 Partition，Consumer 向 Kafka 发送心跳检测，后续超过心跳周期（session.timeout.ms）将默认离线。会触发 rebalance，将该 Partition 重新分配给消费者组中的其他消费者实例。

补充：ISR与OSR

分区中的所有副本统称为AR，所有与leader副本保持一定程度同步的副本组成ISR，消息会先发送到leader副本，然后follwer副本才能从leader副本中拉取消息进行同步；

与leader副本同步滞后过多的副本（不包括leader副本，组成OSR）

故有：AR=ISR+OSR

leader副本负责维护和跟踪ISR集合中所有follower副本的滞后状态，当follower副本落后太多或者失效的时候，leader副本会把它从ISR中剔除，如果OSR集合中有follower副本追上leader副本，那么leader副本会把它从OSR转移到ISR中；

默认情况下，当leader副本发生故障的时候，只有在ISR集合中的副本才有资格被选举成新的leader，在OSR中的副本没有任何机会参与

86、Kafka的工作原理和它与传统消息队列服务的不同之处？与RabbitMQ相比？

特点：

发布订阅模型；分区和复制；高吞吐量；实时数据流支持：传统消息队列只支持按需查看历史数据，而Kafka还支持传输实时流数据

与传统消息队列相比：Kafka优化了磁盘使用、利用操作系统缓存进行高速读写、并提供高效的分区和复制机制

RabbitMQ：在大规模实时性要求的场景下，使用Kafka合适；在简单的消息传递与排队需求中，选择常见的消息队列较为合适、

补充：两种消息队列模式

点对点模式：点对点通常是基于拉取或者轮询的消息传送模型，发送到队列的消息被一个且只有一个消费者进行消费，生产者把消息放入消息队列后，由消费者主动拉取消息进行消费；优点是消费者拉取消息的频率可以由自己控制，避免造成下游消息队列阻塞

发布订阅模式：生产者把消息放入消息队列以后，队列会把消息推送给该类的消费者

87、Kafka的工作流程

创建一个Kafka的生产者将源数据推送到Kafka的topic中，然后使用消费者从topic订阅消息，并传递给处理引擎或者存储系统

在生产者流程中有两个关键参数（batch.size和linger.ms）：只有数据累计达到batch.size后，sender才会发送数据，默认为16k；如果数据迟迟未达到batch.size，sender设置的linger.ms设置的时间达到以后就会发送数据，默认为0ms，表示没有延迟。

补充：kafka发送数据步骤

1）生产者查询leader：生产者通过元数据请求从kafka集群的某个broker获取关于topic、partition和leader的元数据信息

2）找到leader后发送消息：生产者向获取到的leader发送消息，leader接收到消息后，将消息追加到该partition的本地日志中

3）leader落盘：leader将消息追加到本地日志，并根据配置的刷新策略将消息刷新到磁盘

4）Follower 从 Leader 拉取数据： Followers 从 Leader 中拉取新的数据，并将这些数据追加到各自的本地日志中。Follower 会不断地拉取数据以保持与 Leader 同步。

5）Kafka 向生产者回应 ACK： 生产者发送消息后，可以选择是否等待集群的确认。如果设置为等待确认模式，生产者会等待来自 Leader 的确认（ack）或其他副本的确认。确认表示消息已经被成功写入 Leader 和所有的副本

88、kakfa分区容错性

副本机制：Kafka允许一个topic创建多个副本，并将这些副本分布在不同的broker上

数据复制：Kafka使用异步复制机制来保证数据的可靠性，当消息被写入到leader副本时候，Kafka会将其异步复制到follower副本中

ISR机制：用来保证副本之间的一致性，如果某个副本无法及时复制消息或者落后于其他副本太多，它将被从SIR集合中移除，直到追赶上其他副本的进度为止

故障转移：当某个broker宕机或者分区的领导副本不可用时候，Kafka会自动进行故障转移，它会从ISR集合中选择一个新副本作为领导副本

89、Kafka的分区策略

如上是Kafka的构造方法：

1、如果指定了partition的情况下，直接将指明的值作为partition值

2、如果没有指明partition值但有key的情况之下，将key的hash值与topic的partition分区数进行取余得到partition的值，并将对应的value写入到对应的分区中

3、既没有partition值又没有key值的情况下，Kafka采用粘性分区器（sticky partition），会随机选择一个分区，并尽可能一直使用或者分区，直到该分区的batch已满或者已完成，Kafka再随机一个分区进行使用。

90、Kafka如何尽可能保证数据可靠性?

1、保证分区消息的顺序———分区有序

2、只有当消息被写入分区的所有同步副本时候，它才被认为是已经提交的（ACK应答）

ACK是指：ackowledgement，用于控制生产者发送消息时候的可靠性和性能，

ACK=0：生产者对象将数据通过网络客户端将数据发送到网络数据流中的时候，Kafka就对当前的数据请求进行了响应，确认应答，只是能保证数据已经通过网络发送给Kafka，并不能保证Kafka一定能接收到，无法保证数据的可靠性，但通信效率高

ACK=1：生产者等待leader副本成功写入消息到日志文件后就认为发送成功，适用于对可靠性较高的场景，这种应答方式，数据已经存储到分区的leader副本中，数据相对安全，但数据并没有及时备份到follower副本，一旦broker崩溃，数据也会丢失

ACK=all或者-1（默认）：生产者等待ISR中所有副本成功写入消息后，就认为发送成功，适用于对数据不可丢失的高可靠性要求场景（一般是金融级别的才会使用这种配置）

3、只要还有一个副本是活跃的，那么已经提交的消息就不会丢失

4、消费者只能读取已经提交的消息

5、Kafka的复制机制和分区的多副本架构是Kafka可靠性保证的核心（topic被分为多个分区，分区是基本的数据块，分区存储在单个磁盘上，Kafka可以保证分区里的事件是有序的，分区可以有多个副本）

91、Kafka的同步与异步发送

同步模式：逐条发送，用户线程选择同步，效果是逐条发送，因为请求队列InFlightRequest中永远最多有一条数据，第一条响应到达以后，才会请求第二条

异步模式：如果设置成异步模式。可以运行生产者以batch的形式push数据，这样会极大的提高broker的性能，会增加丢失数据的风险

如果Kafka通过主线程代码将一条数据放入到缓冲区中后，无需等待数据的后续发送过程，就直接发送下一条数据的场合，就是异步发送

如果Kafka通过主线程代码将一条数据放入到缓冲区后，需等待数据的后续发送操作的应答状态，才能发送一下条数据的场合，我们就称之为同步发送。所以这里的所谓同步，就是生产数据的线程需要等待发送线程的应答（响应）结果。

92、Kafka数据丢失和数据重复原因和解决办法

数据丢失原因：不等待broker的ack，broker接收到磁盘就已经返回了，当broker故障时候会丢失数据

数据重复原因：当ack设置为1的时候，假如因为网络原因，Kafka没有将应答消息发送给生产者，一旦超时时间阈值，就认为Kafka数据丢失，此时生产者会尝试对超时的请求数据进行重试，此时Kafka中存在的数据是重复的

补充：数据幂等性

幂等性出现的原因就是为了解决kafka传输数据的时候，出现数据重复和乱序的问题

生产者同样的一条数据，无论向Kafka发送多少次，Kafka只会存储一条数据，

幂等性只能保证单分区消息有序不重复，多分区不能保证幂等性

数据传输语义：

https://infinity-culture.feishu.cn/sync/OWY5dMNgjsOajnbyFSxcrIq7nBd

kafka幂等性实现原理

1）kafka幂等性会给每一个请求批次的数据增加序列号（sequencenum）和生产者ID（producerid）；

2）Broker采用队列的方式缓存最近的5个批次的数据，队列中按照sequencenum升序排列，（5为固定值，不可修改）

3）如果broker当前新的请求的批次数据在缓存中的5个旧的批次中存在相同的，如果有相同的，说明有重复，当前批次数据不做任何处理

4）如果broker当前的请求批次数据在缓存中没有相同的，那么判断当前新的批次的序列号是否为缓存的最后一个批次的序列号+1，如果是，说明连续，如果不是，说明数据乱序

5）如果请求批次不重复且有序，那么更新缓冲区中的批次数据，将当前的批次放置在队列的结尾，将队列的第一个移除，保证队列中缓冲的数据最多有5个

幂等性缺点

kafka的幂等性是通过消耗时间和性能的方式提升数据的唯一性和可靠性；幂等性仅仅做到了单分区上的幂等性，单分区消息有序不重复，多分区无法保证幂等性；目前只能保持生产者单个会话的幂等性，无法实现跨会话的幂等性，如果一个producer挂掉再重启，前后会被当成两个独立的生产者，不能实现跨会话的幂等性

补充：为了解决跨会话幂等性，引入事务机制

引入事务协调器负责事务的处理；

普通的数据操作，只要数据写入了日志，那么对于消费者来讲，数据就可以读取到，

对于事务操作，如果有数据写入了日志，但是没有提交的话，其实数据默认情况下也是不能被消费者看到，只有提交之后才可以看见数据

补充：kafka事务的两阶段提交

https://infinity-culture.feishu.cn/sync/FAZcdhAyJs6M85bwRaYcaHOVnHd

补充：ISR、AR、OSR的区别

所有同步的副本形成一个列表，称为同步副本列表（In-Sync Replicas） ISR

注意：如果ACKS的应答机制设置为-1，此时需要保证同步副本列表ISR中的所有副本全部接收完毕，kafka才会进行确认应答

已分配的副本列表（Assigned Replicas） AR

没有同步的副本列表（Out-of-Sync Replicas） OSR

补充：副本管理器 ReplicaManager

周期性地查看ISR中的副本集合时候需要收缩，把ISR副本集合中那些与leader差距过大的副本移除

补充：Kafka消息可靠性

很多时候是不关心消息是否已经发送成功，我们只要发送就好了；也有些时候需要确定消息是否已经发送成功并且kafka正确的接收到数据；kafka提供了3种应答处理：Ack（0，1，-1）

ACK=0：

  生产者只要发送了数据就会进行应答，只是单纯的发送出去了消息，如果中途出现网络波动，消费者不能正确的接收到消息，此方法效率最高，可靠性最低

  ACK=1：

  生产者发出消息时，leader副本将数据接收到并且成功写入到日志后，就会对当前数据请求进行应答

  ACK=-1：

  生产者发出消息，leader副本和follower都已经将数据收到并写入到日志文件后，再对当前的数据请求进行应答，此方法效率最低，可靠性最高，数据不会丢失

补充：kafka数据传输语义

93、生产者消费者模式与发布订阅模式有何异同?

生产者消费者模式，指的是由生产者将数据源源不断推送到消息中心，由不同的消费者从消息中心取出数据做自己的处理，在同一类别下，所有消费者拿到的都是同样的数据

发布订阅模式：本质上也是一种消费者模式，由订阅者首先向消息中心指定自己对哪些数据感兴趣，发布者推送的数据经过消息中心后，每个订阅者拿到的仅仅是自己感兴趣的数据

生产者消费者是所有消费者抢占消息，订阅发布是所有订阅者共享信息；

主动权不同，生产消费者主动权在消费者，订阅发布主动权在发布者，

94、Kafka如何保证全局有序

Kafka通过分区和分区内的顺序保证全局有序，将数据分为多个topic，每个topic可以有多个分区，每个分区都有唯一的标识，并且在集群中的多个节点上进行复制以提高 高可用性

每个分区内，Kafka使用offset来标识消息的顺序，生产者将消息切入待定的分区时，Kafka会为每个消息分配一个递增的偏移量，消费者通过指定分区和偏移量来读取消息，保证消费者按照指定顺序处理消息

如果某一个topic只有一个分区，那么该主题的消息顺序是全局有序的

如果一个topic有多个分区，Kafka可以根据消息的key来选择将消息写入哪个分区，具有相同key的消息将被写入同一个分区，并且同一个分区内的消息顺序是有序的

95、Kafka为什么同一个消费者组的消费者不能消费相同的分区?

Kafka中同一个消费者组的消费者组不能消费相同的分区是因为Kafka中采用分区分配策略，确保每个分区被消费者组的的一个消费者消费，主要是为了确保消息的顺序性和负载均衡，使得每个消费者都能够处理大致相同的数量的消息

96、Kafka读取消息是推还是拉的模式?有什么好?

Kafka的消息读取模式是pull拉模式，消费者主动拉取Kafka服务器的消息

好处：

  1、消费者可以根据自身的处理能力和需求决定拉取消息的速率

  2、节约资源：可以避免服务器主动推送大量消息给消费者，减少网络带宽的和服务资源的消耗

  3、容错性：在拉取过程中出现错误，可以重新拉取相同的消息进行重试

  4、消息积压控制：消费者可以根据自身的处理能力调整拉取消息的速率

如果是push模式，多个分区的数据同时推送给消费者进行处理，明显一个消费者的消费能力是有限的，消费者无法快速处理数据，就会导致数据的积压，导致网络、存储的压力，影响效率

补充：消费者组模式

为什么会出现消费者组？

  在kafka中，为了提高消息拉取的效率，出现了消费者组的概念，消费者组中的消费者可以指定拉取某一个分区的消息

如果topic的分区的数据过多，消费时间很长，至此对Kafka的压力就很大；

在Kafka中，每个消费者都对应一个消费者组，如果Kafka想要消费消息，那么需要指定消费那个topic的消息以及自己的消费组id(groupId)

在消费者组中，多个实例共同订阅若干个topic，实现共同消费，同一个组下的每个实例都配置有相同的ID，被分配不同的订阅分区，当某个实例挂掉的时候，其他实例会自动地承担起它负责消费的分区

消费者组的消费规则：

同一个消费者组的消费者都订阅同一个主题，所以消费者组中的多个消费者可以共同消费一个主题的所有数据

为了避免数据被重复消费，topic的一个分区的数据只能被组中的一个消费者消费，不能两个消费者同时消费一个分区的数据，但是一个消费者可以消费多个分区的数据

消费者组中的消费者数量最好不要超过topic的分区数，会导致多出来的消费者无法消费数据，资源浪费

补充：kafka中的日志（消息）存储

一个topix下大致有如下的文件结构

其中.log文件保存的实际数据；

.index文件保存的是偏移量；

.timeindex文件保存的是时间戳索引文件

补充：kafka怎么指定消费者组中的消费者消费哪一个分区的数据

• RoundRobinAssignor（轮询分配策略）
• RangeAssignor（范围分配策略）按照topic的分区数计算出给每个消费者应该分配的分区数量，分配的原则就是尽可能平均的分配，如果新增或者移除消费者组的消费者，会导致每个消费者都需要重新建立新的分区节点的链接，更新本地的分区缓存，效率低
• StickyAssignor（粘性分区）每个组员都保留分配给自己的分区信息，如果有消费者加入或退出，一般情况下退出45s后，才会进行重新分配，尽可能保证消费者原有的分区不表，重新对加入或退出的分区进行分配
• CooperativeStickyAssignor

97、Kafka高吞吐的原理

1、顺序读写磁盘，Kafka消息是不断追加到文件中的，使得Kafka可以充分利用磁盘的互相内需读写性能，不需要次哦按磁头的寻道时间，快速读写

2、Kafka中的topic被分为了多个partition，每个partition又分为多个segment，一个队列的消息实际上是保存在多个片段文件中通过分段的方式，每次文件操作都是对一个小文件进行操作，增加了并行处理的能力

3、Kafka的瓶颈不是cpu或者磁盘，而是网络带宽

98、说下Kafka中的Partition?

Kafka的partirion过程是将topic划分为多个独立的数据片段的过程，每个parririon是一个有序的不可变的消息队列，消息按照生产者的发送顺序一次追加到partition中，每个partition在物理上对应一个独立的日志文件，被分成多个segment

Partition的作用在于：

实现消息的水平扩展：Kafka可以在多个Broker上并行处理不同Partition的消息，提高了整个系统的吞吐量。

实现数据的持久化：每个Partition都会被复制到多个Broker上，确保数据的可靠性和冗余。

实现消息的顺序性：在同一个Partition中，消息的顺序是有序的，保证了消息的有序性处理。

每个Partition都有一个唯一的标识符（Partition ID），并且可以配置多个副本（Replica），其中一个为Leader副本，其它副本为Follower副本。Leader副本负责处理来自Producer和Consumer的请求，Follower副本用于备份和故障转移。

在生产者发送消息时，可以选择指定消息要发送到的Partition，如果没有指定，Kafka会根据某种策略（如Hash值）将消息平均分配到各个Partition中。而在消费者消费消息时，可以订阅一个或多个Partition，每个消费者只会消费其中一个Partition上的消息。

99、如何使用Kafka实现实时数据流处理？

需要创建一个Kafka的producer将元数据推送到Kafka potic中，再使用Kafka的consumer从topic中订阅消息，并将其传递给流处理引擎Spark或者Flink，对接受到的消息进行实时计算和转换，将结果写回固定的外部存储

100、Flink的checkpoint和Kafka的offset关联是什么

Flink的checkpoint用于记录Flink的应用程序的状态，而Kafka offset用于记录消费者的topic的位置，两者相互结合，以确保在故障恢复后不会重复处理Kafka中的消息

补充：Kafka中的数据模型

顾名思义就是Kafka的架构；

补充：页缓存

页缓存用来减少磁盘IO操作，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变成对内存的访问；

读操作：当一个进程准备读取磁盘上的文件时候，会先查看待读取的数据所在的页是否在页缓存上，如果命中则直接返回，从而直接避免了对物理磁盘的IO；如果没有命中，则会向磁盘发起读取请求并将读取的数据写入页缓存，再将数据返回给进程；

写操作：同样的，当一个进程需要将数据写入到磁盘中时候，也会监测数据是否在页缓存中，如果不在，则会先在页缓存中添加相应的页，最后将数据写入对应的页，被修改后的页也变成了脏页，系统会在合适的时间把脏页中的数据写入磁盘，保证数据一致性、

Kafka中大量使用了页缓存，这是Kafka实现高吞吐的重要因此之一。

补充：零拷贝

零拷贝并不是不需要拷贝，而是说在IO读写过程中减少不必要的拷贝次数，通常一个应用程序会不断在用户态操作和内核态操作之间谢欢，如果存在大量的用户态和内核态的切换，IO性能就会急剧下降，所以就存在零拷贝操作，减少用户态和内核态的切换，提高效率

补充：Kafka为什么可以实现高效传输数据

1、利用Partition实现并行处理

  一个topic包好多个partition，不同的partition位于不同的节点上，从而可以实现磁盘间的并行处理，充分发挥多磁盘的优势。

2、顺序写磁盘（提供预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快）

  影响磁盘的关键因素是磁盘的完成一个IO请求所花费的时间，它由寻道时间、旋转时间和数据传输时间三部分构成。Kafka中都通过追加的方式尽可能的将随机IO转换为顺序IO，以此来降低寻址和旋转延时

3、充分利用页缓存Page Cache

引入cache层是为了提高linux操作系统对磁盘访问的性能，cache层在内存中缓存了磁盘上的部分数据，免除了对底层磁盘的操作，提高了性能（liunx的实现中，文件cache层分为两个层面，一个page cache，另一个是buffer cache，每个page chche有多个buffer chche，Page Cache 主要用来作为文件系统上的文件数据的缓存来用，尤其是针对当进程对文件有 read/write 操作的时候。Buffer Cache 则主要是设计用来在系统对块设备进行读写的时候，对块进行数据缓存的系统来使用。）

broker收到数据后，写磁盘时只是将数据写入page chche中，并不能保证数据一定会完全写入磁盘，可能会造成页缓存中的数据为写入磁盘从而造成数据丢失

4、零拷贝（减少拷贝次数）

零拷贝是一种为了解决数据从内核缓存到用户缓存的CPU拷贝产生的性能消耗的技术。

  Kafka中存在大量的网络数据持久化到磁盘和磁盘文件需要通过网络发送的过程，影响Kafka的整体吞吐量

DMA：直接存储器，是一个无需CPU参与，让外设和系统内存之间进行双向数据传输的硬件机制，可以使系统CPU从实际的IO数据传输过程中脱离出来，提高系统的吞吐率

  当数据从磁盘经过DMA到内核缓存后，为了减少CPU的拷贝性能损耗，操作系统会将该内核缓存与用户层，减少以此CPU拷贝的过程，

网络数据持久化到磁盘中：

补充：Kafka中的offset

在Kafka中，每个topic分区下的每一条消息都被赋予了一个唯一的ID数值，用于标识它在分区中的位置，这个ID数值，就被称为唯一，也叫做偏移量，一旦消费被写入分区日志中，它的位移将不能被修改

补充：削峰、异步、解耦

削峰：就是缓冲瞬时的突发流量，使其平滑，对于上游发送能力很强的系统，若没有消息中间件的保护，脆弱的下游系统可能会被直接压垮导致雪崩

异步：不用同步等待下游将数据处理完，将喜喜发送到消息队列中即可返回，不阻碍主流程

解耦：

补充：Kafka与Zookeeper的联系

kafka集群受zk管理，所有kakfa broker节点一起到zk上注册一个临时节点，最终只会有一个kafka broker注册成功，其他都会失败，所以这个成功在zk上注册临时节点的kafka broker会成为kafka broker controller，其他的kafka broker都叫做kafka breoker follower、

补充：kafka注意事项

kafka底进行数据的写入时候，写的时候并不是直接写入文件，而是先写入缓冲区，当缓冲区满了时候，再将数据顺序写入文件，无需定位文件中的某一个位置进行写入，那么就减少了磁盘的查询，数据定位的过程，比随机写入高效