腾讯有点顶，连环追问我基础细节！

小林coding 2023-12-11 595

小林coding

62 文章 7.6w阅读 1粉丝

描述

 

大家好，我是小林。

这次跟大家分享一位同学面腾讯后端开发的面经，一步一步深挖计算机基础的内容，问的问题很多，光面试时常长达 1 个小时多，再加上写算法 20 分钟，面试的强度还是挺大的。

虽然面试强度是比较大了一点，但是整体面下来，同学反馈还是很有收获的，也算是对自己没掌握的内容进行查漏补缺的过程。

计算机网络

网络七层模型分别是什么？

为了使得多种设备能通过网络相互通信，和为了解决各种不同设备在网络互联中的兼容性问题，国际标准化组织制定了开放式系统互联通信参考模型（Open System Interconnection Reference Model），也就是 OSI 网络模型，该模型主要有 7 层，分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。

传输层img

  • 应用层：应用层最接近终端用户。大多数应用程序都位于这一层。我们从后端服务器请求数据，无需了解数据传输的具体细节。这一层的协议包括 HTTP、SMTP、FTP、DNS 等。

  • 表示层：这一层处理数据编码、加密和压缩，为应用层准备数据。例如，HTTPS 利用 TLS（Transport Layer Security）实现客户端与服务器之间的安全通信。

  • 会话层：该层用于打开和关闭两个设备之间的通信。如果数据量较大，会话层就会设置检查点，避免从头开始重新发送。

  • 传输层：该层处理两个设备之间的端到端的通信。它在发送方将数据分解成段，然后在接收方重新组装。这一层有流量控制，以防止拥塞。这一层的主要协议是 TCP 和 UDP。

  • 网络层：这一层实现不同网络之间的数据传输。它进一步将网段或数据报分解成更小的数据包，并使用 IP 地址找到通往最终目的地的最佳路由。

  • 数据链路层：这一层允许在同一网络的设备之间传输数据。数据包被分解成帧，这些帧被限制在局域网内。

  • 物理层：这一层通过电缆和交换机发送比特流，因此与设备之间的物理连接密切相关。与 OSI 模型相比，TCP/IP 模型只有 4 层。在讨论网络协议的层次时，必须明确上下文。

TCP和UDP的应用场景是哪些？

TCP适用：网页、电子邮件、远程登录连接、文件传输

UDP适用：语音通话，多播通信，DNS解析

TCP如何实现可靠传输？

面向连接、同步序列号、校验和、流量控制和拥塞控制。

  • 序列号与确认机制：TCP将每个数据包分配一个唯一的序列号，并且接收方会发送确认消息来确认已经接收到的数据。发送方会根据接收到的确认消息判断是否需要重新发送丢失的数据包。
  • 数据校验和：TCP使用校验和来验证数据在传输过程中是否发生了损坏。接收方会计算校验和并与发送方发送的校验和进行比较，如果不一致，则说明数据包发生了损坏，需要重新发送。
  • 滑动窗口机制：TCP使用滑动窗口来控制发送方发送数据的速度和接收方接收数据的速度，以避免因发送速度过快或接收速度过慢而导致的数据丢失或堵塞。
  • 重传机制：如果发送方没有收到接收方的确认消息，或者接收方收到的数据包校验和不一致，发送方会重新发送数据包，确保数据的可靠传输。
  • 拥塞控制：TCP具有拥塞控制机制，可以根据网络的拥塞情况来调整发送数据的速率，避免网络拥塞导致的数据丢失和延迟。

第一次握手，客户端发送SYN报后，服务端回复ACK报，那这个过程中服务端内部做了哪些工作？

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

传输层半连接队列与全连接队列

不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回 RST 包。

大量SYN包发送给服务端服务端会发生什么事情？

有可能会导致TCP 半连接队列打满，这样当 TCP 半连接队列满了，后续再在收到 SYN 报文就会丢弃，导致客户端无法和服务端建立连接。

避免 SYN 攻击方式，可以有以下四种方法：

  • 调大 netdev_max_backlog；
  • 增大 TCP 半连接队列；
  • 开启 tcp_syncookies；
  • 减少 SYN+ACK 重传次数

