腾讯java面试题

腾讯面经

算法

1.给一个有序数组，查找其中某元素的下标——二分查找（A掉了）代码如下：

public int search(int[] numbers, int n) {
        int left = 0;
        int right = numbers.length - 1;
        int mid;
        while (left <= right) {
            mid = (left + right) / 2;
            if (numbers[mid] == n) {
                return mid;
            } else if (numbers[mid] < n) {
                left = mid + 1;
            } else {
                right = mid - 1;
            }
        }
        return -1;
    }

2.字符串反转，要求使用小于O(n)的时间复杂度。（二分法，刚开始想到了递归，结果报错了。后面使用交换字符的方法）代码如下：

public String fanZhuan(String str) {
        char[] chars = str.toCharArray();
        int right = str.length() - 1;
        int mid = right / 2;
        for (int i = 0; i <= mid; i++) {
            char c = chars[i];
            chars[i] = chars[right - i];
            chars[right - i] = c;
        }
        return new String(chars);
    }

测试：

public static void main(String[] args) {
        Main main = new Main();
//        int[] numbers = {1, 3, 4, 6, 8, 10, 12, 16, 19, 23};
//        System.out.println(main.search(numbers, 12));

        String str = "hello,world!";
        System.out.println(main.fanZhuan(str));
    }

问题

求两个大量数据集合的交集，其中A中的数据不重复，B中的数据不重复，A、B中有相同的数据？

好的，面试官。

对于求两个海量数据集合A和B的交集这个问题，由于数据量非常大，我们无法使用传统的内循环暴力匹配方式，因为时间复杂度会非常高。核心思路是利用数据结构进行高效查找，或者采用分治策略将大问题分解为小问题。

根据不同的场景和资源，我有以下几种解决方案：

第一种方案，也是我最优先考虑的，是使用哈希表。
既然A和B中的数据都是唯一的，这非常适合使用哈希表。具体做法是：

1. 选择一个集合，比如集合A，将其所有元素全部加载到内存中的一个哈希集合中。这一步的时间复杂度是O(n)。
2. 然后，遍历另一个集合B，对于B中的每一个元素，都去这个哈希集合中查询是否存在。因为哈希表的查询操作平均时间复杂度是O(1)，所以这一步的时间复杂度是O(m)。
   整个方案的总时间复杂度是O(n + m)，效率非常高。但这个方案的瓶颈在于内存。如果集合A的大小远超内存容量，那么这个方案就无法实施。因此，它适用于其中一个集合的大小能够被单机内存所容纳的场景。

第二种方案，适用于两个集合都无法完全放入内存的情况，即使用外部排序归并法。
这个方案借鉴了MapReduce的分治思想，步骤如下：

1. 排序：首先，分别将两个海量集合A和B进行外部排序，将它们各自排序成有序的数据序列。外部排序是处理海量数据排序的经典算法，它允许我们在磁盘上进行排序，而不需要全部加载到内存。
2. 归并：然后，使用双指针法，对这两个已经排序好的有序集合进行归并遍历。
   • 创建两个指针，分别指向集合A和集合B的起始位置。
   • 比较两个指针所指的元素的大小。如果A的元素小于B的元素，则A的指针后移；如果B的元素小于A的元素，则B的指针后移。
   • 如果两个元素相等，那么这就是一个交集元素，将其放入结果集，然后两个指针同时后移。
     这个过程只需要顺序地读取两个集合的数据，不需要将全部数据同时加载到内存，极大地降低了对内存的需求。它的效率取决于外部排序的效率。

第三种方案，是使用布隆过滤器，这是一种空间效率极高的概率型数据结构。
如果对结果的准确性要求不是100%精确，可以接受极小的误判率，那么布隆过滤器是一个非常好的选择。

1. 我们可以用一个足够大的布隆过滤器，将集合A中的所有元素都映射进去。
2. 然后，遍历集合B，用同一个布隆过滤器判断每个元素是否在集合A中存在。
3. 它的特点是：如果布隆过滤器说某个元素不存在，那么它一定不存在；但如果它说存在，那么有可能存在（极大概率），也有可能是误判。
   因此，这个方案得到的交集可能包含一些误判的元素（假阳性），但可以确保不漏掉任何一个真正的交集元素。它非常适合用于第一轮快速去重和过滤，比如在大规模推荐系统中快速筛选候选集。

总结一下我的选择思路：

• 如果内存允许，哈希表方案是效率最高、实现最简单的首选。
• 如果数据量巨大，远超内存限制，外部排序归并法是通用的、可靠的解决方案。
• 如果业务可以接受概率性结果，或者作为前置过滤器，布隆过滤器是空间效率最高的方案。

在实际工程中，我们通常会根据数据的具体规模、硬件资源和业务对准确性的要求，来组合或选择这些方案。

以上就是我的思路，谢谢。

Redis缓存击穿、缓存穿透、缓存雪崩以及解决办法？

好的，面试官。

Redis的缓存击穿、缓存穿透和缓存雪崩是高并发场景下三个典型的问题，它们都会导致大量请求直接落到数据库上，从而引发系统风险。它们之间的核心区别在于缓存Key的状态。

我先分别解释这三个问题以及对应的解决方案。

第一个是缓存穿透。
它是指查询一个根本不存在的数据。这个数据在缓存和数据库中都不存在。导致这个请求每次都会绕过缓存，直接查询数据库，失去了缓存的意义。如果短时间内有大量这样的恶意请求，比如用随机ID进行攻击，数据库压力会非常大，甚至可能被压垮。
解决方案主要有几个：

1. 接口层增加校验：比如用户权限校验，参数合法性校验（如ID<=0的直接拦截）。
2. 缓存空值：即使从数据库没查到，也将这个空结果（比如null）进行缓存，并设置一个较短的过期时间（比如1-5分钟）。这样后续的请求在缓存期间就能拿到这个空结果，从而保护数据库。
3. 使用布隆过滤器（Bloom Filter）：在访问缓存和数据库之前，先将所有可能存在的key哈希到一个足够大的bitmap中。当一个请求过来时，先到布隆过滤器中判断这个key是否存在。如果判断为不存在，那么这个key一定不存在，就直接返回，避免了后续的查询。如果判断为存在，则继续后续的查询流程。这是一个空间效率非常高的方案，但存在一定的误判率。

第二个是缓存击穿。
这是一个热点Key问题。指某一个热点Key（比如明星绯闻）在缓存过期的瞬间，同时有大量的请求对这个Key发起请求。这些请求发现缓存过期，都会去加载数据库数据并回设缓存，这个过程中大量并发请求会瞬间把数据库压垮。
解决方案的核心是避免大量请求同时去后端加载数据：

