TP-Link 云计算开发工程师一面面经详解

阿贾克斯的黎明

于 2024-11-07 22:48:06 发布

阅读量795

点赞数 16

分类专栏：运维文章标签：面试

本文链接：https://blog.csdn.net/m0_57836225/article/details/143609588

版权

运维专栏收录该内容

143 篇文章

订阅专栏

最近参加了 TP-Link 云计算开发工程师岗位的面试，现将一面的经历分享如下。

一、自我介绍

在面试开始时，进行了自我介绍，简要介绍了自己的教育背景、专业技能和项目经验。

二、介绍实习

详细介绍了之前的实习经历，包括实习的公司、岗位、主要工作内容和取得的成果。

三、Kafka 版本及维护方式

1. Kafka 用的是什么版本？

- 回答时可以说明具体使用的 Kafka 版本号。不同版本可能在功能、性能和稳定性方面有所差异。

2. 是 Zookeeper 维护的还是 KRaft 维护的？

- Kafka 早期版本通常使用 Zookeeper 来进行集群管理和协调，但从较新的版本开始，逐渐引入了 KRaft（Kafka Raft）作为内置的共识机制来替代 Zookeeper。KRaft 提供了更高效、更可靠的集群管理方式。

四、Kafka ISR 列表的作用

Kafka 中的 ISR（In-Sync Replicas）列表是指与领导者副本保持同步的副本集合。其作用主要有以下几点：

1. 保证数据的可靠性：只有在 ISR 中的副本被认为是可靠的，当领导者副本出现故障时，可以从 ISR 中选举新的领导者，确保数据不会丢失。

2. 提高系统的可用性：即使部分副本出现故障，只要 ISR 中还有副本可用，Kafka 集群就可以继续提供服务。

3. 实现数据的一致性：确保消费者只能读取已经被完全复制到 ISR 中的数据，从而保证数据的一致性。

五、消费者组 Coordinator 的位置及选举方式

1. 消费者组的 Coordinator 分布在哪儿？

- Coordinator 通常分布在 Kafka 集群中的 broker 节点上。每个消费者组都会被分配一个 Coordinator，负责管理该消费者组的消费进度、分区分配等事务。

2. 是怎么选举出来的？

- Coordinator 的选举通常是通过哈希算法来确定的。根据消费者组的 ID 进行哈希计算，将消费者组分配到特定的 broker 节点上，该节点就成为该消费者组的 Coordinator。

六、Kafka 生产者保证消息不丢失及相关机制

1. Kafka 的生产者你是如何保证不丢失消息的？

- 可以通过以下几种方式保证生产者不丢失消息：

- 设置 acks 参数为 all 或 -1，确保所有副本都接收到消息后才认为消息发送成功。

- 配置 retries 参数，当消息发送失败时自动重试。

- 使用幂等性生产者或事务性生产者，确保消息的唯一性和可靠性。

2. At Once，AtLeast Once 是什么？

- At Once：表示生产者发送消息后，只等待服务器的确认，一旦确认就认为消息发送成功，不进行重试。这种方式可能会导致消息丢失，但性能较高。

- AtLeast Once：表示生产者发送消息后，会等待服务器的确认，如果没有收到确认则会进行重试。这种方式可以保证消息至少被发送一次，但可能会导致消息重复。

七、Kafka 消费者组自动提交

Kafka 的消费者组可以选择自动提交或手动提交消费位移。自动提交是指消费者在定期时间间隔内自动将消费位移提交到 Kafka 服务器，以记录消费进度。自动提交的优点是简单方便，但可能会导致重复消费或丢失消息的情况。如果对数据的准确性要求较高，可以选择手动提交消费位移，由应用程序控制提交的时机。

八、Kafka 消费者组重复消费及防止机制

1. Kafka 消费者组有没有可能重复消费？

- 有可能。例如，当消费者在自动提交消费位移之前出现故障，重新启动后可能会从上次提交的位置继续消费，导致重复消费已经处理过的消息。

2. 你有没有做相关的防止重复消费机制？

- 可以通过以下方式防止重复消费：

- 使用唯一的消息标识符，在消费消息时进行去重处理。

- 手动提交消费位移，确保只有在消息处理成功后才提交位移。

- 记录已处理消息的标识符或状态，在消费新消息时进行检查。

九、Zookeeper 避免脑裂

脑裂是指在分布式系统中，由于网络故障等原因导致集群分裂成多个小集群，每个小集群都有自己的领导者，从而导致数据不一致的情况。为了避免脑裂，Zookeeper 可以采取以下措施：

1. 配置合适的心跳超时时间：确保在网络故障时，能够及时检测到节点的故障状态，避免出现多个领导者。