方式一：调大 netdev_max_backlog

当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数，默认值是 1000，我们要适当调大该参数的值，比如设置为 10000：

net.core.netdev_max_backlog = 10000

方式二：增大 TCP 半连接队列

增大 TCP 半连接队列，要同时增大下面这三个参数：

  • 增大 net.ipv4.tcp_max_syn_backlog
  • 增大 listen() 函数中的 backlog
  • 增大 net.core.somaxconn

方式三：开启 net.ipv4.tcp_syncookies

开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接，相当于绕过了 SYN 半连接来建立连接。

传输层tcp_syncookies 应对 SYN 攻击

具体过程：

  • 当 「 SYN 队列」满之后，后续服务端收到 SYN 包，不会丢弃，而是根据算法，计算出一个 cookie 值；
  • 将 cookie 值放到第二次握手报文的「序列号」里，然后服务端回第二次握手给客户端；
  • 服务端接收到客户端的应答报文时，服务端会检查这个 ACK 包的合法性。如果合法，将该连接对象放入到「 Accept 队列」。
  • 最后应用程序通过调用 accpet() 接口，从「 Accept 队列」取出的连接。

可以看到，当开启了 tcp_syncookies 了，即使受到 SYN 攻击而导致 SYN 队列满时，也能保证正常的连接成功建立。

net.ipv4.tcp_syncookies 参数主要有以下三个值：

  • 0 值，表示关闭该功能；
  • 1 值，表示仅当 SYN 半连接队列放不下时，再启用它；
  • 2 值，表示无条件开启功能；

那么在应对 SYN 攻击时，只需要设置为 1 即可。

$ echo 1 > /proc/sys/net/ipv4/tcp_syncookies

方式四：减少 SYN+ACK 重传次数

当服务端受到 SYN 攻击时，就会有大量处于 SYN_REVC 状态的 TCP 连接，处于这个状态的 TCP 会重传 SYN+ACK ，当重传超过次数达到上限后，就会断开连接。

那么针对 SYN 攻击的场景，我们可以减少 SYN-ACK 的重传次数，以加快处于 SYN_REVC 状态的 TCP 连接断开。

SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定（默认值是 5 次），比如将 tcp_synack_retries 减少到 2 次：

$ echo 2 > /proc/sys/net/ipv4/tcp_synack_retries

服务端默认能接受多少个连接？

TCP 四元组可以唯一的确定一个连接，四元组包括如下：

  • 源地址
  • 源端口
  • 目的地址
  • 目的端口
传输层TCP 四元组

源地址和目的地址的字段（32 位）是在 IP 头部中，作用是通过 IP 协议发送报文给对方主机。

源端口和目的端口的字段（16 位）是在 TCP 头部中，作用是告诉 TCP 协议应该把报文发给哪个进程。

有一个 IP 的服务端监听了一个端口，它的 TCP 的最大连接数是多少？

服务端通常固定在某个本地端口上监听，等待客户端的连接请求。

因此，客户端 IP 和端口是可变的，其理论值计算公式如下:

传输层img

对 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数，约为 2 的 48 次方。

当然，服务端最大并发 TCP 连接数远不能达到理论上限，会受以下因素影响：

  • 文件描述符限制

    ，每个 TCP 连接都是一个文件，如果文件描述符被占满了，会发生 Too many open files。Linux 对可打开的文件描述符的数量分别作了三个方面的限制：

    • 系统级：当前系统可打开的最大数量，通过 cat /proc/sys/fs/file-max 查看；
    • 用户级：指定用户可打开的最大数量，通过 cat /etc/security/limits.conf 查看；
    • 进程级：单个进程可打开的最大数量，通过 cat /proc/sys/fs/nr_open 查看；

  • 内存限制，每个 TCP 连接都要占用一定内存，操作系统的内存是有限的，如果内存资源被占满后，会发生 OOM。

从输入url到页面显示发生了哪些事情？