1. 设置热点数据永不过期：对于一些极热点数据，可以由后台定时任务异步地更新缓存，或者直接从逻辑上让它永不过期。
2. 加互斥锁（Mutex Lock）：这是最常用的方法。当第一个发现缓存失效的请求到来时，它会先获取一个分布式锁。获取锁成功的线程才会去数据库加载数据并回写缓存。而其他没能获取锁的请求则等待一小段时间，然后重新从缓存中获取数据。这样就避免了大量请求同时击穿到数据库。在实现上，通常可以用Redis的SETNX命令来实现。

第三个是缓存雪崩。
它是指在同一时间段内，大量的缓存Key集中过期失效，或者Redis缓存服务直接宕机了。导致所有原本应该访问这些失效Key的请求，全部转向数据库，引起数据库压力骤增甚至宕机，就像雪崩一样。
解决方案的核心是让缓存Key的失效时间变得分散，并提高系统的可用性：

1. 错开过期时间：给缓存数据的过期时间加上一个随机值（比如1-5分钟的随机数），避免大量key在同一时刻过期。
2. 构建高可用的Redis集群：通过主从复制、哨兵模式或者Redis Cluster来保证Redis服务不会彻底宕机，即使部分机器挂掉，依然可以提供服务。
3. 依赖隔离组件为后端限流并降级：比如使用Hystrix等组件，当应用检测到数据库访问慢或者请求过多时，能够进行限流甚至降级，牺牲部分非核心功能或用户体验，来保证系统整体不被拖垮。

总结一下：
• 穿透是查没有的数据，解决方案是缓存空值和布隆过滤器。

• 击穿是一个热点Key失效，解决方案是设置永不过期和加互斥锁。

• 雪崩是大量Key同时失效或服务宕机，解决方案是错开过期时间和构建高可用集群。

在实际项目中，我们通常会根据业务场景，组合使用这些方案来构建一个健壮的缓存系统。

以上就是我的理解，谢谢。

TCP和UDP的区别？

好的，面试官。

TCP和UDP是传输层两个最核心的协议，它们的区别非常显著，也决定了它们各自不同的应用场景。我主要从以下几个维度来阐述它们的区别：

第一，也是最根本的区别，是连接与无连接。

• TCP 是面向连接的协议。在数据传输之前，通信双方必须通过三次握手建立一条稳定的连接通道，传输结束后，还需要通过四次挥手来断开连接。这个过程就像打电话，需要先拨通、对方接听，才能开始通话。
• UDP 则是无连接的协议。发送数据之前不需要建立连接，直接发送。它类似于发短信或广播，直接把信息发出去，而不关心对方是否准备好接收。

第二，是可靠性和有序性。

• TCP 提供了非常可靠的交付保证。它通过确认应答、超时重传、序列号等机制，确保数据包能够无差错、不丢失、不重复地到达对方，并且能按发送顺序重新组装。如果中途有包丢失，TCP会负责重传。
• UDP 不提供任何可靠性保证。它只是“尽最大努力交付”，发送方无法知道数据是否到达接收方，也不会对数据包进行重传。数据包可能会丢失、乱序或重复。

第三，是传输效率和速度。

• 正因为TCP 提供了复杂的可靠性机制，它就需要做更多的工作（如建立连接、确认、重传、流量控制等），这导致了更大的协议开销和更高的延迟。因此，它的传输效率相对较低。
• UDP 由于没有这些额外的控制机制，头部开销非常小，处理逻辑简单，所以传输速度非常快，延迟低，效率高。

第四，是连接模式和数据形式。

• TCP 是点对点的连接，一条TCP连接只能有两个端点。它的传输方式是面向字节流的，这意味着应用程序发送的数据和接收的数据没有固定的边界，TCP会根据网络情况对数据包进行拆分和合并。
• UDP 支持一对一、一对多、多对多的通信模式。它的传输是面向报文的，应用程序交给UDP多长的报文，UDP就原样发送，一次发送一个报文，并保留边界。

最后，基于以上特点，它们的应用场景完全不同：

• TCP 适用于对数据准确性要求极高、但对速度要求相对不那么苛刻的场景。比如：网页浏览（HTTP/HTTPS）、电子邮件（SMTP/POP3）、文件传输（FTP）、金融交易等。
• UDP 则适用于对传输速度和实时性要求极高、可以容忍部分数据丢失的场景。比如：视频直播、语音通话、在线游戏（容忍偶尔卡顿但不能接受高延迟），以及域名查询（DNS） 这种简单的请求-应答模型。

总结来说，TCP的核心是可靠，为此牺牲了部分速度；而UDP的核心是高效和低延迟，为此牺牲了可靠性。 在实际开发中，我们会根据业务的核心诉求来选择使用哪一个。

以上就是我的理解，谢谢。

简述三次握手，四次挥手？

好的，面试官。

TCP的三次握手和四次挥手，分别是建立和终止一条TCP连接的核心过程。我结合它们的状态变化来简述一下。

首先是三次握手，目的是为了建立一条可靠的连接，并协商双方的初始序列号，为后续可靠传输做准备。这个过程如下：

1. 第一次握手：客户端首先向服务器发送一个SYN报文段。这个报文不携带应用数据，但其首部中的SYN标志位被置为1，同时客户端会随机生成一个初始序列号（seq=x）。发送后，客户端进入SYN-SENT状态。

2. 第二次握手：服务器收到客户端的SYN报文后，如果同意建立连接，会回复一个SYN-ACK报文段。这个报文的SYN和ACK标志位都置为1。它确认了客户端的序列号（ack=x+1），同时服务器也随机生成自己的初始序列号（seq=y）。发送后，服务器进入SYN-RCVD状态。

3. 第三次握手：客户端收到服务器的SYN-ACK报文后，会再向服务器发送一个ACK报文段。这个报文的ACK标志位置为1，它确认了服务器的序列号（ack=y+1），而自己的序列号为x+1。此时，客户端进入ESTABLISHED状态。服务器收到这个ACK后，也进入ESTABLISHED状态。至此，连接成功建立，双方可以开始传输数据。

为什么是三次？ 两次握手只能保证服务器的确认能力，但无法防止已失效的连接请求报文突然又传送到服务器，导致服务器错误地打开连接，造成资源浪费。三次握手确保了双方都具有发送和接收的能力，连接是双向可靠的。

接下来是四次挥手，目的是为了安全地终止一个双向的连接。因为TCP是全双工的，每个方向必须单独关闭。

1. 第一次挥手：主动关闭的一方（通常是客户端）发送一个FIN报文段，FIN标志位置1，并指定一个序列号（seq=u）。发送后，主动方进入FIN-WAIT-1状态。

2. 第二次挥手：被动关闭的一方（服务器）收到FIN后，会发送一个ACK报文作为确认（ack=u+1）。此时，服务器进入CLOSE-WAIT状态。主动方收到这个ACK后，进入FIN-WAIT-2状态。至此，从主动方到被动方这个方向的连接就被关闭了，但反向通道仍然可用，服务器可能还有数据要发送给客户端，这称为“半关闭状态”。

3. 第三次挥手：当被动方也没有数据要发送时，它会发送自己的FIN报文段（FIN标志位置1，seq=v）。发送后，被动方进入LAST-ACK状态。

