腾讯--后台开发实习生一面的八股真题整理（2025年3月4日）

面经小记：

资料来源于网络收集。

1.TCP的三次握手：

1. 客户端发送SYN报文段，请求建立连接
2. 服务器收到客户端请求，同意建立连接并发送SYN-ACK报文段
3. 客户端收到服务器相应，再次发送ACK报文段进行确认，服务器收到响应后连接成功建立。

通过三次握手，确保双方都准备好进行通信，并同步双方的初始序列号。

2.TCP的四次握手：

1. 客户端完成数据发送后，发送FIN报文段请求断开连接
2. 服务器收到请求后，发送ACK报文段表示确认

1. 1. 客户端进入FIN-WAIT状态，等待服务器的最终关闭请求
   2. 服务器进入CLOSE-WAIT状态，表示还可能继续发送数据，但已停止接受新的数据

1. 服务器完成数据发送后，也向客户端发送一个FIN报文，表示无数据可发送，申请关闭连接
2. 客户端收到服务器的FIN报文段后，发送一个ACK报文段作为确认

1. 1. 此时客户端进入TIME-WAIT的超时等待状态，等待2个最大报文段生命周期，从而确保服务器能够收到该ACK报文。服务器收到ACK后，进入CLOSED状态，完成连接关闭。

超时等待状态的作用：

1. 确保服务器收到最后一个ACK报文：如果服务器没有收到最后一个ACK报文，客户端需要等待足够长时间以便收到服务器重新发送的FIN报文
2. 防止旧连接的报文干扰新连接：由于TCP协议中端口数有限，一个连接刚刚关闭，很可能新的连接需要使用相同的端口，等待两倍的最大报文段生命周期以确保旧连接的报文段已消失，从而避免了对新连接的干扰。

3.TCP的粘包和拆包：

TCP粘包和拆包是TCP协议的特性决定的，它是一个面向流的协议，将数据看作一个连续的字节流，不保留消息边界，因此可能出现粘包和拆包两种现象。

1. 定义：

1. 1. 粘包（多变少）：发送方的多个数据包在接收方被当作一个数据包合并接受
   2. 拆包（少变多）：发送方发送的一个完整数据包在接收方可能被分成多个数据包依次接受

1. 原因：

1. 1. TCP面向流的特性：不保留消息边界。
   2. 速度差异：发送方速度快，容易粘包；接收方速度快，容易拆包。
   3. 网络延迟和丢包：也可能导致数据包的合并和拆分。

1. 解决方式：在应用层协议中定义消息边界。

1. 1. 固定消息的长度，简单但不灵活。
   2. 采用特殊分隔符，但仅适用于文本数据，且需进行转义处理。
   3. 添加长度字段，由发送方在消息开头添加一个字段表示消息长度。
   4. 借助协议框架（例如Netty），这些框架提供了解码器，如针对消息长度或分隔符进行消息划分的解码器。

4.HTTPS为什么相对于HTTP更安全？

前者在后者的基础上引入了传输层安全协议SSL/TLS，对数据传输进行了加密和身份验证。

1. 数据加密：HTTP通过明文形式传输，而HTTPS传输的是加密后的密文，接收方通过正确密钥进行解密方可解读数据。
2. 身份验证：HTTP协议无法验证服务器的身份，HTTPS下客户端在与服务器建立连接时通过其发送的数字证书来确认身份。避免了中间人攻击。
3. 数据完整性：HTTPS通过数字签名和哈希算法验证数据的完整性，。哈希算法能够对原始消息进行处理，生成固定长度的哈希值，且无法倒推。
4. 证书和密钥的管理：HTTPS使用非对称加密体制，服务器严格保管私钥，客户端使用服务器提供的公钥进行加密通信，且服务器的身份认证由第三方机构进行合法认定。
5. 安全协议不断更新。

5.加密过程涉及的加密类型：

非对称体制下的数据加密，数字证书，数字签名（发送方使用私钥对消息摘要进行加密生成数字签名，接收方先使用相同的哈希算法处理消息得到消息摘要，再使用发送方的公钥对数字签名解密得到原始消息摘要，最后比较两个消息摘要即可。）

6.HTTPS握手过程讲一下：

1. 客户端发送请求，即Hello消息
2. 服务器相应，发送Hello消息和SSL整数
3. 客户端验证整数，生成并发送用证书包含的公钥进行加密的预主密钥
4. 服务器用子集的私钥解密预主密钥
5. 双方生成相同的会话密钥
6. 相互发送Finished消息，握手完成
7. 开始安全通信

7.InnoDB介绍一下：

InnoDB是MySQL数据库中默认的存储引擎。

事务是一组逻辑上相关的数据库操作。

（1）核心特性

1. 作为一个事务型存储引擎，支持ACID特性，保证并发环境下数据的完整性和一致性。

1. 1. A是Atomicity，事务的原子性
   2. C是Consistency，事务执行前后，数据库状态保持一致
   3. I是Isolation，并发事务相互隔离、互不干扰
   4. D是Durability，事务提交后，数据永久保存

1. 行级锁：并发环境下，多个事务可同时操作不同的行，而不相互堵塞，大大提高了高并发场景下的性能。
2. 外键支持：允许外键约束，维护了表之间的关系完整性
3. 多版本并发控制：MVCC保存数据的多个版本，允许读操作不加锁从而提高了并发性能，在读已提交和可重复读的事务隔离级别下，确保事务读取到的数据符合该隔离级别。
4. 崩溃恢复：通过事务日志保证系统崩溃后，未完成事务的回滚和已完成事务的恢复，保证了数据的完整性。

（2）架构