传输层图片
  • 解析URL：分析 URL 所需要使用的传输协议和请求的资源路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，则对非法字符进行转义后在进行下一过程。
  • 缓存判断：浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里且没有失效，那么就直接使用，否则向服务器发起新的请求。
  • DNS解析：如果资源不在本地缓存，首先需要进行DNS解析。浏览器会向本地DNS服务器发送域名解析请求，本地DNS服务器会逐级查询，最终找到对应的IP地址。
  • 获取MAC地址：当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相结合，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。
  • 建立TCP连接：主机将使用目标 IP地址和目标MAC地址发送一个TCP SYN包，请求建立一个TCP连接，然后交给路由器转发，等路由器转到目标服务器后，服务器回复一个SYN-ACK包，确认连接请求。然后，主机发送一个ACK包，确认已收到服务器的确认，然后 TCP 连接建立完成。
  • HTTPS 的 TLS 四次握手：如果使用的是 HTTPS 协议，在通信前还存在 TLS 的四次握手。
  • 发送HTTP请求：连接建立后，浏览器会向服务器发送HTTP请求。请求中包含了用户需要获取的资源的信息，例如网页的URL、请求方法（GET、POST等）等。
  • 服务器处理请求并返回响应：服务器收到请求后，会根据请求的内容进行相应的处理。例如，如果是请求网页，服务器会读取相应的网页文件，并生成HTTP响应。

拿到IP地址还要去获取MAC地址，TCP连接需要用到MAC地址吗？

也需要的，客户端发送第一个 syn 报文的时候，也需要在数据链路层组装 mac 地址的。

DNS解析流程？

传输层域名解析的工作流程
  1. 客户端首先会发出一个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
  2. 本地域名服务器收到客户端的请求后，如果缓存里的表格能找到 www.server.com，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大， 能告诉我 www.server.com 的 IP 地址吗？” 根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
  3. 根 DNS 收到来自本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
  4. 本地 DNS 收到顶级域名服务器的地址后，发起请求问“老二， 你能告诉我 www.server.com 的 IP 地址吗？”
  5. 顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
  6. 本地 DNS 于是转向问权威 DNS 服务器：“老三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
  7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
  8. 本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。

至此，我们完成了 DNS 的解析过程。现在总结一下，整个过程我画成了一个图。

网页非常慢转圈圈的时候，要定位问题需要从哪些角度？

最直接的办法就是抓包，排查的思路大概有：

  1. 先确定是服务端的问题，还是客户端的问题。先确认浏览器是否可以访问其他网站，如果不可以，说明客户端网络自身的问题，然后检查客户端网络配置（连接wifi正不正常，有没有插网线）；如果可以正常其他网页，说明客户端网络是可以正常上网的。

  2. 如果客户端网络没问题，就抓包确认 DNS 是否解析出了 IP 地址，如果没有解析出来，说明域名写错了，如果解析出了 IP 地址，抓包确认有没有和服务端建立三次握手，如果能成功建立三次握手，并且发出了 HTTP 请求，但是就是没有显示页面，可以查看服务端返回的响应码：

  3.  
  • 如果是404错误码，检查输入的url是否正确；
  • 如果是500，说明服务器此时有问题；
  • 如果是200，F12看看前端代码有问题导致浏览器没有渲染出页面。

  • 如果客户端网络是正常的，但是访问速度很慢，导致很久才显示出来。这时候要看客户端的网口流量是否太大的了，导致tcp发生丢包之类的问题。

总之就是一层一层有没有插网线，网络配置是否正确、DNS有没有解析出 IP地址、TCP有没有三次握手、HTTP返回的响应码是什么。

推荐阅读：网站显示不出来，怎么排查？

HTTP默认的端口是什么？

http 是 80，https 默认是 443。

端口通不通用什么命令？

第一种方式：telnet：telnet命令用于建立与远程主机的Telnet连接，并可以使用telnet命令测试特定端口的可访问性。

  • 示例：telnet IP地址 端口号 用于测试指定IP地址上的指定端口是否可访问。如果能够建立连接，则表示端口通畅；如果连接失败或超时，则表示端口不可访问。

第二种方式：nc：nc命令（也称为netcat）是一个网络工具，可以用于创建各种类型的网络连接，包括测试端口的可访问性。

  • 示例：nc -zv IP地址 端口号 用于测试指定IP地址上的指定端口是否可访问。如果能够成功连接，则表示端口通畅；如果连接失败或拒绝，则表示端口不可访问。