4. 第四次挥手：主动方收到FIN后，必须再发送一个ACK报文（ack=v+1）进行确认。然后主动方进入TIME-WAIT状态，等待2MSL（最长报文段寿命的两倍）时间后，才最终进入CLOSED状态。被动方一旦收到这个ACK，就立即关闭连接，进入CLOSED状态。

为什么需要TIME-WAIT等待？ 主要有两个目的：一是确保主动方发送的最后一个ACK能到达被动方（如果丢失，被动方会超时重传FIN，主动方可以再次响应ACK）；二是让本次连接持续时间内所产生的所有报文都从网络中消失，避免影响到即将建立的新连接。

以上就是我对三次握手和四次挥手的理解，谢谢。

TCP中的算法了解吗？滑动窗口算法和拥塞控制算法说下（其他的我没想起来）？

好的，面试官。

TCP协议能提供可靠的传输，其核心依赖于一系列精妙的算法，其中最重要的两个是滑动窗口算法和拥塞控制算法。它们分别解决了不同层面的问题。

首先，滑动窗口算法，它主要解决的是流量控制问题。其目的是确保发送方的发送速率不会超过接收方的处理能力，避免接收方缓冲区被填满。

它的工作原理是：接收方在每次发送确认（ACK）报文时，都会通过一个“窗口大小”字段来告知发送方自己当前还能接收多少数据。发送方则维护一个发送窗口，这个窗口内的数据可以连续地发送出去，而无需等待每一个数据包的单独确认。

这个窗口是“滑动”的：当发送方收到接收方对窗口内最左边数据的确认后，窗口就会向右滑动，允许发送新的数据。通过这种机制，它很好地利用了网络带宽，将一次往返时间（RTT）内可以发送的数据量从1个包提升到了一批包，极大地提高了信道利用率，解决了TCP早期“停止-等待”协议效率低下的问题。

其次，拥塞控制算法，它解决的是网络环境的问题。其目的是防止发送方过快发送数据，导致网络中间设备（如路由器）的缓冲区被填满，从而引发网络拥塞和大量丢包。它是一个基于反馈的闭环控制系统，主要包含四个核心算法：

1. 慢启动：连接刚建立时，TCP会从一个很小的拥塞窗口开始，然后以指数级速度增长（每收到一个ACK，窗口大小就加一），目的是快速探测出网络的可用带宽。
2. 拥塞避免：当拥塞窗口大小超过一个阈值（慢启动阈值）后，就进入拥塞避免阶段。此时窗口从指数增长转变为线性增长（每RTT时间窗口大小加一），变得更为谨慎，以避免很快触碰到网络的容量极限。
3. 快速重传：当发送方连续收到3个重复的ACK时，就推断可能有数据包丢失（但网络可能并未严重拥塞），它会立即重传那个被认为丢失的包，而不必等待超时计时器触发。
4. 快速恢复：在快速重传之后，TCP并不会像超时那样将窗口急剧减小到1并重新慢启动，而是将拥塞窗口减半，然后直接进入拥塞避免阶段。这是为了更平滑地恢复，减少对吞吐量的影响。

两者的关系与区别：

• 滑动窗口是接收方控制的，目的是防止接收端过载。
• 拥塞控制是发送方根据网络状态自我调整的，目的是防止网络过载。
• 发送方最终的实际发送窗口大小，取的是“接收方通告的窗口”和“自己计算的拥塞窗口”中的较小值。

总结来说，TCP通过滑动窗口实现了高效可靠的端到端传输，又通过拥塞控制算法成为一个有礼貌、懂得谦让的网络公民，共同保证了整个互联网的稳定与高效。

以上就是我的理解，谢谢。

https和http的区别，https的安全性和可靠性如何保证？

好的，面试官。

HTTPS和HTTP最核心的区别在于安全性。HTTP的所有数据都是以明文形式传输的，就像寄送一张明信片，途中的任何人都可以查看和篡改其内容。而HTTPS则是在HTTP的基础上，增加了一个安全层（SSL/TLS），对数据进行加密和认证，相当于为通信建立了一条安全的私人隧道，保证了传输过程的安全性、完整性和可靠性。

HTTPS的安全性和可靠性主要通过以下四个机制来保证：

第一，混合加密机制。 HTTPS采用了非对称加密和对称加密相结合的方式。

1. 非对称加密用于安全地交换对称加密的密钥。在握手阶段，客户端使用服务器公钥加密一个随机生成的“预主密钥”并发送给服务器，只有拥有对应私钥的服务器才能解密获取它。这个过程解决了密钥交换的安全难题。
2. 对称加密用于加密实际传输的业务数据。双方使用刚才协商出的密钥进行加密和解密。对称加密算法效率高，适合大量数据的加密。这种混合模式既解决了密钥分发的安全问题，又保证了数据加密的高效性。

第二，数字证书机制。 这解决了身份认证问题，防止中间人攻击。如何确保我们连接的公钥真的属于目标网站，而不是一个攻击者伪装的？
服务器会向一个受信任的第三方机构（CA）申请一份数字证书。这个证书就像服务器的“数字身份证”，里面包含了服务器的公钥、网站身份信息以及CA的数字签名。客户端在握手时会校验这张证书：

• 是否由受信任的CA签发。
• 证书是否在有效期内。
• 证书中的域名是否与正在访问的域名一致。
  通过校验证书，客户端就能确认服务器身份的真实性，从而放心地使用证书中的公钥进行后续加密通信。

第三，完整性校验机制。 HTTPS通过摘要算法（如SHA-256）来保证数据的完整性，防止数据在传输中被篡改。
发送方会对传输的数据计算一个唯一的“指纹”（哈希值），并随加密后的数据一起发送。接收方解密数据后，会用同样的算法重新计算指纹，并与传来的指纹进行比对。如果两者不一致，就说明数据在传输过程中被篡改了，接收方会丢弃这些数据。

第四，安全套接层协议。 上述的所有过程，都通过SSL/TLS协议来规范和实现。TLS握手协议负责完成加密套件协商、身份认证和密钥交换；TLS记录协议则负责对数据进行分块、压缩、加密和添加消息认证码（MAC），确保应用层数据的安全传输。

总结来说， HTTPS通过混合加密保证机密性，通过数字证书保证身份认证，通过摘要算法保证完整性，最终由TLS协议将它们整合成一个完整的安全框架，从而为我们提供了安全可靠的通信保障。

以上就是我的理解，谢谢。

什么情况下mysql索引会失效？失效了如何处理？

好的，面试官。

MySQL索引失效是一个非常常见且关键的性能优化点。了解索引何时会失效，可以帮助我们更好地设计表和编写高效的SQL语句。我结合自己的经验，总结了几种典型的索引失效场景以及相应的处理办法。

首先，常见的索引失效场景主要有以下几种：

