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)。
-
审计日志:记录用户的操作行为,用于监控和审计。
八股文分类整理 老哥们点点赞,订阅一下,纯福利做数据。