linux端口状态查询有哪些命令？

  • netstat -tunlp 用于显示所有TCP和UDP端口的监听状态。

  • lsof -i :端口号 用于显示指定端口的相关信息。

ping命令走的是什么协议？

ICMP 协议。

传输层ICMP 回送消息

错误返回码认识哪些？

传输层五大类 HTTP 状态码
  • 1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。
  • 2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。
  • 3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。
  • 4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。
  • 5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

403代表什么含义？

「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

常见的情况包括：

  • 客户端尝试访问需要身份验证的资源，但未提供有效的凭据。
  • 客户端尝试访问受限制的目录或文件。
  • 客户端的IP地址被服务器所禁止访问。

重定向的作用？

重定向状态码如下，301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

  • 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
  • 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

重定向是指将一个URL请求转发到另一个URL的过程。重定向的作用包括：

  • 更改URL：通过重定向，可以更改URL，使其更易于记忆、更友好或更有意义。例如，将长而复杂的URL重定向到简洁的、易于理解的URL。

  • 网站迁移：当网站进行重构、更换域名或更改URL结构时，通过重定向旧的URL到新的URL，可以让用户和搜索引擎正确地访问和索引新的内容。

反向代理，那正向代理是什么？

传输层图片来源：ByteByteGo
  • 正向代理是位于用户设备和互联网之间的服务器。它代理的是客户端，是站在用户一方的。其真实客户端对于服务器不可见。
  • 反向代理是一种服务器，它接受客户端的请求，将请求转发给网络服务器，然后将结果返回给客户端，就像代理服务器处理了请求一样。

推荐阅读：面试官：你背一下负载均衡算法？

TCP的拥塞控制介绍一下？

拥塞控制是用于在网络拥塞时减少网络流量和避免网络崩溃。

传输层

TCP的拥塞控制机制主要包括以下几个方面：

  • 慢启动：当建立连接或恢复丢失的数据包时，TCP会以指数增加的方式逐渐增加发送窗口的大小，从而逐渐增加发送的数据量。

  • 拥塞避免：在慢启动阶段，当检测到网络拥塞时，TCP会切换到拥塞避免模式。拥塞避免使用线性增加的方式逐渐增加发送窗口的大小，以降低网络拥塞的风险。

  • 快速重传：当发送方连续接收到同一个确认号的重复确认时，它会认为该数据包已经丢失，并立即重新发送丢失的数据包，而不等待超时重传。

  • 快速恢复：在快速重传后，发送方会将拥塞窗口减半，并使用拥塞避免模式逐渐增加发送窗口的大小，以便恢复正常的发送速率。

通过这些机制，TCP能够根据网络的拥塞情况动态调整发送窗口的大小和发送速率，以避免网络拥塞并保证数据的可靠传输。拥塞控制是TCP协议的重要特性，它在保持网络稳定和高效运行方面起着重要作用。

HTTP层请求的类型有哪些？

  • GET：用于请求获取指定资源，通常用于获取数据。

  • POST：用于向服务器提交数据，通常用于提交表单数据或进行资源的创建。

  • PUT：用于向服务器更新指定资源，通常用于更新已存在的资源。

  • DELETE：用于请求服务器删除指定资源。

  • HEAD：类似于GET请求，但只返回资源的头部信息，用于获取资源的元数据而不获取实际内容。

GET和POST的使用场景，有哪些区别？

根据 RFC 规范，GET 的语义是从服务器获取指定的资源，这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。

比如，你打开我的文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。

传输层GET 请求

根据 RFC 规范，POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。

比如，你在我文章底部，敲入了留言后点击「提交」（暗示你们留言），浏览器就会执行一次 POST 请求，把你的留言文字放进了报文 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。

传输层POST 请求

如果从 RFC 规范定义的语义来看：

  • GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签。
  • POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。

但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：

  • 可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。
  • 可以用 POST 方法实现查询数据的请求，这样实现的 POST 方法自然就是安全和幂等。

HTTP的长连接是什么？

HTTP 协议采用的是「请求-应答」的模式，也就是客户端发起了请求，服务端才会返回响应，一来一回这样子。