2. 使用 quorum 机制：要求大多数节点在线才能进行选举和决策，避免少数节点分裂成独立的集群。

3. 监控节点状态：通过监控节点的状态，及时发现和处理故障节点，避免脑裂的发生。

十、集群部署方式及 CI/CD 流程

1. 这些集群是在虚拟机部署的还是 K8s 部署的？

- 回答具体的部署方式，如果是在公司服务器部署的，可以说明服务器的配置和管理方式。

2. 有没有 CI/CD 流程？

- 如果有 CI/CD 流程，可以介绍一下流程的具体步骤，包括代码构建、测试、部署等环节。如果没有，可以说明目前的开发和部署方式，并提出一些改进的建议。

十一、实习工作的合理性解释

解释为什么看起来很厉害的工作会分配给实习生做。可以强调自己的学习能力、团队合作精神和对新技术的热情，以及在实习期间得到的指导和支持。

十二、Redis Cluster 的槽位原理

Redis Cluster 采用哈希槽（hash slot）的方式来实现数据的分布式存储。整个集群被划分为 16384 个哈希槽，每个节点负责一部分哈希槽。当客户端发送一个命令时，Redis 会根据键的哈希值计算出对应的哈希槽，然后将命令转发到负责该哈希槽的节点上进行处理。这种方式可以实现数据的自动分片和负载均衡，提高系统的可扩展性和性能。

十三、Redis key 的 ttl 设置

可以为 Redis 的键设置生存时间（TTL，Time To Live），当键的生存时间到期后，Redis 会自动删除该键。设置 TTL 可以用于实现缓存过期、会话超时等功能。可以通过 EXPIRE、PEXPIRE 等命令来设置键的 TTL。

十四、Redis 的 keys 和 scan 的区别

1. keys 命令：用于列出所有满足给定模式的键。这个命令会遍历整个数据库，可能会导致性能问题，特别是在大数据量的情况下。

2. scan 命令：是一个迭代器命令，用于逐步遍历数据库中的键。它可以避免一次性遍历整个数据库，从而减少对性能的影响。scan 命令可以指定一个游标和一个匹配模式，每次返回一部分键，通过不断调用 scan 命令可以逐步遍历所有满足条件的键。

十五、Redis 的持久化方式及混合持久化的原因

1. Redis 的持久化你是用的什么？

- Redis 提供了两种主要的持久化方式：RDB（Redis Database Backup）和 AOF（Append Only File）。

- RDB 是一种快照式的持久化方式，它会在指定的时间间隔内将内存中的数据保存到磁盘上的一个二进制文件中。RDB 持久化的优点是恢复速度快，适用于数据备份和灾难恢复。

- AOF 是一种日志式的持久化方式，它会将所有的写命令追加到一个文件中，当 Redis 重启时，可以通过重新执行 AOF 文件中的命令来恢复数据。AOF 持久化的优点是数据安全性高，适用于对数据完整性要求较高的场景。

2. 为什么要用 RDB+AOF 混合持久化？

- 混合持久化结合了 RDB 和 AOF 的优点。在进行持久化时，Redis 会先使用 RDB 方式生成一个快照文件，然后将快照文件之后的写命令追加到 AOF 文件中。这样，在恢复数据时，可以先加载 RDB 文件快速恢复大部分数据，然后再通过执行 AOF 文件中的写命令来恢复剩余的数据，从而提高恢复速度和数据安全性。

十六、keepalived 底层实现

keepalived 是一个用于实现高可用性的软件，它通过以下方式实现底层功能：

1. 虚拟 IP 地址（VIP）管理：keepalived 可以为服务器分配一个虚拟 IP 地址，当主服务器出现故障时，备用服务器可以接管 VIP，继续提供服务。

2. 健康检查：通过定期发送心跳检测消息来检查服务器的健康状态。如果主服务器出现故障，备用服务器会在检测到故障后自动接管服务。

3. 故障转移：当主服务器出现故障时，keepalived 会自动将 VIP 切换到备用服务器上，并通知客户端连接到新的服务器。

4. 配置管理：keepalived 可以通过配置文件进行管理，用户可以根据自己的需求配置健康检查参数、故障转移策略等。

十七、集群扩容

如果所有的集群需要扩容，可以采取以下步骤：

1. 评估需求：确定需要扩容的原因和目标，例如增加存储容量、提高性能等。

2. 选择扩容方式：可以选择垂直扩容（增加单个节点的资源）或水平扩容（增加节点数量）。

3. 准备新节点：根据选择的扩容方式，准备新的服务器或虚拟机，并安装和配置相应的软件。

4. 数据迁移：如果是水平扩容，需要将部分数据从现有节点迁移到新节点上，以实现负载均衡。可以使用工具或手动方式进行数据迁移。