1. 违反最左前缀原则：这是复合索引失效最常见的原因。比如我们有一个(a, b, c)的联合索引，但查询条件是WHERE b = 1 AND c = 2，跳过了字段a，那么这个索引就无法被使用。因为索引的排序结构是先按a排，再按b排，最后按c排，跳过a就无法利用这个有序性。

2. 对索引列进行运算或使用函数：在索引列上使用函数、计算、自动或手动的类型转换，都会导致索引失效。例如：WHERE YEAR(create_time) = 2023 或者 WHERE amount * 2 > 100。因为MySQL无法预先知道运算后的结果是什么，它只能遍历所有行进行运算后再比较。

3. 使用LIKE查询并以通配符开头：比如 WHERE name LIKE '%张'。因为索引的排序是从左开始的，开头不确定就无法利用索引树进行快速查找，会导致全表扫描。而LIKE '张%'一般就可以使用索引。

4. OR连接条件：如果OR条件中的列并非全部都有索引，那么MySQL可能会选择全表扫描。例如，WHERE a = 1 OR b = 2，如果字段b上没有索引，即使字段a有索引，MySQL也可能放弃使用索引。

5. 索引列使用不等于查询：使用!=或<>查询时，MySQL认为需要扫描的数据集很大，使用索引的效率可能不如直接全表扫描，因此可能会放弃使用索引。

6. 数据分布问题：如果MySQL优化器通过统计信息发现，使用索引查询需要回表的数据量非常大（比如超过全表数据的30%），或者表中数据本身非常少，它可能会认为直接全表扫描的成本更低，从而放弃使用索引。

当发现索引失效导致查询缓慢时，我的处理思路和方法是：

1. 使用EXPLAIN进行分析：这是诊断SQL性能问题的第一步。通过EXPLAIN命令查看SQL的执行计划，重点关注type、key、rows这几个字段。如果type是ALL，就说明发生了全表扫描；如果key为空，就说明没有使用到索引。这是定位问题的关键证据。

2. 针对性优化SQL语句：

   • 对于最左前缀问题，调整查询条件的顺序或考虑新建一个更合适的联合索引。
   • 避免在索引列上做任何运算和函数操作，尽量将操作移到等号的另一侧。比如把YEAR(create_time)=2023改为 create_time BETWEEN '2023-01-01' AND '2023-12-31'。
   • 对于LIKE，尽量避免以%开头。如果业务必须如此，可以考虑使用全文索引等替代方案。

3. 优化索引设计：

   • 根据实际的查询需求，设计合理的联合索引，并注意字段的顺序。
   • 考虑使用覆盖索引，即索引包含了查询所需要的所有字段，这样就不需要回表，效率会大大提升，也能避免优化器因回表成本高而放弃使用索引。

4. 利用强制索引：在非常确定使用某个索引效率更高，但优化器错误判断时，可以使用FORCE INDEX提示来强制MySQL使用指定索引。但这只是一个临时方案，需要谨慎使用，因为随着数据分布的变化，强制索引可能在未来会适得其反。

总结来说， 解决索引失效问题的流程是：先通过EXPLAIN确认问题，然后分析是SQL写法问题还是索引设计问题，最后通过改写SQL或优化索引来解决。核心思想是让查询条件尽可能符合索引的排序规则，避免索引列参与计算。

以上就是我的理解和处理方式，谢谢。

说一下Redis有哪些数据类型？

好的，面试官。

Redis之所以强大和受欢迎，很大程度上得益于它丰富的数据类型。它不仅仅是一个简单的键值存储，更是一个支持多种数据结构的服务器。这使得我们可以直接将内存中的数据按照合适的结构进行组织，从而非常高效地支持各种业务场景。

Redis主要支持以下五种核心数据类型，以及一些更高级的类型：

首先是五种最基本也是使用最频繁的类型：

1. String（字符串）：这是最基础的类型，可以存储任何形式的二进制数据，包括文本、数字或者序列化的对象。它的一个强大之处在于可以对数字值执行原子性的自增或自减操作，这使得它在计数器（如文章阅读量、用户点赞数）、分布式锁以及缓存简单数据等场景中非常有用。

2. Hash（哈希）：它类似于Java中的Map，是一个键值对集合，特别适合用来存储对象。例如，我们可以用一个user:1的Hash结构来存储一个用户的所有信息，如姓名、年龄等。与将整个对象序列化成String存储相比，使用Hash可以单独获取或更新某个字段，更加高效和灵活，节省网络带宽。

3. List（列表）：它是一个简单的字符串列表，按照插入顺序排序，并且支持在头部和尾部进行插入。基于这个特性，我们可以用它来实现消息队列（生产者从左侧推入消息，消费者从右侧取出消息）、排行榜或者最新文章列表这类功能。

4. Set（集合）：它是一个无序且元素唯一的集合。它支持高效的交集、并集、差集等集合操作。因此，它非常适合用于需要去重的场景，比如共同关注、共同好友（求交集），或者随机抽奖（随机弹出元素）。

5. Sorted Set（有序集合）：它和Set一样保证元素的唯一性，但不同的是，它为每个元素都关联了一个score（分数），元素会根据这个分数进行从小到大的排序。这使得它成为实现排行榜功能的绝佳选择，可以轻松地获取Top N的用户。此外，它还可以用于带权重的消息队列。

除了这五大核心类型，Redis还提供了一些更高级的类型：

• Bitmaps（位图）：它本质上是基于String类型的一套位操作指令，可以极大地节省空间。常用于需要记录大量布尔值的场景，比如用户的每日签到记录。
• HyperLogLog：这是一种用于基数统计的算法，它的优点是，用极小的空间就能完成对海量数据去重后的计数，比如统计一个大型网站的每日独立访客数（UV），它会有一定的误差率，但效率极高。
• Geospatial（地理空间）：它存储的是地理空间位置信息，支持计算两地之间的距离、查找指定位置半径内的所有地点等，非常适合用于“附近的人”、“附近的餐厅”这类LBS（基于位置的服务）应用。

总结来说，Redis丰富的数据类型让我们在设计和实现功能时有了更多、更优的选择，可以直接在内存中完成复杂的逻辑操作，而无需频繁地与数据库交互，这正是Redis性能如此出色的关键原因之一。

以上就是我对Redis数据类型的理解，谢谢。

Redis集群了解吗？说一下哨兵机制和主从同步原理？

好的，面试官。

关于Redis集群，我主要了解三种模式：主从复制模式、哨兵模式以及Redis Cluster模式。您问的哨兵和主从同步正是前两种模式的核心机制。

首先，我说一下主从同步原理。这是Redis实现高可用的数据基础，核心是一个主节点（Master） 和多个从节点（Slave） 之间的数据复制。

整个过程可以分为两个阶段：全量同步和增量同步。