传输层请求-应答

由于 HTTP 是基于 TCP 传输协议实现的，客户端与服务端要进行 HTTP 通信前，需要先建立 TCP 连接，然后客户端发送 HTTP 请求，服务端收到后就返回响应，至此「请求-应答」的模式就完成了，随后就会释放 TCP 连接。

传输层一个 HTTP 请求

如果每次请求都要经历这样的过程：建立 TCP -> 请求资源 -> 响应资源 -> 释放连接，那么此方式就是 HTTP 短连接，如下图：

传输层HTTP 短连接

这样实在太累人了，一次连接只能请求一次资源。

能不能在第一个 HTTP 请求完后，先不断开 TCP 连接，让后续的 HTTP 请求继续使用此连接？

当然可以，HTTP 的 Keep-Alive 就是实现了这个功能，可以使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，避免了连接建立和释放的开销，这个方法称为 HTTP 长连接。

传输层HTTP 长连接

HTTP 长连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

HTTP长连接与WebSocket有什么区别？

  • 全双工和半双工：TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。
  • 应用场景区别：在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。

操作系统

进程跟线程的区别？

传输层
  • 本质区别：进程是操作系统资源分配的基本单位，而线程是任务调度和执行的基本单位
  • 在开销方面：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小
  • 所处环境：在操作系统中能同时运行多个进程（程序）；而在同一个进程（程序）中有多个线程同时执行（通过CPU调度，在每个时间片中只有一个线程执行）
  • 内存分配方面：系统在运行的时候会为每个进程分配不同的内存空间；而对线程而言，除了CPU外，系统不会为线程分配内存（线程所使用的资源来自其所属进程的资源），线程组之间只能共享资源
  • 包含关系：没有线程的进程可以看做是单线程的，如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程

举个例子：进程=火车，线程=车厢

  • 线程在进程下行进（单纯的车厢无法运行）
  • 一个进程可以包含多个线程（一辆火车可以有多个车厢）
  • 不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）
  • 同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）
  • 进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）
  • 进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）

多线程是不是越多越好，太多会有什么问题？

多线程不一定越多越好，过多的线程可能会导致一些问题。

  • 切换开销：线程的创建和切换会消耗系统资源，包括内存和CPU。如果创建太多线程，会占用大量的系统资源，导致系统负载过高，某个线程崩溃后，可能会导致进程崩溃。
  • 死锁的问题：过多的线程可能会导致竞争条件和死锁。竞争条件指的是多个线程同时访问和修改共享资源，如果没有合适的同步机制，可能会导致数据不一致或错误的结果。而死锁则是指多个线程相互等待对方释放资源，导致程序无法继续执行。

进程调度算法有哪些？

01 先来先服务调度算法

最简单的一个调度算法，就是非抢占式的先来先服务（*First Come First Serve, FCFS*）算法了。

传输层FCFS 调度算法

顾名思义，先来后到，每次从就绪队列选择最先进入队列的进程，然后一直运行，直到进程退出或被阻塞，才会继续从队列中选择第一个进程接着运行。

这似乎很公平，但是当一个长作业先运行了，那么后面的短作业等待的时间就会很长，不利于短作业。

FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用于 I/O 繁忙型作业的系统。

02 最短作业优先调度算法

最短作业优先（*Shortest Job First, SJF*）调度算法同样也是顾名思义，它会优先选择运行时间最短的进程来运行，这有助于提高系统的吞吐量。

传输层SJF 调度算法

这显然对长作业不利，很容易造成一种极端现象。

比如，一个长作业在就绪队列等待运行，而这个就绪队列有非常多的短作业，那么就会使得长作业不断的往后推，周转时间变长，致使长作业长期不会被运行。

03 高响应比优先调度算法

前面的「先来先服务调度算法」和「最短作业优先调度算法」都没有很好的权衡短作业和长作业。

那么，高响应比优先 （*Highest Response Ratio Next, HRRN*）调度算法主要是权衡了短作业和长作业。

每次进行进程调度时，先计算「响应比优先级」，然后把「响应比优先级」最高的进程投入运行，「响应比优先级」的计算公式：

