电脑系统江门网站seo推广

当前位置： 首页 > news >正文

电脑系统,江门网站seo推广,彩票计划网站怎么做,网站主体域名Kafka 面试题 Q:讲一下Kafka。 Kafka 入门一篇文章就够了 Kafka的简单理解 Q:消息队列#xff0c;有哪些使用场景及用途#xff1f; 解耦#xff0c;削峰#xff0c;限流。 Q:Kafka相对其他消息队列#xff0c;有什么特点#xff1f; 持久化#xff1a;Kafka的持久化…Kafka 面试题 Q:讲一下Kafka。 Kafka 入门一篇文章就够了 Kafka的简单理解 Q:消息队列有哪些使用场景及用途 解耦削峰限流。 Q:Kafka相对其他消息队列有什么特点 持久化Kafka的持久化能力比较好通过磁盘持久化。而RabbitMQ是通过内存持久化的。 吞吐量Rocket的吞吐量非常高。Kafka的吞吐量也特别高。基本都是单机十万级别。 消息处理RabbitMQ的消息不支持批量处理而RocketMQ和Kafka支持批量处理。 高可用RabbitMQ采用主从模式。Rocket支持多主多从。Kafka基于Replication多副本ISR选举Leader。 低延时Kafka生产和消费的延时都很低是毫秒级别的。 事务RocketMQ支持事务消息而Kafka和RabbitMQ不支持。 详情见 https://www.cnblogs.com/expiator/p/10023649.html Q:Kafka有哪些缺点 无法弹性扩容对partition的读写都在partition leader所在的broker如果该broker压力过大也无法通过新增broker来解决问题扩容成本高集群中新增的broker只会处理新topic如果要分担老topic-partition的压力需要手动迁移partition这时会占用大量集群带宽partition过多会使得性能显著下降。broker上partition过多让磁盘顺序写几乎退化成随机写。kafka不支持事务消息。 参考资料 https://blog.csdn.net/zjjcchina/article/details/122359951 Q:Kafka有哪些模式 如果一个生产者或者多个生产者产生的消息能够被多个消费者同时消费的情况这样的消息队列称为发布订阅模式的消息队列 Q:Kafka作为消息队列有哪些优势 分布式的消息系统。 高吞吐量。即使存储了许多TB的消息它也保持稳定的性能。 数据保留在磁盘上因此它是持久的。 Q:kafka的吞吐量为什么高Kafka为什么处理速度会很快 零拷贝Kafka 实现了零拷贝原理来快速移动数据避免了内核之间的切换。 消息压缩、分批发送Kafka 可以将数据记录分批发送从生产者到文件系统Kafka 主题日志到消费者可以端到端的查看这些批次的数据。 批处理能够进行更有效的数据压缩并减少 I/O 延迟。 页缓存页缓存是操作系统实现的一种主要磁盘缓存用来减少对磁盘I/O的操作。 顺序读写Kafka 采取顺序写入磁盘的方式避免了随机磁盘寻址的浪费。顺序写入磁盘比随机写入快很多倍。 详情见 https://mp.weixin.qq.com/s/iJJvgmwob9Ci6zqYGwpKtw Q:讲一下页缓存 页缓存是操作系统实现的一种主要磁盘缓存用来减少对磁盘I/O的操作。 当一个进程准备读取磁盘上的文件内容时操作系统会先查看待读取的数据所在的页(page)是否在页缓存(page cache)中如果存在(命中)则直接返回数据从而避免了对物理磁盘的I/O操作。 如果没有命中则操作系统会向磁盘发起读取请求并将读取到的数据页存入页缓存之后再将数据返回给进程。 同样的如果一个进程需要将数据写入到磁盘那么操作系统也会检测数据对应的页是否在页缓存中如果不存在则会先在页缓存中添加相应的页最后将数据写入对应的页。被修改过后的页也就变成了脏页操作系统会在合适的时间把脏页中的数据写入磁盘以保持数据的一致性。 参考资料《深入理解kafka核心设计与实践原理》 Q:讲一下Kafka中的零拷贝。 传统的IO流程包括read以及write的过程 read:将数据从磁盘读取到内核缓存区中在拷贝到用户缓冲区 write:先将数据写入到socket缓冲区中最后写入网卡设备 数据的拷贝整个过程耗费的时间比较高。 而零拷背利用了Linux的sendFile技术。 sendfile表示在两个文件描述符之间传输数据避免了数据从内核缓冲区和用户缓冲区之间的拷贝操作从内核缓冲区就发到socket缓冲区省去了进程切换和一次数据拷贝性能变得更好。 Q:讲下kafka的三种语义 「消息传递语义」就是 Kafka 提供的 Producer 和 Consumer 之间的消息传递过程中消息传递的保证性。 至少一次:at-least-once 这种语义有可能会对数据重复处理。 (1): 设置enable.auto.commit为false禁用自动提交offset (2): 消息处理完之后手动调用consumer.commitSync()提交offset 这种方式是在消费数据之后手动调用函数consumer.commitSync()异步提交offset有可能处理多次的场景是消费者的消息处理完并输出到结果库但是offset还没提交这个时候消费者挂掉了再重启的时候会重新消费并处理消息所以至少会处理一次 至多一次:at-most-once 这种语义有可能会丢失数据。 至多一次消费语义是kafka消费者的默认实现。 (1): enable.auto.commit设置为true。 (2): auto.commit.interval.ms设置为一个较低的时间范围。 由于上面的配置此时kafka会有一个独立的线程负责按照指定间隔提交offset。 消费者的offset已经提交但是消息还在处理中(还没有处理完)这个时候程序挂了导致数据没有被成 功处理再重启的时候会从上次提交的offset处消费导致上次没有被成功处理的消息就丢失了。 仅一次:exactly-once 这种语义可以保证数据只被消费处理一次。 (1): 将enable.auto.commit设置为false禁用自动提交offset (2): 使用consumer.seek(topicPartitionoffset)来指定offset (3): 在处理消息的时候要同时保存住每个消息的offset。 以原子事务的方式保存offset和处理的消息结 果这个时候相当于自己保存offset信息了把offset和具体的数据绑定到一块数据真正处理成功的时 候才会保存offset信息。 这样就可以保证数据仅被处理一次了。
参考资料https://blog.csdn.net/lt326030434/article/details/119881907 kafka生产者 Q:Kafka的生产者是如何发送消息的 生产者的消息是先被写入分区中的缓冲区中然后分批次发送给 Kafka Broker。 异步发送消息的同时能够对异常情况进行处理生产者提供了Callback 回调。 Q:Kafka生产者发送消息有哪些分区策略 Kafka 的分区策略指的就是将生产者发送到哪个分区的算法。 有顺序轮询、随机轮询、key-ordering 策略。 编写一个类实现org.apache.kafka.clients.Partitioner接口。实现内部两个方法partition()和close()。然后显式地配置生产者端的参数partitioner.class 常见的策略 轮询策略默认。保证消息最大限度地被平均分配到所有分区上。 随机策略。随机策略是老版本生产者使用的分区策略在新版本中已经改为轮询了。 按key分区策略(key-ordering 策略)。key可能是uid或者订单id将同一标志位的所有消息都发送到同一分区这样可以保证一个分区内的消息有序。 Kafka 中每条消息都会有自己的key一旦消息被定义了 Key那么你就可以保证同一个 Key 的所有消息都进入到相同的分区里面由于每个分区下的消息处理都是有顺序的故这个策略被称为按消息键保序策略。 其他分区策略。如基于地理位置的分区策略。 Kafka broker Q:Kafka为什么要分区 实现负载均衡和水平扩展。 Kafka可以将主题(Topic)划分为多个分区Partition会根据分区规则选择把消息存储到哪个分区中只要如果分区规则设置的合理那么所有的消息将会被均匀的分布到不同的分区中这样就实现了负载均衡和水平扩展。另外多个订阅者可以从一个或者多个分区中同时消费数据以支撑海量数据处理能力。 Q:Kafka是如何在Broker间分配分区的 在broker间平均分布分区副本; 假设有6个broker打算创建一个包含10个分区的Topic复制系数为3那么Kafka就会有30个分区副本它可以被分配给这6个broker这样的话每个broker可以有5个副本。要确保每个分区的每个副本分布在不同的broker上面; 假设Leader分区0会在broker1上面Leader分区1会在broker2上面Leder分区2会在broker3上面。 接下来会分配跟随者副本。如果分区0的第一个Follower在broker2上面第二个Follower在broker3上面。 分区1的第一个Follower在broker3上面第二个Follower在broker4上面。。 顺序性 Q:Kafka如何保证消息的顺序性 Kafka 可以保证同一个分区里的消息是有序的。也就是说消息发送到一个Partition 是有顺序的。 Q:Kafka多个分区如何保证消息的顺序性 生产者在发消息的时候指定partition keykafka对其进行hash计算根据计算结果决定放入哪个partition。这样partition key计算结果相同的消息会放在同一个partition。此时partition数量仍然可以设置多个提升topic的整体吞吐量。 kafka消费者 Q:你们的kafka有多少个分区有多少个消费者有多少个服务实例 有5个分区5个消费者。 分区和消费者的数量相等最好。不要让消费者的数量超过主题分区的数量多余的消费者只会被闲置。 Q:kafka 消费者的消费策略有哪些 Kafka 有四种主流的分区分配策略 Range 、 RoundRobin 、 Sticky 、 CooperativeSticky 。 可以通过配置参数 partition.assignment.strategy 修改分区的分配策略。默认策略是 Range CooperativeSticky 。 Kafka 可以同时使用 多个分区分配策略。 Range 按顺序。 分区有0-6消费者有0-2那么每个消费者分7/32个分区剩下的按序分配。 消费者0P0,P1,P2 消费者1P3,P4 消费者2P5,P6 如果消费者0挂了 那么 消费者10123 消费者2456 缺点大数据环境容易产生数据倾斜。 RoundRobin 轮询排序Sticky粘性分区。 再分区的尽量少的去改变旧的分配方案。 举个例子现在的分区方案 C0:P0,P1,P2 C1:P3,P4 C2:P5,P6 消费者C0挂了之后 C1:P0,P1,P3,P4 C2:P5,P6,P2 range是按序分配而sticky是随机的。不一定就是0123456 尽量均匀可以减少再分区的开销。CooperativeSticky多种配合使用 参考资料 https://blog.csdn.net/u011066470/article/details/124090278 Q:Kafka的偏移量是什么 消费者每次消费数据的时候消费者都会记录消费的物理偏移量offset的位置。等到下次消费时他会接着上次位置继续消费 Q:Kafka的消费者群组Consumer Group订阅了某个Topic假如这个Topic接收到消息并推送那整个消费者群组能收到消息吗 http://kafka.apache.org/intro Kafka官网中有这样一句Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. 表示推送到topic上的record会被传递到已订阅的消费者群组里面的一个消费者实例。 Q:kafka出现消息积压有哪些原因怎么解决如何提高Kafka的消费速度 出现消息积压可能是因为消费的速度太慢。 扩容消费者。之所以消费延迟大就是消费者处理能力有限可以增加消费者的数量。 扩大分区。一个分区只能被消费者群组中的一个消费者消费。消费者扩大分区最好多随之扩大。 消费者重平衡 Q:讲一下kafka的 Rebalance重平衡.重平衡有什么用哪些场景下会发生重平衡 分区的所有权从一个消费者转到其他消费者的行为称为重平衡。 新加入群组的消费者实例分摊了之前的消费者的部分分区消息。 或者消费者组内某个消费者实例挂掉后其他消费者实例自动重新分配订阅主题分区。 Rebalance 是 Kafka 消费者端实现高可用性、伸缩性的重要手段。 消费者通过向Kafka Broker发送心跳来维护自己是消费者组的一员并确认其拥有的分区。对于不同的消费群体来说其组织协调者可以是不同的。只要消费者定期发送心跳就会认为消费者是存活的并处理其分区中的消息。当消费者检索记录或者提交它所消费的记录时就会发送心跳。 如果过了一段时间 Kafka 停止发送心跳了会话Session就会过期组织协调者就会认为这个 Consumer 已经死亡就会触发一次重平衡。如果消费者宕机并且停止发送消息组织协调者会等待几秒钟确认它死亡了才会触发重平衡。在这段时间里死亡的消费者将不处理任何消息。在清理消费者时消费者将通知协调者它要离开群组组织协调者会触发一次重平衡尽量降低处理停顿。 消费失败 Q:kafka消费时如果处理失败怎么办 先重试几次。如果重试还是不成功可以根据业务选择 处理失败的放到死信队列其他topic即可不断重试。处理失败的记录到一张表里面同时发送告警信息给开发人员。处理失败的如果是不重要的数据直接跳过。(谨慎选择) 消息丢失 Q:讲一下Kafka的ack机制。 acks 参数指定了要有多少个分区副本接收消息生产者才认为消息是写入成功的。此参数对消息丢失的影响较大。 如果 acks 0就表示生产者也不知道自己产生的消息是否被服务器接收了它才知道它写成功了。如果发送的途中产生了错误生产者也不知道它也比较懵逼因为没有返回任何消息。这就类似于 UDP 的运输层协议只管发服务器接受不接受它也不关心。 如果 acks 1只要集群的 Leader 接收到消息就会给生产者返回一条消息告诉它写入成功。如果发送途中造成了网络异常或者 Leader 还没选举出来等其他情况导致消息写入失败生产者会受到错误消息这时候生产者往往会再次重发数据。因为消息的发送也分为 同步 和 异步Kafka 为了保证消息的高效传输会决定是同步发送还是异步发送。如果让客户端等待服务器的响应通过调用 Future 中的 get() 方法显然会增加延迟如果客户端使用回调就会解决这个问题。 如果 acks all这种情况下是只有当所有参与复制的节点都收到消息时生产者才会接收到一个来自服务器的消息。不过它的延迟比 acks 1 时更高因为我们要等待不只一个服务器节点接收消息。 参考资料 https://juejin.im/post/5ddf5659518825782d599641 Q:Kafka如何避免消息丢失如何保证消息的可靠性传输 1.生产者丢失消息的情况 生产者(Producer) 调用send方法发送消息之后消息可能因为网络问题并没有发送过去。 所以我们不能默认在调用send方法发送消息之后消息消息发送成功了。为了确定消息是发送成功我们要判断消息发送的结果。 可以采用为其添加回调函数的形式获取回调结果。 如果消息发送失败的话我们检查失败的原因之后重新发送即可 可以设置 Producer 的retries重试次数为一个比较合理的值一般是 3 但是为了保证消息不丢失的话一般会设置比较大一点。 设置完成之后当出现网络问题之后能够自动重试消息发送避免消息丢失。 2.消费者丢失消息的情况 当消费者拉取到了分区的某个消息之后消费者会自动提交了 offset。自动提交的话会有一个问题 试想一下当消费者刚拿到这个消息准备进行真正消费的时候突然挂掉了消息实际上并没有被消费但是 offset 却被自动提交了。 手动关闭闭自动提交 offset每次在真正消费完消息之后之后再自己手动提交 offset 。 3.Kafka丢失消息 a.假如 leader 副本所在的 broker 突然挂掉那么就要从 follower 副本重新选出一个 leader 但是 leader 的数据还有一些没有被 follower 副本的同步的话就会造成消息丢失。 因此可以设置ackall。 b.设置 replication.factor 3 为了保证 leader 副本能有 follower 副本能同步消息我们一般会为 topic 设置 replication.factor 3。这样就可以保证每个 分区(partition) 至少有 3 个副本。虽然造成了数据冗余但是带来了数据的安全性。 c.设置min.insync.replicas 2。最小同步副本数。对于一个包含3个副本的主题如果min.insync.replicas设置为2那么至少要存在两个同步副本才能向分区写入数据。 如果2个副本不可用那么broker就会停止接受生产者的请求尝试发送数据的生产者会收到异常。 详情参考《kafka权威指南》第六章。可靠的数据传递。 https://blog.csdn.net/qq_34337272/article/details/104903388?fps1locationNum2 Q:Kafka写入的数据如何保证不丢失kafka的数据写到主节点后还没来得及复制就挂掉了那数据会丢失么 所以如果要让写入Kafka的数据不丢失你需要要求几点 (1)每个Partition都至少得有1个Follower在ISR列表里跟上了Leader的数据同步。 最小同步副本数 min.insync.replicas 最小同步副本数, 表示的是 ISR 列表里面最小的同步副本个数,默认是1。 这个配置再加上 acks-1/all 可以设置高可靠性了。 特别需要注意这个配置是用来设置同步副本个数的下限的, 并不是只有 min.insync.replicas 个副本同步成功就返回ack。 只要你acks-1/all 就意味着你ISR里面的副本必须都要同步成功。 (2)每次写入数据的时候都要求至少写入Partition Leader成功同时还有至少一个ISR里的Follower也写入成功才算这个写入是成功了。 (3)如果不满足上述两个条件那就一直写入失败让生产系统不停的尝试重试直到满足上述两个条件然后才能认为写入成功 按照上述思路去配置相应的参数才能保证写入Kafka的数据不会丢失。 需要保证每次写数据必须是leader和follower都写成功了才能算是写成功保证一条数据必须有两个以上的副本。 这个时候万一leader宕机就可以切换到那个follower上去那么Follower上是有刚写入的数据的此时数据就不会丢失了。 详情见 https://juejin.cn/post/6844903790789787655 https://mp.weixin.qq.com/s/CXrvy7Moj2ElPm_CJ-gH2A 可靠性、副本 Q:Kafka怎么保证可靠性高可用 多副本以及ISR机制。 在Kafka中主要通过ISR机制来保证消息的可靠性。 ISRin sync replica是Kafka动态维护的一组同步副本在ISR中有成员存活时只有这个组的成员才可以成为leader内部保存的为每次提交信息时必须同步的副本acks all时每当leader挂掉时在ISR集合中选举出一个follower作为leader提供服务当ISR中的副本被认为坏掉的时候会被踢出ISR当重新跟上leader的消息数据时重新进入ISR。 详情见 https://www.jianshu.com/p/ebeaa7593d83 Q:讲一下kafka的副本机制AR、ISR、OSR (1)AR副本集合 (Assigned Replicas)分区Partition中的所有Replica组成AR副本集合。 (2)ISR副本集合In Sync Replica所有与Leader副本能保持一定程度同步的Replica组成ISR副本集合其中也包括 Leader副本。 (3)OSR副本集合 (Out-of-Sync Replied) 与Leader副本同步滞后过多的Replica组成OSR副本集合。 Q:Kafka是读写分离的么 不是的。 在Kafka中一个Topic的每个Partition都有若干个副本副本分成两类领导者副本「Leader Replica」和追随者副本「Follower Replica」。每个分区在创建时都要选举一个副本作为领导者副本其余的 副本作为追随者副本。 在Kafka中Follower副本是不对外提供服务的。也就是说任何一个Follower副本都不能响应客户端的 读写请求。 所有的读写请求都必须先发往Leader副本所在的Broker,由该Broker负责处理。Follower副本 不处理客户端请求它唯一的任务就是从Leader副本异步拉取消息并写入到自己的提交日志中从而实现 与Leader副本的同步。 Q:什么是HW HWhigh watermark副本的高水印值replica中leader副本和follower副本都会有这个值通过它可以得知副本中已提交或已备份消息的范围leader副本中的HW决定了消费者能消费的最新消息能到哪个offset。 HW: 即高水位它标识了一个特定的消息偏移量offset,消费者只 能拉取到这个水位offset之前的消息。 Q:什么是LEO? LEOlog end offset日志末端位移代表日志文件中下一条待写入消息的offset这个offset上实际是没有消息的。不管是leader副本还是follower副本都有这个值。 LEO它标识当前日志文件中下一条待写入的消息的offset,在ISR 副本集合中的每个副本都会维护自身的LEO。 参考资料https://www.cnblogs.com/youngchaolin/p/12641463.html Q:Kafka怎么保证一致性(存疑) 一致性定义若某条消息对client可见那么即使Leader挂了在新Leader上数据依然可以被读到。 HW-HighWaterMark: client可以从Leader读到的最大msg offset即对外可见的最大offset HWmax(replica.offset) 对于Leader新收到的msgclient不能立刻消费Leader会等待该消息被所有ISR中的replica同步后更新HW此时该消息才能被client消费这样就保证了如果Leader fail该消息仍然可以从新选举的Leader中获取。 对于来自内部Broker的读取请求没有HW的限制。同时Follower也会维护一份自己的HWFolloer.HW min(Leader.HW, Follower.offset) 详情见https://www.jianshu.com/p/f0449509fb11 重复消费 Q:Kafka怎么处理重复消息怎么避免重复消费 偏移量offset:消费者每次消费数据的时候消费者都会记录消费的物理偏移量offset的位置。等到下次消费时他会接着上次位置继续消费。 一般情况下kafka重复消费都是由于未正常提交offset造成的比如网络异常消费者宕机之类的。 把Kafka消费者的配置enable.auto.commit设为false禁止Kafka自动提交offset从而避免了提交失败而导致永远重复消费的问题。 怎么避免重复消费将消息的唯一标识保存起来每次消费时判断是否处理过即可。 Q:如何保证消息不被重复消费如何保证消息消费的幂等性 怎么保证消息队列消费的幂等性其实还是得结合业务来思考有几个思路 比如你拿个数据要写库你先根据主键查一下如果这数据都有了你就别插入了update一下好吧。 比如你是写 Redis那没问题了反正每次都是 set天然幂等性。 如果是复杂一点的业务那么每条消息加一个全局唯一的 id类似订单 id 之类的东西然后消费到了之后先根据这个 id 去比如 Redis 里查一下之前消费过吗 如果没有消费过你就处理然后这个 id 写 Redis。如果消费过了那你就别处理了保证别重复处理相同的消息即可。 参考资料https://www.jianshu.com/p/8d1c242872a4 消息pull、push Q:Kafka消息是采用pull模式还是push模式 生产者是push而消费者是pull模式。 Q:pull模式和push模式各有哪些特点 push模式即时性可以在broker获取消息后马上送达消费者。 而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。 消费者可以自行决定消费的速率、是否批量处理模式处理消息. pull 模式不足之处是如果 kafka 没有数据消费者可能会一直轮询一直返回空数据。 针对这一点 Kafka 的消费者在消费数据时会传入一个时长参数 timeout如果当前没有数据可供消费 consumer 会等待一段时间之后再返回。 低延时、高吞吐量 Q:针对 Kafka 线上系统, 你是如何进⾏调优的? 「吞吐量」和「延时」是⾮常重要的优化指标。 吞吐量 TPS是指 Broker 端或 Client 端每秒能处理的消息数越⼤越好。 延时表示从 Producer 端发送消息到 Broker 端持久化完成到 Consumer 端成功消费之间的时间间隔。与吞吐量 TPS 相反延时越短越好。 总之⾼吞吐量、低延时是我们调优 Kafka 集群的主要⽬标。 Q:针对 Kafka 线上系统, 如何降低延时? 降低延时的⽬的就是尽量减少端到端的延时。 调整 Producer 端和 Consumer 端的参数配置。 对于 Producer 端此时我们希望可以快速的将消息发送出去必须设置 linger.ms0同时关闭压缩另外设置 acks 1减少副本同步时间。 ⽽对于 Consumer 端我们只保持 fetch.min.bytes1 即 Broker 端只要有能返回的数据就⽴即返回给 Consumer减少延时。 linger.ms表示批次缓存时间如果数据迟迟未达到batch.sizesender 等待 linger.ms 之后就会发送数据。单位 ms默认值是 0意思就是消息必须立即被发送。 如果设置的太短会导致频繁网络请求吞吐量下降 如果设置的太长会导致一条消息需要等待很久才能被发送出去增加网络延时。 所以适当增加会提高吞吐量建议10~100毫秒。 fetch.min.bytes表示只要 Broker 端积攒了多少数据就可以返回给 Consumer 端。默认值1字节适当增加该值为1kb或者更多。 存储 Q:Kafka是如何存储消息的 Kafka使用日志文件的方式来保存生产者和发送者的消息每条消息都有一个 offset 值来表示它在分区中的偏移量。 Kafka中存储的一般都是海量的消息数据为了避免日志文件过大 一个分片并不是直接对应在一个磁盘上的日志文件而是对应磁盘上的一个目录。 数据存储设计的特点在于以下几点 1Kafka把主题中一个分区划分成多个分段的小文件段通过多个小文件段就容易根据偏移量查找消息、定期清除和删除已经消费完成的数据文件减少磁盘容量的占用 2采用稀疏索引存储的方式构建日志的偏移量索引文件并将其映射至内存中提高查找消息的效率同时减少磁盘IO操作 3Kafka将消息追加的操作逻辑变成为日志数据文件的顺序写入极大的提高了磁盘IO的性能 参考https://www.jianshu.com/p/3e54a5a39683 参考资料https://blog.csdn.net/zhangxm_qz/article/details/87636094 Q:讲一下Kafka集群的Leader选举机制。 Kafka在Zookeeper上针对每个Topic都维护了一个ISRin-sync replica—已同步的副本的集合集合的增减Kafka都会更新该记录。如果某分区的Leader不可用Kafka就从ISR集合中选择一个副本作为新的Leader。 Q:在 Kafka 中 Zookeeper 作⽤是什么 ZooKeeper主要⽤来「负责 Kafka集群元数据管理集群协调⼯作」在每个 Kafka 服务器启动的时候去连接并将⾃⼰注册到 Zookeeper类似注册中⼼ Kafka 使⽤ Zookeeper 存放「集群元数据」、「集群成员管理」、 「Controller 选举」、「其他管理类任务」等。 1集群元数据Topic 对应 Partition 的所有数据都存放在 Zookeeper 中且以 Zookeeper 保存的数据为准。 2集群成员管理Broker 节点的注册、删除以及属性变更操作等。主要包括两个⽅⾯成员数量的管理主要体现在新增成员和移除现有成员单个成员的管理如变更单个 Broker 的数据等。 3Controller 选举即选举 Broker 集群的控制器 Controller。其实它除了具有⼀般 Broker 的功能之外还具有选举主题分区 Leader 节点的功能。在启动 Kafka系统时其中⼀个 Broker 会被选举为控制器负责管理主题分区和副本状态还会执⾏分区重新分配的管理任务。如果在 Kafka 系统运⾏过程中当前的控制器出现故障导致不可⽤那么 Kafka 系统会从其他正常运⾏的 Broker 中重新选举出新的控制器。 4其他管理类任务包括但不限于 Topic 的管理、参数配置等等。 Q:Kafka 3.X 「2.8版本开始」为什么移除 Zookeeper 的依赖 1集群运维层⾯Kafka 本身就是⼀个分布式系统如果还需要重度依赖 Zookeeper集群运维成本和系统复杂度都很⾼。 2集群性能层⾯Zookeeper 架构设计并不适合这种⾼频的读写更新操作, 由于之前的提交位移的操作都是保存在 Zookeeper ⾥⾯的这样的话会严重影响 Zookeeper 集群的性能。 参考资料 https://juejin.cn/post/6844903790789787655 《kafka面试连环炮》 《kafka权威指南》 《深入理解kafka核心设计与实践原理》