高性能 Kafka 及常见面试题(2)，彻底帮你搞懂

最新推荐文章于 2024-11-03 12:44:11 发布

2401_84170522

最新推荐文章于 2024-11-03 12:44:11 发布

阅读量874

点赞数 21

分类专栏： 2024年程序员学习文章标签： kafka linq 分布式

本文链接：https://blog.csdn.net/2401_84170522/article/details/137803859

版权

2024年程序员学习专栏收录该内容

70 篇文章 1 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

这些技术在 Kafka 的设计和实现中发挥了重要作用，帮助 Kafka 实现了高性能、高吞吐量的特性。在使用 Kafka 时，可以根据具体的场景和需求，结合这些技术来进行性能优化和调优。

零拷贝

当使用零拷贝技术时，数据在内核空间和用户空间之间的传输是通过以下几个关键组件和步骤完成的：

内核缓冲区（Kernel Buffer）：内核缓冲区是位于内核空间的一块内存区域，用于存储从用户空间写入的数据或从网络接收的数据。
用户缓冲区（User Buffer）：用户缓冲区是位于用户空间的一块内存区域，用于存储应用程序读取或写入的数据。
零拷贝系统调用：操作系统提供了一些特定的系统调用，例如sendfile()和writev()，用于在内核空间和用户空间之间实现数据的零拷贝传输

下面是零拷贝技术在 Kafka 中的更详细工作流程：

生产者端

生产者将要发送的消息写入发送缓冲区，该缓冲区位于用户空间
生产者调用零拷贝系统调用（如sendfile()或writev()），将发送缓冲区的数据直接传输到内核缓冲区
内核将数据从内核缓冲区传输到网络套接字缓冲区，而无需将数据从内核空间复制到用户空间

Kafka 服务端

客户端发送的消息到达 Kafka 服务端，数据存储在网络套接字缓冲区
Kafka 服务端使用零拷贝技术，将网络套接字缓冲区的数据直接复制到内核缓冲区
Kafka 服务端根据配置的存储策略，将数据写入磁盘或存储设备

消费者端

消费者从网络接收消息，数据存储在接收缓冲区（Receive Buffer）
消费者使用零拷贝技术，直接从接收缓冲区读取数据，而无需将数据从内核空间复制到用户空间
消费者对数据进行处理或存储，完成消费过程

通过使用零拷贝技术，Kafka 避免了不必要的数据拷贝，提高了数据的传输效率和整体性能。它减少了CPU的开销和内存带宽的使用，特别在处理大量数据和高吞吐量的场景中表现出色。同时，零拷贝技术还可以减少系统调用的次数，进一步提高性能

常见面试题

本段参考自阿里技术这些年背过的面试题——Kafka篇

线上问题rebalance

因集群架构变动导致的消费组内重平衡，如果kafka集内节点较多，比如数百个，那重平衡可能会耗时导致数分钟到数小时，此时kafka基本处于不可用状态，对kafka的TPS影响极大。

产生的原因：

组成员数量发生变化
订阅主题数量发生变化
订阅主题的分区数发生变化

**组成员崩溃和组成员主动离开是两个不同的场景。**因为在崩溃时成员并不会主动地告知coordinator此事，coordinator有可能需要一个完整的session.timeout周期(心跳周期)才能检测到这种崩溃，这必然会造成consumer的滞后。可以说离开组是主动地发起rebalance；而崩溃则是被动地发起rebalance。

解决方案：

加大超时时间 session.timout.ms=6s
加大心跳频率 heartbeat.interval.ms=2s
增长推送间隔 max.poll.interval.ms=t+1 minutes

ZooKeeper 的作用

目前，Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务。之后，等 KIP-500 提案完成后，Kafka 将完全不再依赖于 ZooKeeper。

存放元数据是指主题分区的所有数据都保存在 ZooKeeper 中，其他“人”都要与它保持对齐。
成员管理是指 Broker 节点的注册、注销以及属性变更等。
Controller 选举是指选举集群 Controller，包括但不限于主题删除、参数配置等。

KIP-500 ，是使用社区自研的基于 Raft 的共识算法，实现 Controller 自选举。

同样是存储元数据，这几年基于Raft算法的etcd认可度越来越高。
越来越多的系统开始用它保存关键数据。比如，秒杀系统经常用它保存各节点信息，以便控制消费 MQ 的服务数量。还有些业务系统的配置数据，也会通过 etcd 实时同步给业务系统的各节点，比如，秒杀管理后台会使用 etcd 将秒杀活动的配置数据实时同步给秒杀 API 服务各节点。

Replica副本的作用

Kafka 只有 Leader 副本才能对外提供读写服务，响应 Clients 端的请求。Follower 副本只是采用拉(PULL)的方式，被动地同步 Leader 副本中的数据，并且在 Leader 副本所在的 Broker 宕机后，随时准备应聘 Leader 副本。

自 Kafka 2.4 版本开始，社区可以通过配置参数，允许 Follower 副本有限度地提供读服务。
之前确保一致性的主要手段是高水位机制，但高水位值无法保证 Leader 连续变更场景下的数据一致性，因此，社区引入了 Leader Epoch 机制，来修复高水位值的弊端。

为什么不支持读写分离?

自 Kafka 2.4 之后，Kafka 提供了有限度的读写分离。
场景不适用。读写分离适用于那种读负载很大，而写操作相对不频繁的场景。
同步机制。Kafka 采用 PULL 方式实现 Follower 的同步，同时复制延迟较大。

如何防止重复消费

代码层面每次消费需提交offset；
通过Mysql的唯一键约束，结合Redis查看id是否被消费，存Redis可以直接使用set方法；
量大且允许误判的情况下，使用布隆过滤器也可以

如何保证顺序消费

单 topic，单partition，单 consumer，单线程消费，吞吐量低，不推荐；
如只需保证单key有序，为每个key申请单独内存 queue，每个线程分别消费一个内存 queue 即可，这样就能保证单key（例如用户id、活动id）顺序性

如何解决积压消费

修复consumer，使其具备消费能力，并且扩容N台；
写一个分发的程序，将Topic均匀分发到临时Topic中；同时起N台consumer，消费不同的临时Topic

如何避免消息积压

提高消费并行度
批量消费
减少组件IO的交互次数
优先级消费

if (maxOffset - curOffset > 100000) {  
	// TODO 消息堆积情况的优先处理逻辑 
	// 未处理的消息可以选择丢弃或者打日志 
	return ConsumeConcurrentlyStatus.CONSUME\_SUCCESS;
}
// TODO 正常消费过程


**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
![img](https://img-blog.csdnimg.cn/img_convert/4f39c6cdfa5ff45386715b283800ef67.png)

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**



**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）**
[外链图片转存中...(img-se3KVCbu-1713211821122)]

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**