传输层

从上面的公式，可以发现：

  • 如果两个进程的「等待时间」相同时，「要求的服务时间」越短，「响应比」就越高，这样短作业的进程容易被选中运行；
  • 如果两个进程「要求的服务时间」相同时，「等待时间」越长，「响应比」就越高，这就兼顾到了长作业进程，因为进程的响应比可以随时间等待的增加而提高，当其等待时间足够长时，其响应比便可以升到很高，从而获得运行的机会；

04 时间片轮转调度算法

最古老、最简单、最公平且使用最广的算法就是时间片轮转（*Round Robin, RR*）调度算法。

传输层RR 调度算法

每个进程被分配一个时间段，称为时间片（*Quantum*），即允许该进程在该时间段中运行。

  • 如果时间片用完，进程还在运行，那么将会把此进程从 CPU 释放出来，并把 CPU 分配给另外一个进程；
  • 如果该进程在时间片结束前阻塞或结束，则 CPU 立即进行切换；

另外，时间片的长度就是一个很关键的点：

  • 如果时间片设得太短会导致过多的进程上下文切换，降低了 CPU 效率；
  • 如果设得太长又可能引起对短作业进程的响应时间变长。将

一般来说，时间片设为 20ms~50ms 通常是一个比较合理的折中值。

05 最高优先级调度算法

前面的「时间片轮转算法」做了个假设，即让所有的进程同等重要，也不偏袒谁，大家的运行时间都一样。

但是，对于多用户计算机系统就有不同的看法了，它们希望调度是有优先级的，即希望调度程序能从就绪队列中选择最高优先级的进程进行运行，这称为最高优先级（*Highest Priority First，HPF*）调度算法。

进程的优先级可以分为，静态优先级和动态优先级：

  • 静态优先级：创建进程时候，就已经确定了优先级了，然后整个运行时间优先级都不会变化；
  • 动态优先级：根据进程的动态变化调整优先级，比如如果进程运行时间增加，则降低其优先级，如果进程等待时间（就绪队列的等待时间）增加，则升高其优先级，也就是随着时间的推移增加等待进程的优先级。

该算法也有两种处理优先级高的方法，非抢占式和抢占式：

  • 非抢占式：当就绪队列中出现优先级高的进程，运行完当前进程，再选择优先级高的进程。
  • 抢占式：当就绪队列中出现优先级高的进程，当前进程挂起，调度优先级高的进程运行。

但是依然有缺点，可能会导致低优先级的进程永远不会运行。

06 多级反馈队列调度算法

多级反馈队列（*Multilevel Feedback Queue*）调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。

顾名思义：

  • 「多级」表示有多个队列，每个队列优先级从高到低，同时优先级越高时间片越短。
  • 「反馈」表示如果有新的进程加入优先级高的队列时，立刻停止当前正在运行的进程，转而去运行优先级高的队列；

传输层多级反馈队列

来看看，它是如何工作的：

  • 设置了多个队列，赋予每个队列不同的优先级，每个队列优先级从高到低，同时优先级越高时间片越短；
  • 新的进程会被放入到第一级队列的末尾，按先来先服务的原则排队等待被调度，如果在第一级队列规定的时间片没运行完成，则将其转入到第二级队列的末尾，以此类推，直至完成；
  • 当较高优先级的队列为空，才调度较低优先级的队列中的进程运行。如果进程运行时，有新进程进入较高优先级的队列，则停止当前运行的进程并将其移入到原队列末尾，接着让较高优先级的进程运行；

可以发现，对于短作业可能可以在第一级队列很快被处理完。对于长作业，如果在第一级队列处理不完，可以移入下次队列等待被执行，虽然等待的时间变长了，但是运行时间也变更长了，所以该算法很好的兼顾了长短作业，同时有较好的响应时间。

数据库

MySQL和Redis的区别，应用场景？

MySQL  是关系型数据库，适用于需要保持数据一致性、进行复杂的数据分析和关联查询的场景。

Redis是一种基于内存的数据存储系统，它主要用于缓存和高速数据访问。Redis适合处理高速读写和缓存需求，适用于需要快速响应和高并发的场景，例如实时计数器、会话缓存、消息队列、发布/订阅系统等。

