互联网公司CTO面试题

2026年互联网公司CTO面试题一、算法与数据结构（共3题，每题10分，总分30分）1.题目：假设有一个无重复元素的整数数组`arr`，请设计一个算法，找出数组中第三大的数。如果数组中的最大数、第二大数和第三大数都存在，则返回第三大的数；否则，返回最大的数。例如：输入：`[1,2,-2147483648]`，输出：`1`。输入：`[1,2,2,5,3,5]`，输出：`2`。2.题目：实现一个LRU（LeastRecentlyUsed）缓存，支持`get`和`put`操作。缓存容量为`capacity`，当访问一个键时，如果键存在，则返回其值，并将该键标记为最近最常使用；如果键不存在，则返回`-1`。当缓存容量已满时，需要删除最久未使用的键以腾出空间。例如：LRU缓存容量为`2`：`put(1,1)`：缓存是`{1=1}``put(2,2)`：缓存是`{1=1,2=2}``get(1)`：返回`1`，缓存是`{2=2,1=1}`（最近最常用是1）`put(3,3)`：缓存容量已满，删除键`2`，缓存是`{1=1,3=3}``get(2)`：返回`-1`（键`2`已删除）3.题目：给定一个链表，判断链表是否存在环。如果存在环，返回进入环的节点；否则，返回`null`。例如：输入：`[3,2,0,-4]`，其中节点`0`的`next`指向节点`2`，输出：节点`2`。输入：`[1,2]`，节点`2`的`next`指向节点`1`，输出：节点`1`。输入：`[1]`，无环，输出：`null`。二、系统设计（共2题，每题15分，总分30分）1.题目：设计一个高并发的短链接生成系统。要求：-链接长度尽可能短（如`/abc123`）。-支持高并发访问，单次请求响应时间控制在`200ms`以内。-链接唯一且可快速查重。-支持自定义短链接前缀（如`/abc123`）。2.题目：设计一个实时消息推送系统（如微信、钉钉）。要求：-支持亿级用户量，消息延迟不超过`100ms`。-支持离线推送，用户上线后立即收到未读消息。-支持消息分片（长消息自动拆分）。-支持消息签收回执和重试机制。三、数据库与分布式（共3题，每题10分，总分30分）1.题目：假设一个电商平台的订单表`orders`，字段包括`order_id`（主键）、`user_id`、`order_time`、`total_amount`。设计以下场景的SQL查询：-查询最近`1小时`内，每个用户的总消费金额。-查询`total_amount`超过`1000`的订单中，`user_id`最多的前`10`个用户。2.题目：解释MySQL的`MVCC`（多版本并发控制）原理，并说明`REPEATABLEREAD`和`SERIALIZABLE`隔离级别下的快照读和间隙锁的区别。3.题目：设计一个分布式事务解决方案，要求：-支持至少`2`个业务系统的数据一致性（如订单和库存）。-允许部分失败，保证最终一致性。-考虑性能和可用性。四、中间件与缓存（共2题，每题15分，总分30分）1.题目：设计一个高可用的Redis集群方案，要求：-支持读写分离。-节点故障时自动切换。-数据分片策略（如哈希槽）。-考虑扩容方案。2.题目：解释Kafka的`ZooKeeper`依赖和`Broker`选举机制。设计一个避免`Broker`单点的方案。五、网络与安全（共2题，每题15分，总分30分）1.题目：假设你的系统需要防御DDoS攻击，请设计一套防护方案，包括：-基于IP的黑白名单。-WAF（Web应用防火墙）策略。-流量清洗中心。2.题目：解释HTTPS的握手过程，包括`TLS`版本选择、证书校验、对称密钥生成等步骤。如何防止中间人攻击？六、分布式与微服务（共2题，每题15分，总分30分）1.题目：设计一个分布式限流方案，要求：-支持按接口或用户维度限流。-允许热扩展。-考虑漏桶和令牌桶算法的适用场景。2.题目：解释SpringCloud的`Eureka`和`Consul`的区别，设计一个服务注册与发现的容错方案。七、开放性问题（共1题，20分）题目：假设你要重构一个十年以上的单体应用，将其拆分为微服务架构。请说明：-如何划分服务边界？-如何解决服务间的通信问题？-如何处理数据一致性？-如何保证系统的监控和运维复杂度可控？答案与解析一、算法与数据结构1.第三大数思路：维护三个变量`first`、`second`、`third`，遍历数组时更新这三个变量。代码：pythondefthird_largest(nums):first,second,third=float('-inf'),float('-inf'),float('-inf')fornuminnums:ifnum>first:third,second,first=second,first,numeliffirst>num>second:third,second=second,numelifsecond>num>third:third=numreturnfirstifthird!=float('-inf')elsesecond解析：-如果`num`大于`first`，则更新所有三个变量。-如果`num`在`first`和`second`之间，则更新`second`和`third`。-否则，仅更新`third`。-最后，如果`third`仍为初始值，说明不存在第三大数，返回`second`。2.LRU缓存思路：使用双向链表+哈希表实现。链表头为最近最常用，尾为最久未使用；哈希表`cache`存储`key->node`映射。代码：pythonclassDLinkedNode:def__init__(self,key=0,value=0):self.key=keyself.value=valueself.prev=Noneself.next=NoneclassLRUCache:def__init__(self,capacity:int):self.capacity=capacityself.cache={}self.head,self.tail=DLinkedNode(),DLinkedNode()self.head.next=self.tailself.tail.prev=self.headdefget(self,key:int)->int:ifkeynotinself.cache:return-1node=self.cache[key]self._remove(node)self._add(node)returnnode.valuedefput(self,key:int,value:int)->None:ifkeyinself.cache:self._remove(self.cache[key])node=DLinkedNode(key,value)self.cache[key]=nodeself._add(node)iflen(self.cache)>self.capacity:node=self.tail.prevself._remove(node)delself.cache[node.key]def_remove(self,node):delself.cache[node.key]node.prev.next=node.nextnode.next.prev=node.prevdef_add(self,node):node.next=self.head.nextnode.next.prev=nodeself.head.next=nodenode.prev=self.head解析：-`get`操作将节点移动到链表头部，返回值。-`put`操作先删除旧节点，再添加新节点到头部。如果超出容量，删除尾部节点。-双向链表保证`O(1)`的插入和删除，哈希表保证`O(1)`的查询单节点。3.链表环检测思路：使用快慢指针（Floyd循环检测算法）。代码：pythondefdetect_cycle(head:ListNode)->ListNode:slow,fast=head,headwhilefastandfast.next:slow=slow.nextfast=fast.next.nextifslow==fast:slow=headwhileslow!=fast:slow=slow.nextfast=fast.nextreturnslowreturnNone解析：-快指针每次走两步，慢指针走一步，相遇则存在环。-相遇后，慢指针从头开始，快指针从相遇点开始，再次相遇的节点即为环的入口。-如果快指针到达`None`，则无环。二、系统设计1.短链接生成系统设计：-使用`62`进制编码（`0-9`，`a-z`，`A-Z`），长度为`6`时约`2^36`种链接。-前缀自定义，后缀随机生成。-数据存储：`Redis`（缓存热点链接）+`MySQL`（持久化）。-高并发：使用`Redis`分布式锁防止冲突。-接口：httpPOST/shortenBody:{url:"",prefix:"my"}Response:"/myabc123"解析：-`62`进制编码可缩短链接长度。-`Redis`缓存热点数据，`MySQL`存储所有链接。-分布式锁保证唯一性。2.实时消息推送系统设计：-消息队列：`Kafka`（高吞吐）。-推送服务：`MQ`消费者异步处理。-离线推送：用户表记录`offline_token`，推送失败缓存消息。-分片：客户端按`len=1024`拆分，服务端组装。-签收回执：`Redis`存储`user->message_id`，服务端定期清理。解析：-`Kafka`保证消息可靠性。-离线推送需用户在线状态。三、数据库与分布式1.SQL查询最近1小时消费金额：sqlSELECTuser_id,SUM(total_amount)AStotalFROMordersWHEREorder_time>NOW()-INTERVAL1HOURGROUPBYuser_id前10高消费用户：sqlSELECTuser_id,SUM(total_amount)AStotalFROMordersWHEREtotal_amount>1000GROUPBYuser_idORDERBYtotalDESCLIMIT10解析：-第一条查询按用户分组，时间过滤。-第二条查询先过滤大订单，再按用户分组排序。2.MVCC与隔离级别MVCC原理：-数据库为每个事务维护一个快照，基于`ReadView`确定可见性。-`REPEATABLEREAD`（读已提交+间隙锁）：防止幻读，但可能死锁。-`SERIALIZABLE`（串行化）：使用Next-Key锁，完全隔离，但性能最低。解析：-`MVCC`通过版本控制避免写冲突。-`SERIALIZABLE`最安全但开销大。3.分布式事务方案：-使用`2PC`（两阶段提交）或`TCC`（补偿事务）。-`2PC`：协调者拉取所有参与者状态，决定提交或回滚。-`TCC`：每个服务实现`try`、`confirm`、`cancel`操作。解析：-`2PC`实现简单但阻塞。-`TCC`灵活但代码复杂。四、中间件与缓存1.Redis集群设计：-使用`6`个`Master`节点，每个`Master`负责`16384`个哈希槽。-集群配置：`RedisSentinel`监控主从切换。-读写分离：客户端通过`Proxy`路由读请求。-扩容：新增`Master`时重新分配槽。解析：-哈希槽避免单点故障。-`Sentinel`保证高可用。2.Kafka依赖与Broker选举ZooKeeper依赖：-元数据存储（`Broker`列表、分区）。-Leader选举。Broker选举：-`Kafka`重启时，`ZooKeeper`选举首个存活节点为`Controller`，再选举分区`Leader`。防单点：-使用`Quorum`机制（如`3`个`ZooKeeper`节点）。解析：-`ZooKeeper`是Kafka的基石。-`Quorum`防止脑裂。五、网络与安全1.DDoS防护方案-IP黑白名单：动态识别恶意IP。-WAF：防止`SQL注入`、`XSS`。-流量清洗中心：使用`Cloudflare`或自建清洗机房。解析：-多层防御提高容错性。2.HTTPS握手过程步骤：1.客户端发送`ClientHello`（`TLS`版本、`CipherSuite`）。2.服务器响应