1. 全量同步：通常发生在一个新的从节点首次接入集群，或者从节点宕机时间过长的情况下。

   • 从节点会向主节点发送一个PSYNC命令请求同步。
   • 主节点接收到命令后，会启动一个后台进程生成当前数据的RDB快照文件。
   • 生成完毕后，主节点会将这个RDB文件发送给从节点。
   • 从节点接收到RDB文件后，会先清空自身旧数据，然后完整地加载这个RDB文件到内存中，从而将自己的数据状态更新到与主节点某个时间点完全一致的水平。
   • 在主节点生成和发送RDB文件期间，新的写命令会被缓存在内存的一个复制缓冲区中。
   • 最后，主节点会将这部分缓冲区的增量命令发送给从节点，从节点执行这些命令，最终实现数据的完全同步。

2. 增量同步：在全量同步完成后，主从节点之间会维持一个网络连接。

   • 主节点会将自己接收到的每一个写命令，异步地发送给所有的从节点。
   • 从节点接收到命令后执行，从而保持与主节点的数据实时一致。这个过程依赖于复制缓冲区，如果网络短暂中断，从节点重连后可以从中断点继续同步增量数据，避免了每次全量同步的巨大开销。

接下来是哨兵机制（Sentinel）。主从模式解决了数据备份和读负载均衡的问题，但它有个致命缺点：当主节点宕机时，无法自动进行故障切换。这就需要哨兵来解决了。

哨兵本身是一个独立的分布式系统，由多个哨兵节点组成，共同来监控Redis主从集群的健康状态。它的核心功能有三个：监控、自动故障转移和配置提供。

1. 监控：每个哨兵节点会定期向所有主从节点发送PING命令来检测它们是否正常运行。如果某个节点在指定时间内没有有效回复，哨兵就会将其标记为“主观下线”。

2. 自动故障转移：当哨兵集群通过投票机制，确认主节点确实“客观下线”后，故障转移流程就会启动。

   • 哨兵会先在所有从节点中，根据一定的规则（如优先级、复制偏移量等）选举出一个新的主节点。
   • 然后，它会向这个被选中的从节点发送SLAVEOF NO ONE命令，使其升级为主节点。
   • 之后，再通过SLAVEOF命令，让其他所有从节点改为复制这个新的主节点。
   • 最后，哨兵会通知客户端（通过发布订阅机制）主节点已经变更，让客户端连接到新的主节点上。

3. 配置提供：客户端在连接集群时，会首先连接哨兵系统，通过哨兵来查询当前真正的主节点地址，从而实现了服务发现的自动化。

总结来说，主从同步是数据复制的基石，保证了数据的多副本；而哨兵机制是在此基础上提供了高可用性，解决了主节点故障时的自动切换问题。在实际项目中，我们通常会将二者结合使用，即“一主多从+哨兵集群”的模式，来构建一个稳定、可靠的Redis缓存方案。

以上就是我的理解，谢谢。

如何实现Redis分布式锁，有哪些使用场景？

好的，面试官。

实现Redis分布式锁，核心目标是在分布式系统中，对一个共享资源进行互斥的访问控制。我通常基于两个核心命令来实现：SET key value NX PX timeout。

它的实现原理和关键考量点如下：

首先，加锁过程。我们使用 SET 命令，并附加上 NX 和 PX 参数。

• NX 表示只有当键不存在时才能设置成功，这保证了只有一个客户端能创建这个锁键，即抢锁成功。
• PX 用于设置一个毫秒级的过期时间。这是非常关键的一步，它避免了因为客户端崩溃或网络中断而导致锁无法释放，最终造成死锁的问题。值（value）的设置也很重要，我们通常会使用一个全局唯一的标识，比如客户端ID加线程ID，这样在释放锁时可以验证身份，防止误删。

其次，释放锁的过程。释放锁并非简单地调用 DEL 命令删除键。因为我们需要确保是“谁加的锁，谁才能释放”。所以，这个过程需要分为两步：

1. 先获取锁对应的值，检查是否与当前客户端的唯一标识匹配。
2. 如果匹配，再执行删除操作。

但这两步操作必须是原子性的，否则在第一步判断匹配之后，锁恰好过期并被其他客户端获取，就可能误删别人的锁。因此，我们通常使用 Lua 脚本来执行释放锁的逻辑，因为Lua脚本在Redis中是原子执行的，确保了判断和删除这两个操作的连续性。

此外，我们还需要考虑一些更复杂的场景：

• 锁的续期（Watchdog机制）：如果一个业务操作执行时间很长，超过了我们设置的锁过期时间，那么锁会自动释放，可能导致临界区被多个客户端进入。针对这种情况，成熟的客户端（如Redisson）实现了“看门狗”机制，它会启动一个后台线程，在锁过期之前定期去延长锁的持有时间。
• Redis集群环境：在主从切换的极端情况下，可能会出现锁失效的风险。比如客户端在主节点上加锁成功，但主节点在将锁数据异步复制给从节点之前宕机了，此时从节点被提升为新主，但锁数据丢失了，其他客户端又能来加锁。对于这种对可靠性要求极高的场景，Redis官方提供了 RedLock 算法，它的核心思想是让客户端依次向多个独立的Redis实例申请锁，只有当超过半数的实例都成功获取锁时，才算加锁成功，这在一定程度上提高了可靠性，但也带来了更高的复杂性和性能开销。

关于使用场景，分布式锁非常适用于需要强一致性保证的并发控制场景，例如：

1. 秒杀库存扣减：防止超卖，确保商品库存不会被多个用户同时修改。
2. 防止重复处理：比如一个定时任务在多个节点上部署，通过分布式锁确保同一时刻只有一个节点在执行。
3. 关键业务操作的单人持有：比如后台管理员进行某项全局配置的修改，需要加锁防止多人同时操作导致数据混乱。

总结来说，实现一个安全、可靠的Redis分布式锁，需要满足互斥性、防死锁、身份验证和原子性释放这几个基本条件。在大多数业务场景下，基于单Redis实例的SET NX PX加Lua脚本的方案已经足够，如果需要更高可靠性，可以考虑RedLock或选择ZooKeeper/Etcd等其他方案。

以上就是我的理解。

类加载过程了解吗？

好的，面试官。

类的加载过程是JVM将类的字节码文件加载到内存，并将其转换为可以被JVM直接使用的运行时数据结构的过程。这个过程非常精细，可以清晰地分为以下五个阶段：加载、验证、准备、解析和初始化。

第一个阶段：加载
这个阶段主要完成三件事：

1. 通过一个类的全限定名来获取定义此类的二进制字节流。这个字节流来源很广泛，可以是Class文件、JAR包、网络，甚至是运行时动态生成。
2. 将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构。
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。我们程序中的getClass()、.class等操作获取的都是这个对象。

第二个阶段：验证
这是一个确保Class文件的字节流包含的信息符合《Java虚拟机规范》全部约束要求，保证其不会危害虚拟机自身安全的重要阶段。主要包括文件格式验证、元数据验证、字节码验证和符号引用验证。如果验证失败，会抛出VerifyError。