一般会用Redis 作为MySQL的缓存，主要是因为 Redis 具备「高性能」和「高并发」两种特性。

1、Redis 具备高性能

假如用户第一次访问 MySQL 中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据缓存在 Redis 中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了，操作 Redis 缓存就是直接操作内存，所以速度相当快。

传输层img

如果 MySQL 中的对应数据改变的之后，同步改变 Redis 缓存中相应的数据即可，不过这里会有 Redis 和 MySQL 双写一致性的问题，后面我们会提到。

2、Redis 具备高并发

单台设备的 Redis 的 QPS（Query Per Second，每秒钟处理完请求的次数） 是 MySQL 的 10 倍，Redis 单机的 QPS 能轻松破 10w，而 MySQL 单机的 QPS 很难破 1w。

所以，直接访问 Redis 能够承受的请求是远远大于直接访问 MySQL 的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

MySQL有哪些存储引擎?有什么区别？

  • InnoDB：支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。

  • MyISAM：插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比 较低，也可以使用。如果数据表主要用来插入和查询记录，则MyISAM引擎能提供较高的处理效率

  • MEMORY：所有的数据都在内存中，数据的处理速度快，但是安全性不高。如果需要很快的读写速度，对数据的安全性要求较低，可以选择MEMOEY。它对表的大小有要求，不能建立太大的表。所以，这类数据库只使用在相对较小的数据库表。如果只是临时存放数据，数据量不大，并且不需要较高的数据安全性，可以选择将数据保存在内存中的Memory引擎，MySQL中使用该引擎作为临时表，存放查询的中间结果

事务用来解决什么问题？

事务用于解决数据库操作中的一致性和持久性问题。

  • 一致性问题指的是在多个并发操作中，如果其中一个操作失败或发生错误，可能导致数据处于不一致的状态，不符合预期的要求。

  • 持久性问题指的是确保已提交的数据在数据库系统

事务的四大特性主要是：

  • 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节，而且事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样，就好比买一件商品，购买成功时，则给商家付了钱，商品到手；购买失败时，则商品在商家手中，消费者的钱也没花出去。
  • 一致性（Consistency）：是指事务操作前和操作后，数据满足完整性约束，数据库保持一致性状态。比如，用户 A 和用户 B 在银行分别有 800 元和 600 元，总共 1400 元，用户 A 给用户 B 转账 200 元，分为两个步骤，从 A 的账户扣除 200 元和对 B 的账户增加 200 元。一致性就是要求上述步骤操作后，最后的结果是用户 A 还有 600 元，用户 B 有 800 元，总共 1400 元，而不会出现用户 A 扣除了 200 元，但用户 B 未增加的情况（该情况，用户 A 和 B 均为 600 元，总共 1200 元）。
  • 隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致，因为多个事务同时使用相同的数据时，不会相互干扰，每个事务都有一个完整的数据空间，对其他并发事务是隔离的。也就是说，消费者购买商品这个事务，是不影响其他消费者购买的。
  • 持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

MySQL存储的数据结构是怎么样的？

InnoDB 存储引擎的索引结构是 b+树。

传输层

选择 b+树作为数据结构的原因是：

  • B+Tree vs B Tree：B+Tree 只在叶子节点存储数据，而 B 树 的非叶子节点也要存储数据，所以 B+Tree 的单个节点的数据量更小，在相同的磁盘 I/O 次数下，就能查询更多的节点。另外，B+Tree 叶子节点采用的是双链表连接，适合 MySQL 中常见的基于范围的顺序查找，而 B 树无法做到这一点。
  • B+Tree vs 二叉树：对于有 N 个叶子节点的 B+Tree，其搜索复杂度为O(logdN)，其中 d 表示节点允许的最大子节点个数为 d 个。在实际的应用当中， d 值是大于100的，这样就保证了，即使数据达到千万级别时，B+Tree 的高度依然维持在 3~4 层左右，也就是说一次数据查询操作只需要做 3~4 次的磁盘 I/O 操作就能查询到目标数据。而二叉树的每个父节点的儿子节点个数只能是 2 个，意味着其搜索复杂度为 O(logN)，这已经比 B+Tree 高出不少，因此二叉树检索到目标数据所经历的磁盘 I/O 次数要更多。
  • B+Tree vs Hash：Hash 在做等值查询的时候效率贼快，搜索复杂度为 O(1)。但是 Hash 表不适合做范围查询，它更适合做等值的查询，这也是 B+Tree 索引要比 Hash 表索引有着更广泛的适用场景的原因。