1. 内存结构：

1. 1. 缓冲池
   2. 日志缓冲区
   3. 其他缓存

1. 磁盘结构：

1. 1. 表空间
   2. 事务日志

1. 1. 1. Redo Log，记录修改，用于崩溃恢复
      2. Undo Log，记录回滚，支持MVCC

1. 1. 数据文件和索引文件：存储在B+树索引结构的表空间文件中。

（3）事务隔离级别：

1. 读未提交：允许读取未提交的数据，可能出现脏读
2. 读已提交：只能读取已提交（版本）的数据，解决脏读，但仍不可重复读
3. 可重复读（默认级别）：第一次读数据时生成数据快照版本，保证同一事务的多次读取结果一致

1. 1. 可通过Next-Key Lock机制防止幻读，即已被读取范围内的数据无法被操作（原读取内容已改变但无法读出）

1. 可串行化：应用锁机制，强制事务串行执行，所有读操作都会加锁确保事务之间完全隔离，从而确保无幻读。

（4）与其他存储引擎的对比：

1. 对比MyISAM：

1. 1. InnoDB并发性能更好，因其支持行级锁
   2. InnoDB支持事务
   3. InnoDB支持外键和崩溃恢复，数据的完整性更好

1. 对比Memory：

1. 1. Memory存储在内存中，适合临时数据存储；InnoDB存储在磁盘中，适合持久化数据
   2. InnoDB支持事务。

8.InnoDB的索引结构说一下：

（1）结构特点：

基于名为B+树的数据结构，即多路平衡查找树，是B树的变种，适合数据库和文件系统的索引实现，主要特点是：

1. 所有叶子节点包含全部关键信息：数据记录只存储在叶子节点中，非叶子节点只存储索引信息
2. 叶子节点之间通过指针相连：便于范围查询
3. 高度平衡：所有叶子节点在同一层，保证了查找效率

（2）索引类型：

1. 主索引：

1. 1. 每张表有且只有一个主索引
   2. 主索引基于表的主键构造B+树
   3. 若没有显示定义主键，则自动选择第一个非空的唯一列作为主键；若无这样的列，自动生成隐藏的主键
   4. 叶子节点存储完整的行数据

1. 辅助索引：主索引之外的所有索引

1. 1. 叶子节点存储的是主键值，而非完整的行数据
   2. 先借助辅助索引找到主键值，再通过主索引访问完整的行数据（回表）

（3）索引结构的优缺点

优点：

1. 高效查询
2. 有序连接，范围查询
3. 高度平衡，时间复杂度O(logn)

缺点：

1. 辅助索引的回表操作增加开销
2. 索引维护成本
3. 空间占用，尤其是主索引

9.为什么选择B+树实现？

1. 高效的磁盘性能：

1. 1. 磁盘I/O是性能瓶颈：数据通常存储在磁盘上，且磁盘操作的性能很低，减少磁盘操作的次数是提高性能的关键。
   2. B+树的节点设计：每个节点可存储多个键值对，每次磁盘I/O可读取大量数据
   3. 高度平衡：高度低且平衡，操作的时间复杂度低，减少磁盘I/O次数

1. 适合范围查询：

1. 1. 对比B树：无需回溯遍历，可通过叶子节点的链表顺序访问数据

1. 减少存储空间浪费：

1. 1. 树低，占用空间小
   2. 节点利用率高，减少存储空间浪费

1. 插入删除高效：

1. 1. 自平衡特性，时间复杂度不变
   2. 高度较低且结构稳定，减少锁竞争

1. 支持并发操作：

1. 1. 行锁颗粒度更细，降低了锁的范围
   2. 允许读操作并发执行
   3. 写操作通过锁禁止高效地并发处理。

10.缓存三兄弟

（1）缓存穿透：查询数据不存在

• 定义：查询数据不存在，缓存和数据库中均没有
• 问题：大量请求查询不存在的数据，导致数据库压力增加乃至崩溃
• 解决：

1. 1. 缓存空值：将不存在的数据缓存一段时间，避免频繁查询
   2. 布隆过滤器：预先存储可能存在的数据键，若不存在则直接返回不存在，避免查询数据库

（2）缓存击穿：热点数据缓存失效

• 定义：某个热点数据的缓存过期时，大量请求发往数据库，导致数据库压力增大乃至崩溃
• 解决：

1. 1. 互斥锁：缓存失效时，第一个请求通过互斥锁获取数据并更新缓存
   2. 逻辑过期：预设逻辑过期时间，缓存物理过期时仍可返回旧数据
   3. 预热缓存：在启动或低峰期，提前加载热点数据到缓存

（3）缓存雪崩：大量缓存同时失效

• 定义：大量缓存数据在同一时间失效，或缓存服务（如Redis）宕机，导致大量请求打到数据库，致使压力增大乃至崩溃
• 解决方案：

1. 1. 设置随机过期时间：避免大量缓存同时过期
   2. 使用Redis集群，避免单点故障
   3. 本地缓存降级：在Redis缓存之上增加本地缓存，作为备案
   4. 限流：防止数据库过载

11.遇到慢查询SQL怎么优化：

1. 开启慢查询日志，找到执行时间较长的SQL语句
2. 分析慢查询，如借助mysqldumpslow
3. 优化索引：

1. 1. 为常用字段添加索引
   2. 避免索引失效
   3. 使用联合索引，注意最左前缀原则

1. 优化SQL语句本身：

1. 1. 避免SELECT *
   2. 用JOIN代替子查询
   3. 避免在WHERE子句中使用函数
   4. 用IN或UNION代替OR

1. 优化表结构：如拆分大表。