第三个阶段：准备
这个阶段正式为类变量（被static修饰的变量）分配内存并设置初始零值。请注意，这里分配内存的仅包括类变量，而不包括实例变量。并且设置的是数据类型的零值，比如int是0，boolean是false，引用类型是null。但如果类变量被final static修饰，那么在这个阶段就会被直接赋予程序中指定的值。

第四个阶段：解析
这个阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

• 符号引用：是一组用来描述所引用目标的符号，可以是任何形式的字面量，与虚拟机实现的内存布局无关。
• 直接引用：可以是直接指向目标的指针、相对偏移量或能间接定位到目标的句柄，与虚拟机实现的内存布局直接相关。

第五个阶段：初始化
这是类加载过程的最后一步，也是真正开始执行类中定义的Java程序代码的阶段。在这个阶段，JVM会执行类构造器<clinit>()方法。这个方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的。虚拟机会保证在子类的<clinit>()方法执行前，其父类的<clinit>()方法已经执行完毕。

需要特别强调的是，JVM规范严格规定了有且只有六种情况必须立即对类进行“初始化”，而加载、验证、准备自然需要在此之前完成。这六种情况包括我们熟悉的new关键字、访问或设置静态字段、调用静态方法等。

总结来说，类加载过程通过这五个严谨的阶段，确保了Java类能够被安全、正确地加载到JVM中并投入使用，这是Java语言安全性和动态性的基石。

以上就是我对类加载过程的理解，谢谢。

Redis缓存和mysql数据库不一致时如何解决？

好的，面试官。

关于Redis缓存与MySQL数据库的数据不一致问题，这是一个引入缓存后非常经典的问题。其根本原因在于，我们无法做到一个原子操作同时更新两个独立系统。在我的项目经验中，解决这个问题的核心思路是：根据业务场景权衡一致性的要求，选择合适的策略，而不是追求绝对的强一致。

我通常从以下几个方案来考虑和解决：

首先，是最常见的“Cache Aside Pattern”（旁路缓存模式）。 这是最基础、使用最广泛的策略。它的读写流程是：

• 读操作：先读缓存，命中则返回；未命中则读数据库，取出数据后写入缓存，再返回。
• 写操作：先更新数据库，再删除缓存（注意是删除，不是更新）。

不一致往往就出现在写操作这里。如果先删缓存再更新数据库，在并发读写下极易产生脏数据。而采用“先更新数据库，再删除缓存”的策略，不一致的窗口期会短很多，但理论上依然存在极小的概率出现问题。这个策略的优点是简单高效，缺点是仍然有极短暂的不一致可能，并且如果缓存删除失败，需要有一套机制来补救。

其次，为了应对删除缓存失败的情况，我们需要引入“重试机制”。 一个成熟的做法是：
在更新数据库后，我们将删除缓存的请求发送到一个消息队列中，由消费者自动重试删除，直到成功。这可以保证最终一致性。如果重试多次后依然失败，就需要有监控报警介入，进行人工处理。

第三，对于一致性要求非常高的场景，比如金融核心业务，我们可以采用更严格的方案。
其中一个方案是**“延迟双删”**。即在更新数据库前，先删除一次缓存；更新完数据库后，休眠一个短暂的时间（比如几百毫秒，这个时间取决于主从同步和业务读操作的耗时），再次删除缓存。这个第二次的延迟删除，是为了清除在第一次删除后、数据库主从同步完成前，可能被读请求加载到缓存中的旧数据。

最后，还有一种订阅数据库二进制日志（binlog）的方案。
我们可以使用阿里巴巴的Canal这类中间件，让它伪装成MySQL的从库，订阅数据库的binlog变化。当数据库有数据更新时，Canal能近乎实时地捕获到这个更新事件，然后通知一个缓存更新程序去删除Redis中对应的缓存。这个方案的优势在于将缓存更新逻辑与业务代码完全解耦，使得业务层非常简洁，对缓存的操作对开发者近乎无感。它的架构复杂度较高，但能提供非常可靠的数据一致性保证。

总结一下，我的选择思路是：

1. 对于绝大多数对一致性不是极度敏感的读多写少场景，“Cache Aside + 异步重试删除” 是性价比最高的方案。
2. 对于一致性要求较高的场景，可以考虑**“延迟双删”** 来进一步降低不一致窗口。
3. 对于大型项目，追求极致解耦和最终一致性，“订阅binlog” 是一个非常专业和可靠的方案。

核心思想就是，理解业务容忍度，通过技术手段将不一致的窗口期缩到最短，并通过重试机制保证最终一致性。

以上就是我的理解和解决方案，谢谢。

用过nacos吗，说一下作用和特点？心跳机制？

好的，面试官。

是的，我在之前的微服务项目中深入使用过Nacos。它是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。可以把它理解为服务注册中心和配置中心的合二为一，是微服务架构中的核心基础设施。

它的主要作用和特点可以概括为以下几个方面：

1. 服务注册与发现：这是它作为注册中心的核心功能。所有微服务实例在启动时都会将自己的元数据，如IP、端口、服务名等，注册到Nacos Server。消费者则通过Nacos来查询和订阅这些服务实例的列表，从而实现服务的动态发现和调用。这解决了传统硬编码IP地址带来的难以维护和无法弹性伸缩的问题。

2. 动态配置管理：这是它作为配置中心的强大能力。我们可以将应用程序的配置信息（如数据库连接、开关标志等）集中托管在Nacos上。当配置发生变更时，Nacos能够实时地推送到相关的客户端应用，使其动态生效，而无需重启服务。这极大地提升了运维效率和系统的灵活性。

3. 服务健康检查与负载均衡：Nacos会持续检查注册服务的健康状态。它通过与服务实例维持心跳机制，能够实时感知实例的上线、下线和健康度。它会自动将不健康的实例从服务列表中剔除，确保客户端不会调用到已宕机的服务，同时内置了负载均衡策略，如轮询、随机等。

4. 高可用与易用性：Nacos支持集群部署，通过Raft协议保证其自身的高可用性。同时，它提供了非常友好的控制台界面，方便我们进行服务管理和配置操作。另一个重要特点是它支持基于AP和CP两种模式的数据一致性，可以根据场景在服务可用性和数据强一致性之间进行权衡。

关于您问到的心跳机制，这是Nacos实现服务健康检查的核心。它包含两种模式：

• 客户端主动上报（心跳模式）：这是默认且主要的方式。服务实例注册后，会定期（默认5秒一次）向Nacos Server发送一个心跳包，以此宣告自己处于活跃状态。Nacos Server在收到心跳后，会将该实例的健康状态标记为true。
• 服务端主动探测：作为补充，Nacos Server也可以主动发送一个健康检查请求到服务实例，比如发送一个HTTP请求或建立一个TCP连接，根据响应来判断服务是否健康。

如果Nacos Server在超过一段时间（默认15秒）内没有收到某个实例的心跳，它会将该实例标记为“不健康”。如果再持续一段时间（默认30秒）仍未收到心跳，则会自动将该实例从服务列表中删除，完成服务的自动下线。