Text数据类型可以无限大吗？

MySQL 3 种text类型的最大长度如下：

  • TEXT：65,535 bytes ~64kb
  • MEDIUMTEXT：16,777,215 bytes ~16Mb
  • LONGTEXT：4,294,967,295 bytes ~4Gb

MySQL索引的优缺点？

索引最大的好处是提高查询速度，但是索引也是有缺点的，比如：

  • 需要占用物理空间，数量越大，占用空间越大；
  • 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增大；
  • 会降低表的增删改的效率，因为每次增删改索引，B+ 树为了维护索引有序性，都需要进行动态维护。

所以，索引不是万能钥匙，它也是根据场景来使用的。

什么时候不适合用索引？

  • WHERE 条件，GROUP BY，ORDER BY 里用不到的字段，索引的价值是快速定位，如果起不到定位的字段通常是不需要创建索引的，因为索引是会占用物理空间的。
  • 字段中存在大量重复数据，不需要创建索引，比如性别字段，只有男女，如果数据库表中，男女的记录分布均匀，那么无论搜索哪个值都可能得到一半的数据。在这些情况下，还不如不要索引，因为 MySQL 还有一个查询优化器，查询优化器发现某个值出现在表的数据行中的百分比很高的时候，它一般会忽略索引，进行全表扫描。
  • 表数据太少的时候，不需要创建索引；
  • 经常更新的字段不用创建索引，比如不要对电商项目的用户余额建立索引，因为索引字段频繁修改，由于要维护 B+Tree的有序性，那么就需要频繁的重建索引，这个过程是会影响数据库性能的。

算法

  • 实现 LRU算法实现（链表+hashmap）
#include 
#include 
#include 

class LRUCache {
private:
    int capacity;
    std::unordered_map<int, std::list<std::pair<int, int>>::iterator> cache;
    std::list<std::pair<int, int>> lruList;

public:
    LRUCache(int capacity) {
        this->capacity = capacity;
    }

    int get(int key) {
        if (cache.find(key) == cache.end()) {
            return -1; // 如果key不存在，返回-1
        }

        // 将访问的节点移动到链表头部
        std::pair<int, int> keyValue = *cache[key];
        lruList.erase(cache[key]);
        lruList.push_front(keyValue);
        cache[key] = lruList.begin();

        return keyValue.second;
    }

    void put(int key, int value) {
        if (cache.find(key) == cache.end()) {
            // 如果容量已满，移除最久未使用的节点
            if (lruList.size() == capacity) {
                std::pair<int, int> lastPair = lruList.back();
                int lastKey = lastPair.first;
                cache.erase(lastKey);
                lruList.pop_back();
            }

            // 将新节点添加到链表头部
            lruList.push_front(std::make_pair(key, value));
            cache[key] = lruList.begin();
        } else {
            // 如果key已存在，更新节点的值，并将节点移动到链表头部
            lruList.erase(cache[key]);
            lruList.push_front(std::make_pair(key, value));
            cache[key] = lruList.begin();
        }
    }
};

int main() {
    LRUCache cache(2);

    cache.put(1, 1);
    cache.put(2, 2);
    std::cout << cache.get(1) << std::endl; // 输出1
    cache.put(3, 3);
    std::cout << cache.get(2) << std::endl; // 输出-1
    cache.put(4, 4);
    std::cout << cache.get(1) << std::endl; // 输出-1
    std::cout << cache.get(3) << std::endl; // 输出3
    std::cout << cache.get(4) << std::endl; // 输出4

    return 0;
}

 


打开APP阅读更多精彩内容
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

下载APP
|投诉反馈|电子发烧友网
© 2021 elecfans.com
湘ICP备2023018690号
×
20
完善资料，
赚取积分