9.TP-link云计算一面

**1: Kafka的版本需要查看具体的部署配置。**在Kafka 2.8.0版本之前，Kafka使用Zookeeper来维护集群的元数据。从Kafka 2.8.0开始，引入了KRaft模式（Kafka Raft Metadata mode），这是一种不依赖Zookeeper的元数据管理方式。具体使用哪种模式，需要根据部署的Kafka版本和配置来确定。

2. ISR（In-Sync Replicas）列表是Kafka为了保证数据不丢失的机制。ISR列表包含了与Kafka主题分区leader副本保持同步的所有副本。如果一个副本由于网络问题或者机器故障不能及时与leader副本同步数据，那么它将被踢出ISR列表。ISR列表的作用是确保在发生副本选举时，新的leader拥有所有已确认的消息，从而保证数据的一致性和可靠性。

**3: 消费者组的Coordinator是Kafka集群中的broker。**每个消费者组都会被分配一个Coordinator，通常是该消费者组第一个成员加入时所在的broker。Coordinator的选举是通过Kafka集群内部机制自动完成的，主要是基于消费者组的ID进行哈希，然后映射到对应的broker上。

4: Kafka的生产者可以通过配置来保证消息不丢失：

• At Least Once（至少一次）：确保消息不会因为网络问题等丢失，但可能会重复发送。

• At Most Once（最多一次）：消息可能会丢失，但不会重复。

Kafka默认是至少一次的保证，通过开启幂等性或者事务功能可以避免消息的重复。

5: Kafka消费者组默认是自动提交offset的，但也可以配置为手动提交。自动提交在某些情况下可能会导致消息的重复消费，而手动提交可以更精确地控制offset的提交时机。

6: Kafka消费者组可能会重复消费消息，特别是在发生再平衡时。防止重复消费可以通过以下机制：

• 使用具有唯一标识的消息。

• 在应用层面实现幂等处理。

• 手动管理offset提交，确保消息处理完成后再提交。

7: Zookeeper通过以下机制来避免脑裂：

• 使用原子广播协议（Zab协议）来保证集群中所有节点的数据一致性。

• 集群中的节点需要获得多数节点的投票才能成为新的领导者。

• 配置合适的超时时间，防止网络分区导致的服务中断。

8.: 集群的部署方式可以是虚拟机、物理机或者Kubernetes（K8s）。CI/CD流程通常用于自动化部署和管理，具体使用哪种部署方式和是否有CI/CD流程取决于公司的实际需求和技术栈。

9： Redis Cluster的槽位是一个分布式的概念，它将所有的键空间分成16384个槽位，每个Redis节点负责一部分槽位。槽位用于在多个节点之间分配和定位键值对。

**10： 在Redis中可以为key设置TTL（**Time To Live），这样key在指定的时间后会自动被删除。

11: KEYS命令会一次性返回所有匹配的key，可能导致服务阻塞，不适用于大数据量的场景。而SCAN命令则是通过游标分批返回匹配的key，不会阻塞服务，适用于大数据量查询。

12: Redis的持久化通常使用RDB（快照）和AOF（追加文件）两种方式。RDB+AOF混合持久化结合了两者的优点，RDB提供了数据恢复的快速性，而AOP确保了数据的持久性。这种混合模式可以在数据恢复速度和数据安全性之间取得平衡。

13: Keepalived是一个高可用解决方案，它底层使用VRRP（Virtual Router Redundancy Protocol）协议来实现。Keepalived通过模拟路由器的功能，在多个节点之间进行健康检查和虚拟IP的漂移，以确保服务的连续性。

14: 集群扩容通常涉及到以下步骤：

• 增加新的节点到集群中。

• 重新分配槽位或者数据分区，确保数据均衡分布在所有节点上。

• 更新集群配置信息，让所有节点识别新的集群拓扑。

15: 如果是自己设计权限模型，通常会包括以下方面：

• 用户认证：确保只有合法用户可以访问系统。

• 权限控制：定义不同的角色和权限，限制用户可以执行的操作。

• 访问控制：基于角色和权限的访问控制列表（ACL）。

• 审计日志：记录用户的操作行为，用于监控和审计。