这种机制保证了服务列表的实时性和准确性，是微服务架构能够实现高可用的关键保障。

总结来说，Nacos通过其服务注册发现和动态配置管理两大核心功能，以及可靠的心跳健康检查机制，为微服务系统提供了强大的支撑，简化了架构，提升了系统的弹性和可维护性。

以上就是我的理解，谢谢。

jvm内存模型说一下？

好的，面试官。

JVM内存模型，更准确地说是JVM的运行时数据区，是Java程序运行时的核心基础。它主要分为两大类别：线程共享的区域和线程私有的区域。

首先，是线程共享的区域，所有线程都能访问，随着虚拟机启动而创建。

1. 堆（Heap）：这是最大的一块内存区域，是垃圾收集器管理的主要区域，因此也被称为“GC堆”。我们通过new关键字创建的所有对象实例和数组几乎都在这里分配内存。为了更高效地进行内存回收，堆空间又细分为：

   • 新生代：用于存放新创建的对象。它又分为一个Eden区和两个Survivor区。绝大多数新对象在Eden区创建，经过一次Minor GC后，存活的对象会被移动到Survivor区。
   • 老年代：用于存放经过多次GC后仍然存活的对象，也就是生命周期较长的对象。当Survivor区中的对象年龄达到一定阈值后，会晋升到老年代。

2. 方法区（Method Area）：它存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。在JDK 8及之后，传统的“永久代”被移除，方法区的实现改为了元空间（Metaspace），并使用本地内存（而非JVM内存）来存储，从而避免了永久代的内存溢出问题。

3. 运行时常量池：它是方法区的一部分，用于存放编译期生成的各种字面量和符号引用。

其次，是线程私有的区域，每个线程都有自己的独立副本，生命周期与线程相同。

1. 程序计数器：这是一块很小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。它保证了线程在切换后能恢复到正确的执行位置。

2. 虚拟机栈：每个方法在执行时，都会同步创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。我们常说的“栈内存”，指的就是这个区域。如果线程请求的栈深度过大，会抛出StackOverflowError错误。

3. 本地方法栈：它的作用与虚拟机栈非常相似，区别在于虚拟机栈为Java方法服务，而本地方法栈为虚拟机使用到的Native方法服务。

在实际开发中，理解JVM内存模型至关重要，尤其是堆空间。 我们遇到的大部分性能问题，如内存溢出（OutOfMemoryError）和内存泄漏，都发生在这里。通过配置堆的大小、新生代与老年代的比例等参数，并结合垃圾回收器进行调优，我们可以有效地提升应用的稳定性和性能。

总结来说，JVM内存模型为Java的“一次编写，到处运行”和自动内存管理提供了底层支撑，是我们进行性能分析和故障排查的理论基础。

以上就是我的理解，谢谢。

线程池了解吗？有哪些参数？

好的，面试官。

线程池是Java并发编程中一个非常重要且实用的工具。它的核心思想是通过池化技术来复用线程，减少线程频繁创建和销毁所带来的性能开销，同时可以有效地控制并发数量，管理任务队列，并提供丰富的钩子方法供我们监控和扩展。

创建一个线程池，最核心的是通过它的七大参数来定义其行为：

1. 核心线程数：这是线程池中长期维持的、即使处于空闲状态也不会被回收的线程数量，除非设置了allowCoreThreadTimeOut。它构成了线程池的常驻基础队伍。

2. 最大线程数：这是线程池所能容纳的线程总数上限。当任务量激增，超过核心线程数的处理能力，且工作队列也已满时，线程池才会创建新线程，直到数量达到这个最大值。

3. 线程存活时间：当线程数量超过核心线程数时，那些空闲的、非核心的线程在等待新任务的最长时间。超过这个时间，这些线程就会被回收，以减少资源消耗。

4. 阻塞队列：用于存放提交后尚未被执行的任务。它是线程池的缓冲区域。常用的队列类型有：

   • LinkedBlockingQueue：可以创建无限长的队列（但通常指定有界容量），适用于任务增长平稳的场景。
   • ArrayBlockingQueue：有界队列，有助于防止资源耗尽。
   • SynchronousQueue：一个不存储元素的队列，每个插入操作必须等待另一个线程的移除操作，适用于任务量瞬间爆发的场景。

5. 线程工厂：用于创建新线程。我们可以通过自定义线程工厂来给线程设置更有意义的名称、设置为守护线程等，这在后期排查问题和监控时非常有用。

6. 拒绝策略：当线程池已经关闭，或者线程数和队列都已达到最大值，无法再接受新任务时，采取的处理策略。JDK内置了四种策略：

   • AbortPolicy：直接抛出RejectedExecutionException异常，这是默认策略。
   • CallerRunsPolicy：由提交任务的调用者线程自己来执行这个任务。
   • DiscardPolicy：直接静默地丢弃这个任务。
   • DiscardOldestPolicy：丢弃队列中最老的一个任务，然后尝试再次提交当前任务。

线程池的工作流程可以简单概括为：一个新任务提交时，会优先分配给核心线程执行；如果核心线程已满，则进入阻塞队列等待；如果队列也满了，才会创建新线程（直到达到最大线程数）；如果所有途径都已满，则触发拒绝策略。

在实际开发中，我们需要根据任务的性质（是CPU密集型还是IO密集型）来合理地配置这些参数。例如，CPU密集型任务通常建议设置较小的核心线程数，以避免过多的线程上下文切换；而IO密集型任务则可以设置较大的线程数，以便在等待IO时CPU不会空闲。

合理地配置线程池参数对于系统的稳定性和性能至关重要，是高性能Java应用开发的必备技能。

以上就是我的理解，谢谢。

现有一个线程池，参数corePoolSize = 5，maximumPoolSize = 10，BlockingQueue阻塞队列长度为100，此时有1个任务进来，问：线程池会做什么？

好的，面试官。

对于这个场景，线程池的处理逻辑会遵循其标准的工作流程。根据您给出的参数：核心线程数为5，最大线程数为10，阻塞队列长度为100。当第一个任务提交进来时，线程池会按顺序进行以下判断和操作：

1. 首先，检查当前运行的线程数是否小于核心线程数（5个）。由于这是第一个任务，当前运行的线程数显然为0，小于5。因此，线程池不会选择将任务放入队列，而是会立即创建一个新的核心工作线程，并将这个任务分配给该线程去执行。

2. 这个新创建的线程是核心线程，即使它在完成任务后进入空闲状态，只要没有设置allowCoreThreadTimeOut为true，它就会一直存在，不会被回收，以备后续任务的到来。

所以，对于这第一个任务，线程池的处理结果是：创建一个核心线程，并由该线程立即执行这个任务。

在这个过程中，线程池的队列始终没有被使用（因为0 < 5，直接创建了线程），也完全没有达到需要判断队列是否已满（100个容量）的地步，更不会触发创建非核心线程（因为10的最大线程数远未触及）或拒绝策略。

这是一个非常典型且简单的“线程数小于核心线程数”的场景，线程池的响应是最直接和高效的。

如果后续任务持续提交，线程池的行为会依次演进：接下来的第2、3、4、5个任务都会同样地创建新的核心线程并执行；当核心线程数达到5且都处于忙碌状态时，后续的任务才会被放入那100个容量的阻塞队列中等待；只有当队列也满了之后，才会继续创建非核心线程，直到达到最大线程数10。

以上就是我对这个特定场景下线程池行为的分析，谢谢。

mysql的存储引擎了解吗？Innodb底层是怎么实现的？B+树与B树的区别？

好的，面试官。

关于MySQL的存储引擎，我了解最常见的是InnoDB和MyISAM。现在InnoDB是MySQL默认的存储引擎，因为它提供了对事务、行级锁和外键的完整支持，更适合大多数需要高并发和数据一致性的业务场景。

接下来，我重点说一下InnoDB的底层实现。它的核心设计可以概括为几个部分：

1. 基于B+树的索引组织表：InnoDB表的数据本身，就是按照主键顺序存放在一棵B+树索引中的，这棵索引被称为聚簇索引。也就是说，数据行就存储在B+树的叶子节点上。这种设计让根据主键的查询非常高效。如果没有定义主键，InnoDB会选择一个唯一的非空索引代替，如果也没有，则会隐式地生成一个主键。

2. 缓冲池：这是InnoDB的核心组件，是一块主要的内存区域。它通过一种LRU算法来缓存表和索引的数据。当需要读取数据时，会先看缓冲池中是否存在，从而避免昂贵的磁盘I/O。当需要修改数据时，也是先在缓冲池中修改对应的数据页，再通过特定的机制刷新回磁盘。这个机制极大地提升了数据库的性能。

3. 事务日志：为了保证事务的持久性和崩溃恢复能力，InnoDB采用了Write-Ahead Logging策略。任何数据修改都会先记录到重做日志中，然后再在适当的时候写回磁盘的数据文件。如果数据库发生崩溃，重启后可以通过重做日志来重做那些已经提交但尚未写入数据文件的事务，从而保证数据不丢失。回滚日志则用于保证事务的原子性，在事务回滚或MVCC时用于撤销操作。

4. 锁与MVCC：InnoDB支持行级锁，这大大提高了并发性能。同时，它通过多版本并发控制来实现非锁定读。简单来说，就是在修改数据时会创建该数据的一个快照版本，其他读请求可以读取这个旧版本的数据，而不会被写操作阻塞。这也就是可重复读和读已提交隔离级别的工作原理。

您问到的B+树与B树的区别，这正是InnoDB选择B+树作为索引结构的关键原因。它们的核心区别有三点：

1. 数据的存储位置：

   • B树的每个节点，无论是非叶子节点还是叶子节点，都会存储数据本身（即对应的行数据）。
   • B+树的非叶子节点只存储键值和指向子节点的指针，并不存储实际的数据行。所有数据行都存储在叶子节点上，并且叶子节点之间通过指针相连，形成了一个有序的双向链表。

2. 查询性能：

   • 由于B树的节点也存数据，所以查询可能在非叶子节点就命中并返回，看起来可能更快，但性能不稳定，最好的情况是很快，最坏的情况要到叶子节点。
   • B+树的所有查询都必须走到叶子节点才能拿到数据，所以每次查询的耗时是稳定的。并且因为非叶子节点不存数据，所以同样大小的节点，B+树可以存储更多的键值，从而使得树的高度更低，减少了磁盘I/O次数。

3. 范围查询：

   • B树进行范围查询需要进行复杂的中序遍历。
   • B+树因为所有叶子节点构成了一个有序链表，所以进行范围查询时，只需要在叶子节点上顺序遍历即可，效率极高。这对于数据库来说是非常频繁和重要的操作。

总结来说，B+树通过牺牲非叶子节点的数据存储能力，换来了更稳定的查询性能、更低的树高和无比高效的范围查询能力，这些特性使其比B树更适合作为数据库的索引结构。

以上就是我的理解，谢谢。

计算机网络的四层模型和七层模型了解吗？TCP位于四层中的哪一层？

好的，面试官。

计算机网络的分层模型主要有两个经典参考：一个是理论上的OSI七层模型，另一个是实践中广泛使用的TCP/IP四层模型。它们都是通过分层的思想，将复杂的网络通信过程分解为多个独立的模块，每一层负责特定的功能，层与层之间通过接口进行协作。

首先，OSI七层模型是一个理论框架，定义得非常完整和清晰，从上到下分别是：

1. 应用层：为应用程序提供网络服务接口，比如HTTP、FTP、SMTP协议。
2. 表示层：负责数据的转换、加密和压缩，确保一个系统应用层发出的信息另一个系统的应用层能够读懂。
3. 会话层：负责建立、管理和终止两个通信主机之间的会话。
4. 传输层：负责提供端到端的可靠数据传输，定义了TCP和UDP等关键协议。
5. 网络层：负责进行逻辑寻址和路由选择，将数据从一个网络传输到另一个网络，核心协议是IP协议。
6. 数据链路层：负责在同一个局域网内，通过MAC地址进行寻址，并差错校验。
7. 物理层：负责在物理介质上传输原始的比特流，定义电气特性和网线接口等。

而在实际的互联网应用中，我们更常使用的是TCP/IP四层模型，它更侧重于实践，可以看作是OSI模型的一个精简和合并。这四层是：

1. 应用层：对应了OSI的应用层、表示层和会话层。所有和应用程序协同工作，利用网络交换数据的协议都在这一层，比如我们开发中最常打交道的HTTP、HTTPS、DNS等。
2. 传输层：与OSI的传输层完全对应，核心协议就是TCP和UDP。TCP提供面向连接的、可靠的数据传输；UDP则提供无连接的、尽最大努力交付的数据传输。
3. 网络层：有时也叫网际层，与OSI的网络层对应，核心协议是IP协议（IPv4, IPv6），负责数据的路由和转发。
4. 网络接口层：对应了OSI的数据链路层和物理层，负责处理与物理网络硬件的细节，比如以太网、Wi-Fi等。

所以，针对您的问题“TCP位于四层中的哪一层？”，答案非常明确：TCP协议位于TCP/IP四层模型中的传输层。它的核心职责就是在不可靠的网络IP层之上，通过三次握手建立连接、通过确认和重传机制保证数据包的可靠传递、通过流量控制和拥塞控制来优化网络性能，为上层应用提供一个可靠的、端到端的通信通道。

在我的实际开发中，理解这个分层模型非常有助于我们进行问题排查。比如，当出现网络问题时，我们可以自底向上地进行排查：先检查网络接口层（网线、网卡）、再检查网络层（IP地址、路由），最后检查传输层（端口、防火墙）和应用层（应用程序本身），这种思路能极大地提高排查效率。

以上就是我的理解，谢谢。