你该关注的运维技术大盘点
2017-12-29 17:13:26 
阿炯
近些年来，软件领域发生了翻天覆地的变化。从操作系统、数据库等底层基础架构，到分布式系统、大数据、云计算、机器学习等基础领域，从单体应用、MVC、服务化，到微服务化等应用开发模式，从 IaaS、PaaS、CaaS 到 FaaS，运维技术(特别是大规模复杂分布式系统的运维)也变得越来越重要，它已成为 IT 类企业提升生产力的核心。
随着运维受到越来越多的重视，运维体系也逐步丰富，出现了 DevOps 等理念将研发、测试、运维等流程连接起来。而容器技术更是从底层重构了运维，连接了开发、测试、部署、运行和监控全流程，进一步推动了运维体系从工具化逐步往平台化、自动化和智能化方向迁移。本文将对运维技术从底层到顶层做一个彻底的梳理和盘点。
微服务
微服务是近几年提出的概念，它通过将应用解耦成多个服务的方式来改善其模块化程度，使其更容易被理解、开发、测试和部署，更适用于小团队快速迭代式协作开发。同时，每个服务也能够采用不同的技术，便于持续进化。业界前沿互联网公司都构建了微服务框架(例如基于 Spring Boot/Spring Cloud 等开源项目)来应对其业务复杂性以及快速迭代过程中的效率问题。最近，微服务配置管理、容器化部署、自动化测试、微服务治理、微服务监控、安全、故障容忍等领域也受到越来越多的关注。
SRE
SRE(Site Reliability Engineering，网站可靠性工程)是来自于谷歌的一个最佳实践，它用于服务的容量规划和实施、保障服务的可靠性和性能，更多的在软件基础架构层面 构建自动化工具 来取代人工操作，从而更好地应对其业务复杂多变的需求。
DevOps & CI/CD
DevOps 逐步成为软件开发的主流，容器也已在过去两年中迅速成长为 DevOps 的核心，在持续集成、持续部署和持续发布等方面也越发受到重视。随着新的 DevOps 自动化工具不断涌现、容器及其相关生态的成熟(特别是容器编排工具及其对有状态服务的支持)、微服务的广泛应用，越来越多的相关工具将会集成在持续集成过程中，同时自动化持续测试也会变得更加流行，从而更有效地控制质量、保障安全、降低成本、控制风险、提升效率，更加高效的支持复杂的大型分布式应用。
容器优化与实践
过去几年间，以 Docker 为核心的容器技术在持续进化，以其构建、分发和部署的简易性成为 IT 基础架构中的关键技术。容器技术通过标准化运行环境的方式来连接了应用的研发、测试和运维。它简单、轻量，具备很强的可移植性，能更高效的利用资源，还能够有效的解决软件依赖问题，提高研发效率，降低研发成本，因此产业界也持续通过容器来优化其软件发布流程，容器化其遗留程序。
然而，容器技术本身也面临了不少挑战。未来，在容器标准化、容器安全、容器网络、容器存储特别是对数据库等有状态服务的支持等方面还存在很大的改进空间，容器的可管理性及易用性也需要进一步提升。
容器编排与管理
随着 Docker 等容器技术的广泛应用，容器编排和管理也受到了越来越多的关注，涌现出了诸于 Kubernetes、Apache Mesos、Docker Swarm Mode 等优秀的开源生态和解决方案。它们试图将目前以资源为中心的管理方式过渡到以应用为中心的管理方式，并且试图对应用的基础构成组件(例如配置、服务、负载均衡等)进行标准化，从而获得更好的可管理性。随着 CaaS 的发展，私有或公有的容器云也越来越多，越来越成熟，用户体验越来越好，从而显著降低迁移成本。
然而，在大规模的实践中，在灰度发布、资源调度、隔离性、运维监控、日志等方面仍有待进一步成熟和标准化，在跨数据中心的应用管理，混和云环境支持，跨云服务迁移，安全性等方面仍然面临着困难和挑战。
自动化运维
随着虚拟化和容器化等技术的出现，运维管理的复杂度和难度大大增加，因此必须通过专业化、标准化和流程化的手段来实现运维的自动化。业界出现了很多提升效率的自动化工具，例如 Puppet、Chef、Ansible、Saltstack 等。各大主流互联网公司也逐步从工具自动化往一站式自动化运维管理平台的方向进行演化，从而使得能够对部署、配置、监控、告警等进行一站式处理，实现资源和流程的标准化统一化、应用运行状态可视化管理，提升运维质量，降低运维成本。
智能化运维
随着监控范围的不断扩大，其产生的数据具备多样性、多维性和非结构化等特点，并且可能同业务数据存在相关性，传统的手动分析处理方式效率低且成本高。随着大数据和人工智能的兴起，越来越多的智能分析算法也应用于运维领域，它们通过分析运维系统本身所拥有和产生的海量数据，在问题定位、流量预测、辅助决策、智能报警和自动故障恢复等方面发挥出较大的作用，从而进一步降低运维成本。
运维基础架构
运维基础架构涵盖网络、机器、机房、机架、存储等的管理，涉及基础资源、机架设计和交付、网络架构设计、数据架构规划、操作系统、系统软件、环境交付和机器报废替换等方向。产业界构建了 CMDB 以支持服务交付流程和相应的管理流程，也构建了相应的初始化、部署、运行、监控、日志等工具。随着虚拟化、容器化和云计算的发展，运维基础架构也从 提供资源往提供能力的方向进行转变，提高应用对基础架构的透明性，进而提高基础架构的灵活性 。
数据库运维
数据库运维涉及数据库部署架构、容量规划、性能调优、数据备份和恢复、数据迁移、数据库监控审计、数据库运维管理，故障排除等一系列服务。
随着互联网更加广泛的使用，数据库运维也呈现出新的形态。近年来，在异地多活等部署模式、在线表模式变更、海量数据迁移、故障排除时，都会通过一系列的工具，来尽可能的减少数据库整体的不可用时间，从而尽可能的降低对用户的影响。同时，为了简化数据库的部署和管理，以容器化的方式来对数据库进行管理和调度也逐步成为热点之一。最后，在智能化运维方面，通过对数据库各项指标的分析和挖掘，提供智能化的诊断方案，提前预知和管控风险，提升处理效率系统整体稳定性。
大数据运维
随着数据的快速增长，以 Hadoop 为基础的生态系统也扮演了越来越重要的角色，它涵盖离线计算、流式计算、即席查询等多种使用方式，也涌现了 Hadoop、Spark、Kafka、Hbase、Storm、Phoenix 等优秀开源项目。在大数据平台的运维中，由于涉及分布式架构、多源异构海量数据存储、数据的处理框架更为多样化和复杂化等问题，大数据的运维也变得异常复杂。
大数据运维的主要目标是提高资源利用率，降低了大数据系统的运维复杂度，提升用户友好性。其中，计算资源的统一管理和调度能力，以容器为基础的多种类型大数据系统混合部署能力，快速弹性扩缩容能力，跨数据中心容灾能力，大数据应用监控能力和快速灵活的故障定位能力也变得越来越重要。
运维监控
监控是 IT 系统运维中保障核心业务稳定可用的重要环节，它涵盖网络、主机、业务、应用、性能等方面，涉及快速的故障通知，精准的故障定位和性能分析诊断等。当前比较流行并且在业界广泛应用开源的监控软件包括 Nagios、Cacti、Zabbix、Ganglia 等。
随着应用规模的迅速扩大以及 DevOps、微服务、容器等技术的快速发展，监控也出现新的形态。产业界已经从 Nagios 风格的监控方式中演化为流式风格，通过海量监控指标的流式处理，同时通过可视化平台来实时的展示监控指标。另外，随着基础设施变得更加动态，监控不但关心单个节点的运行状态，更关心整个业务系统的健康状态，全链路追踪等技术也已经现并得到广泛应用。
运维安全
在互联网化和移动化的背景下，应用逐渐往云中迁移，传统的边界变得越来越模糊，安全也有了新的发展趋势。过去的安全技术是以防御为主，采用传统防火墙、入侵防御系统等。现在，除了对传统的安全措施进行加强之外，还会在开发流程中引入一些安全实践，包括威胁建模，自动安全扫描、安全功能性测试等，从而降低安全风险，缩短安全问题的反馈周期。同时，安全也从事先预防转向为持续检测和快速响应，通过对攻击行为的持续检测，对安全事件进行快速响应，从而大幅降低损失。
游戏开发与运维
近年来，网络游戏的增长非常迅速，游戏开发采用通用化框架和引擎的趋势越来越明显。在游戏运维方面，除了常规的运维手段，游戏还有其自身的特点。首先，端游、页游和手游由于形式的不同， 其在联网方式、分发渠道、生命周期长短等方面存在差异，因此给网络接入、多渠道分发、容量规划、网络延时、档案数据高可靠存取等方面的运维都带来了挑战。
其次，由于用户增长存在不可预知性，游戏运维必须具备快速的扩缩容能力，多采用混合云或者公有云的技术架构，从而最大程度的提升其水平可扩展性。最后，在受到大规模 DDOS 异常流量攻击时，游戏运维应当具备多级流量清洗保护机制，具备服务降级的能力，从而尽可能的保证可用性。
互联网金融与运维
近几年来，互联网金融出现了井喷式发展，Fintech 也为其注入了技术创新基因。微服务、容器化、大数据和云计算等技术为互联网金融的快速迭代提供了基础。然而，相对于目前的应用运维，互联网金融行业有其自身的特点，其在数据留存、安全合规、防攻击能力、支付清算、金融监管、数据安全、大数据风控和高等级安全防护等方面都有较强需求甚至强制性的金融监管规范，也对互联网金融的运维提出了更高的挑战。
上文源自：运维技术大盘点-你该关注运维的哪一面
后端开发基础知识
上面简单说了运维的技术，来盘点一下与其非常相关的后端开发的技能体系：大致可分为计算机网络、操作系统、数据库、开发的基本知识。在此重点介绍前三者。
网络七层模型分别是什么？
为了使得多种设备能通过网络相互通信，和为了解决各种不同设备在网络互联中的兼容性问题，国际标准化组织制定了开放式系统互联通信参考模型（Open System Interconnection Reference Model），也就是 OSI 网络模型，该模型主要有 7 层，分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。
应用层：应用层最接近终端用户。大多数应用程序都位于这一层。我们从后端服务器请求数据，无需了解数据传输的具体细节。这一层的协议包括 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 和端口是可变的，其理论值计算公式如下:
对 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解析流程？
域名解析的工作流程
客户端首先会发出一个 DNS 请求，问 www.freeoa.net 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
本地域名服务器收到客户端的请求后，如果缓存里的表格能找到 www.freeoa.net，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大， 能告诉我 www.freeoa.net 的 IP 地址吗？” 根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
根 DNS 收到来自本地 DNS 的请求后，发现后置是 .net，说：“www.freeoa.net 这个域名归 .net 区域管理”，我给你 .net 顶级域名服务器地址给你，你去问问它吧。”
本地 DNS 收到顶级域名服务器的地址后，发起请求问“你好，能告诉我 www.freeoa.net 的 IP 地址吗？”
顶级域名服务器说：“我给你负责 www.freeoa.net 区域的权威 DNS 服务器的地址，去问它应该能问到”。
本地 DNS 于是转向问权威 DNS 服务器：“你好，www.freeoa.net对应的IP是多少？” freeoa.net 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是这个域名我做主。
权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。
至此完成了 DNS 的解析过程。现在总结一下，整个过程画成了一个图。
网页非常慢转圈圈的时候，要定位问题需要从哪些角度？
最直接的办法就是抓包，排查的思路大概有：
先确定是服务端的问题，还是客户端的问题。先确认浏览器是否可以访问其他网站，如果不可以，说明客户端网络自身的问题，然后检查客户端网络配置（连接wifi正不正常，有没有插网线）；如果可以正常其他网页，说明客户端网络是可以正常上网的。
如果客户端网络没问题，就抓包确认 DNS 是否解析出了 IP 地址，如果没有解析出来，说明域名写错了，如果解析出了 IP 地址，抓包确认有没有和服务端建立三次握手，如果能成功建立三次握手，并且发出了 HTTP 请求，但是就是没有显示页面，可以查看服务端返回的响应码：
如果是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 长连接
长连接的特点是只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
HTTP长连接与WebSocket有什么区别？
全双工和半双工：TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。
应用场景区别：在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。
操作系统
进程跟线程的区别？
本质区别：进程是操作系统资源分配的基本单位，而线程是任务调度和执行的基本单位
在开销方面：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小
所处环境：在操作系统中能同时运行多个进程（程序）；而在同一个进程（程序）中有多个线程同时执行（通过CPU调度，在每个时间片中只有一个线程执行）
内存分配方面：系统在运行的时候会为每个进程分配不同的内存空间；而对线程而言，除了CPU外，系统不会为线程分配内存（线程所使用的资源来自其所属进程的资源），线程组之间只能共享资源
包含关系：没有线程的进程可以看做是单线程的，如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程
举个例子：进程=火车，线程=车厢
线程在进程下行进（单纯的车厢无法运行）
一个进程可以包含多个线程（一辆火车可以有多个车厢）
不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）
同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）
进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）
进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）
多线程是不是越多越好，太多会有什么问题？
多线程不一定越多越好，过多的线程可能会导致一些问题。
切换开销：线程的创建和切换会消耗系统资源，包括内存和CPU。如果创建太多线程，会占用大量的系统资源，导致系统负载过高，某个线程崩溃后，可能会导致进程崩溃。
死锁的问题：过多的线程可能会导致竞争条件和死锁。竞争条件指的是多个线程同时访问和修改共享资源，如果没有合适的同步机制，可能会导致数据不一致或错误的结果。而死锁则是指多个线程相互等待对方释放资源，导致程序无法继续执行。
进程调度算法有哪些？
1 先来先服务调度算法
最简单的一个调度算法，就是非抢占式的先来先服务（*First Come First Serve, FCFS*）算法了。
FCFS 调度算法
顾名思义，先来后到，每次从就绪队列选择最先进入队列的进程，然后一直运行，直到进程退出或被阻塞，才会继续从队列中选择第一个进程接着运行。
这似乎很公平，但是当一个长作业先运行了，那么后面的短作业等待的时间就会很长，不利于短作业。
FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用于 I/O 繁忙型作业的系统。
2 最短作业优先调度算法
最短作业优先（*Shortest Job First, SJF*）调度算法同样也是顾名思义，它会优先选择运行时间最短的进程来运行，这有助于提高系统的吞吐量。
SJF 调度算法
这显然对长作业不利，很容易造成一种极端现象。
比如，一个长作业在就绪队列等待运行，而这个就绪队列有非常多的短作业，那么就会使得长作业不断的往后推，周转时间变长，致使长作业长期不会被运行。
3 高响应比优先调度算法
前面的「先来先服务调度算法」和「最短作业优先调度算法」都没有很好的权衡短作业和长作业。
那么，高响应比优先 （*Highest Response Ratio Next, HRRN*）调度算法主要是权衡了短作业和长作业。
每次进行进程调度时，先计算「响应比优先级」，然后把「响应比优先级」最高的进程投入运行，「响应比优先级」的计算公式：
从上面的公式，可以发现：
如果两个进程的「等待时间」相同时，「要求的服务时间」越短，「响应比」就越高，这样短作业的进程容易被选中运行；
如果两个进程「要求的服务时间」相同时，「等待时间」越长，「响应比」就越高，这就兼顾到了长作业进程，因为进程的响应比可以随时间等待的增加而提高，当其等待时间足够长时，其响应比便可以升到很高，从而获得运行的机会；
4 时间片轮转调度算法
最古老、最简单、最公平且使用最广的算法就是时间片轮转（*Round Robin, RR*）调度算法。
RR 调度算法
每个进程被分配一个时间段，称为时间片（*Quantum*），即允许该进程在该时间段中运行。
如果时间片用完，进程还在运行，那么将会把此进程从 CPU 释放出来，并把 CPU 分配给另外一个进程；
如果该进程在时间片结束前阻塞或结束，则 CPU 立即进行切换；
另外，时间片的长度就是一个很关键的点：
如果时间片设得太短会导致过多的进程上下文切换，降低了 CPU 效率；
如果设得太长又可能引起对短作业进程的响应时间变长。
一般来说，时间片设为 20ms~50ms 通常是一个比较合理的折中值。
5 最高优先级调度算法
前面的「时间片轮转算法」做了个假设，即让所有的进程同等重要，也不偏袒谁，大家的运行时间都一样。
但是，对于多用户计算机系统就有不同的看法了，它们希望调度是有优先级的，即希望调度程序能从就绪队列中选择最高优先级的进程进行运行，这称为最高优先级（*Highest Priority First，HPF*）调度算法。
进程的优先级可以分为，静态优先级和动态优先级：
静态优先级：创建进程时候，就已经确定了优先级了，然后整个运行时间优先级都不会变化；
动态优先级：根据进程的动态变化调整优先级，比如如果进程运行时间增加，则降低其优先级，如果进程等待时间（就绪队列的等待时间）增加，则升高其优先级，也就是随着时间的推移增加等待进程的优先级。
该算法也有两种处理优先级高的方法，非抢占式和抢占式：
非抢占式：当就绪队列中出现优先级高的进程，运行完当前进程，再选择优先级高的进程。
抢占式：当就绪队列中出现优先级高的进程，当前进程挂起，调度优先级高的进程运行。
但是依然有缺点，可能会导致低优先级的进程永远不会运行。
6 多级反馈队列调度算法
多级反馈队列（*Multilevel Feedback Queue*）调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。
顾名思义：
「多级」表示有多个队列，每个队列优先级从高到低，同时优先级越高时间片越短。
「反馈」表示如果有新的进程加入优先级高的队列时，立刻停止当前正在运行的进程，转而去运行优先级高的队列；
多级反馈队列
来看看它是如何工作的：
设置了多个队列，赋予每个队列不同的优先级，每个队列优先级从高到低，同时优先级越高时间片越短；
新的进程会被放入到第一级队列的末尾，按先来先服务的原则排队等待被调度，如果在第一级队列规定的时间片没运行完成，则将其转入到第二级队列的末尾，以此类推，直至完成；
当较高优先级的队列为空，才调度较低优先级的队列中的进程运行。如果进程运行时，有新进程进入较高优先级的队列，则停止当前运行的进程并将其移入到原队列末尾，接着让较高优先级的进程运行；
可以发现，对于短作业可能可以在第一级队列很快被处理完。对于长作业，如果在第一级队列处理不完，可以移入下次队列等待被执行，虽然等待的时间变长了，但是运行时间也变更长了，所以该算法很好的兼顾了长短作业，同时有较好的响应时间。
数据库
MySQL和Redis的区别，应用场景？
MySQL 是关系型数据库，适用于需要保持数据一致性、进行复杂的数据分析和关联查询的场景。Redis是一种基于内存的数据存储系统，它主要用于缓存和高速数据访问。Redis适合处理高速读写和缓存需求，适用于需要快速响应和高并发的场景，例如实时计数器、会话缓存、消息队列、发布/订阅系统等。一般会用Redis 作为MySQL的缓存，主要是因为 Redis 具备「高性能」和「高并发」两种特性。
1、Redis 具备高性能
假如用户第一次访问 MySQL 中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据缓存在 Redis 中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了，操作 Redis 缓存就是直接操作内存，所以速度相当快。
如果 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的有序性，那么就需要频繁的重建索引，这个过程是会影响数据库性能的。
随着运维受到越来越多的重视，运维体系也逐步丰富，出现了 DevOps 等理念将研发、测试、运维等流程连接起来。而容器技术更是从底层重构了运维，连接了开发、测试、部署、运行和监控全流程，进一步推动了运维体系从工具化逐步往平台化、自动化和智能化方向迁移。本文将对运维技术从底层到顶层做一个彻底的梳理和盘点。
微服务
微服务是近几年提出的概念，它通过将应用解耦成多个服务的方式来改善其模块化程度，使其更容易被理解、开发、测试和部署，更适用于小团队快速迭代式协作开发。同时，每个服务也能够采用不同的技术，便于持续进化。业界前沿互联网公司都构建了微服务框架(例如基于 Spring Boot/Spring Cloud 等开源项目)来应对其业务复杂性以及快速迭代过程中的效率问题。最近，微服务配置管理、容器化部署、自动化测试、微服务治理、微服务监控、安全、故障容忍等领域也受到越来越多的关注。
SRE
SRE(Site Reliability Engineering，网站可靠性工程)是来自于谷歌的一个最佳实践，它用于服务的容量规划和实施、保障服务的可靠性和性能，更多的在软件基础架构层面 构建自动化工具 来取代人工操作，从而更好地应对其业务复杂多变的需求。
DevOps & CI/CD
DevOps 逐步成为软件开发的主流，容器也已在过去两年中迅速成长为 DevOps 的核心，在持续集成、持续部署和持续发布等方面也越发受到重视。随着新的 DevOps 自动化工具不断涌现、容器及其相关生态的成熟(特别是容器编排工具及其对有状态服务的支持)、微服务的广泛应用，越来越多的相关工具将会集成在持续集成过程中，同时自动化持续测试也会变得更加流行，从而更有效地控制质量、保障安全、降低成本、控制风险、提升效率，更加高效的支持复杂的大型分布式应用。
容器优化与实践
过去几年间，以 Docker 为核心的容器技术在持续进化，以其构建、分发和部署的简易性成为 IT 基础架构中的关键技术。容器技术通过标准化运行环境的方式来连接了应用的研发、测试和运维。它简单、轻量，具备很强的可移植性，能更高效的利用资源，还能够有效的解决软件依赖问题，提高研发效率，降低研发成本，因此产业界也持续通过容器来优化其软件发布流程，容器化其遗留程序。
然而，容器技术本身也面临了不少挑战。未来，在容器标准化、容器安全、容器网络、容器存储特别是对数据库等有状态服务的支持等方面还存在很大的改进空间，容器的可管理性及易用性也需要进一步提升。
容器编排与管理
随着 Docker 等容器技术的广泛应用，容器编排和管理也受到了越来越多的关注，涌现出了诸于 Kubernetes、Apache Mesos、Docker Swarm Mode 等优秀的开源生态和解决方案。它们试图将目前以资源为中心的管理方式过渡到以应用为中心的管理方式，并且试图对应用的基础构成组件(例如配置、服务、负载均衡等)进行标准化，从而获得更好的可管理性。随着 CaaS 的发展，私有或公有的容器云也越来越多，越来越成熟，用户体验越来越好，从而显著降低迁移成本。
然而，在大规模的实践中，在灰度发布、资源调度、隔离性、运维监控、日志等方面仍有待进一步成熟和标准化，在跨数据中心的应用管理，混和云环境支持，跨云服务迁移，安全性等方面仍然面临着困难和挑战。
自动化运维
随着虚拟化和容器化等技术的出现，运维管理的复杂度和难度大大增加，因此必须通过专业化、标准化和流程化的手段来实现运维的自动化。业界出现了很多提升效率的自动化工具，例如 Puppet、Chef、Ansible、Saltstack 等。各大主流互联网公司也逐步从工具自动化往一站式自动化运维管理平台的方向进行演化，从而使得能够对部署、配置、监控、告警等进行一站式处理，实现资源和流程的标准化统一化、应用运行状态可视化管理，提升运维质量，降低运维成本。
智能化运维
随着监控范围的不断扩大，其产生的数据具备多样性、多维性和非结构化等特点，并且可能同业务数据存在相关性，传统的手动分析处理方式效率低且成本高。随着大数据和人工智能的兴起，越来越多的智能分析算法也应用于运维领域，它们通过分析运维系统本身所拥有和产生的海量数据，在问题定位、流量预测、辅助决策、智能报警和自动故障恢复等方面发挥出较大的作用，从而进一步降低运维成本。
运维基础架构
运维基础架构涵盖网络、机器、机房、机架、存储等的管理，涉及基础资源、机架设计和交付、网络架构设计、数据架构规划、操作系统、系统软件、环境交付和机器报废替换等方向。产业界构建了 CMDB 以支持服务交付流程和相应的管理流程，也构建了相应的初始化、部署、运行、监控、日志等工具。随着虚拟化、容器化和云计算的发展，运维基础架构也从 提供资源往提供能力的方向进行转变，提高应用对基础架构的透明性，进而提高基础架构的灵活性 。
数据库运维
数据库运维涉及数据库部署架构、容量规划、性能调优、数据备份和恢复、数据迁移、数据库监控审计、数据库运维管理，故障排除等一系列服务。
随着互联网更加广泛的使用，数据库运维也呈现出新的形态。近年来，在异地多活等部署模式、在线表模式变更、海量数据迁移、故障排除时，都会通过一系列的工具，来尽可能的减少数据库整体的不可用时间，从而尽可能的降低对用户的影响。同时，为了简化数据库的部署和管理，以容器化的方式来对数据库进行管理和调度也逐步成为热点之一。最后，在智能化运维方面，通过对数据库各项指标的分析和挖掘，提供智能化的诊断方案，提前预知和管控风险，提升处理效率系统整体稳定性。
大数据运维
随着数据的快速增长，以 Hadoop 为基础的生态系统也扮演了越来越重要的角色，它涵盖离线计算、流式计算、即席查询等多种使用方式，也涌现了 Hadoop、Spark、Kafka、Hbase、Storm、Phoenix 等优秀开源项目。在大数据平台的运维中，由于涉及分布式架构、多源异构海量数据存储、数据的处理框架更为多样化和复杂化等问题，大数据的运维也变得异常复杂。
大数据运维的主要目标是提高资源利用率，降低了大数据系统的运维复杂度，提升用户友好性。其中，计算资源的统一管理和调度能力，以容器为基础的多种类型大数据系统混合部署能力，快速弹性扩缩容能力，跨数据中心容灾能力，大数据应用监控能力和快速灵活的故障定位能力也变得越来越重要。
运维监控
监控是 IT 系统运维中保障核心业务稳定可用的重要环节，它涵盖网络、主机、业务、应用、性能等方面，涉及快速的故障通知，精准的故障定位和性能分析诊断等。当前比较流行并且在业界广泛应用开源的监控软件包括 Nagios、Cacti、Zabbix、Ganglia 等。
随着应用规模的迅速扩大以及 DevOps、微服务、容器等技术的快速发展，监控也出现新的形态。产业界已经从 Nagios 风格的监控方式中演化为流式风格，通过海量监控指标的流式处理，同时通过可视化平台来实时的展示监控指标。另外，随着基础设施变得更加动态，监控不但关心单个节点的运行状态，更关心整个业务系统的健康状态，全链路追踪等技术也已经现并得到广泛应用。
运维安全
在互联网化和移动化的背景下，应用逐渐往云中迁移，传统的边界变得越来越模糊，安全也有了新的发展趋势。过去的安全技术是以防御为主，采用传统防火墙、入侵防御系统等。现在，除了对传统的安全措施进行加强之外，还会在开发流程中引入一些安全实践，包括威胁建模，自动安全扫描、安全功能性测试等，从而降低安全风险，缩短安全问题的反馈周期。同时，安全也从事先预防转向为持续检测和快速响应，通过对攻击行为的持续检测，对安全事件进行快速响应，从而大幅降低损失。
游戏开发与运维
近年来，网络游戏的增长非常迅速，游戏开发采用通用化框架和引擎的趋势越来越明显。在游戏运维方面，除了常规的运维手段，游戏还有其自身的特点。首先，端游、页游和手游由于形式的不同， 其在联网方式、分发渠道、生命周期长短等方面存在差异，因此给网络接入、多渠道分发、容量规划、网络延时、档案数据高可靠存取等方面的运维都带来了挑战。
其次，由于用户增长存在不可预知性，游戏运维必须具备快速的扩缩容能力，多采用混合云或者公有云的技术架构，从而最大程度的提升其水平可扩展性。最后，在受到大规模 DDOS 异常流量攻击时，游戏运维应当具备多级流量清洗保护机制，具备服务降级的能力，从而尽可能的保证可用性。
互联网金融与运维
近几年来，互联网金融出现了井喷式发展，Fintech 也为其注入了技术创新基因。微服务、容器化、大数据和云计算等技术为互联网金融的快速迭代提供了基础。然而，相对于目前的应用运维，互联网金融行业有其自身的特点，其在数据留存、安全合规、防攻击能力、支付清算、金融监管、数据安全、大数据风控和高等级安全防护等方面都有较强需求甚至强制性的金融监管规范，也对互联网金融的运维提出了更高的挑战。
上文源自：运维技术大盘点-你该关注运维的哪一面
后端开发基础知识
上面简单说了运维的技术，来盘点一下与其非常相关的后端开发的技能体系：大致可分为计算机网络、操作系统、数据库、开发的基本知识。在此重点介绍前三者。
网络七层模型分别是什么？
为了使得多种设备能通过网络相互通信，和为了解决各种不同设备在网络互联中的兼容性问题，国际标准化组织制定了开放式系统互联通信参考模型（Open System Interconnection Reference Model），也就是 OSI 网络模型，该模型主要有 7 层，分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。
应用层：应用层最接近终端用户。大多数应用程序都位于这一层。我们从后端服务器请求数据，无需了解数据传输的具体细节。这一层的协议包括 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 和端口是可变的，其理论值计算公式如下:
对 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解析流程？
域名解析的工作流程
客户端首先会发出一个 DNS 请求，问 www.freeoa.net 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
本地域名服务器收到客户端的请求后，如果缓存里的表格能找到 www.freeoa.net，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大， 能告诉我 www.freeoa.net 的 IP 地址吗？” 根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
根 DNS 收到来自本地 DNS 的请求后，发现后置是 .net，说：“www.freeoa.net 这个域名归 .net 区域管理”，我给你 .net 顶级域名服务器地址给你，你去问问它吧。”
本地 DNS 收到顶级域名服务器的地址后，发起请求问“你好，能告诉我 www.freeoa.net 的 IP 地址吗？”
顶级域名服务器说：“我给你负责 www.freeoa.net 区域的权威 DNS 服务器的地址，去问它应该能问到”。
本地 DNS 于是转向问权威 DNS 服务器：“你好，www.freeoa.net对应的IP是多少？” freeoa.net 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是这个域名我做主。
权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。
至此完成了 DNS 的解析过程。现在总结一下，整个过程画成了一个图。
网页非常慢转圈圈的时候，要定位问题需要从哪些角度？
最直接的办法就是抓包，排查的思路大概有：
先确定是服务端的问题，还是客户端的问题。先确认浏览器是否可以访问其他网站，如果不可以，说明客户端网络自身的问题，然后检查客户端网络配置（连接wifi正不正常，有没有插网线）；如果可以正常其他网页，说明客户端网络是可以正常上网的。
如果客户端网络没问题，就抓包确认 DNS 是否解析出了 IP 地址，如果没有解析出来，说明域名写错了，如果解析出了 IP 地址，抓包确认有没有和服务端建立三次握手，如果能成功建立三次握手，并且发出了 HTTP 请求，但是就是没有显示页面，可以查看服务端返回的响应码：
如果是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 长连接
长连接的特点是只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
HTTP长连接与WebSocket有什么区别？
全双工和半双工：TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。
应用场景区别：在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。
操作系统
进程跟线程的区别？
本质区别：进程是操作系统资源分配的基本单位，而线程是任务调度和执行的基本单位
在开销方面：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小
所处环境：在操作系统中能同时运行多个进程（程序）；而在同一个进程（程序）中有多个线程同时执行（通过CPU调度，在每个时间片中只有一个线程执行）
内存分配方面：系统在运行的时候会为每个进程分配不同的内存空间；而对线程而言，除了CPU外，系统不会为线程分配内存（线程所使用的资源来自其所属进程的资源），线程组之间只能共享资源
包含关系：没有线程的进程可以看做是单线程的，如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程
举个例子：进程=火车，线程=车厢
线程在进程下行进（单纯的车厢无法运行）
一个进程可以包含多个线程（一辆火车可以有多个车厢）
不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）
同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）
进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）
进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）
多线程是不是越多越好，太多会有什么问题？
多线程不一定越多越好，过多的线程可能会导致一些问题。
切换开销：线程的创建和切换会消耗系统资源，包括内存和CPU。如果创建太多线程，会占用大量的系统资源，导致系统负载过高，某个线程崩溃后，可能会导致进程崩溃。
死锁的问题：过多的线程可能会导致竞争条件和死锁。竞争条件指的是多个线程同时访问和修改共享资源，如果没有合适的同步机制，可能会导致数据不一致或错误的结果。而死锁则是指多个线程相互等待对方释放资源，导致程序无法继续执行。
进程调度算法有哪些？
1 先来先服务调度算法
最简单的一个调度算法，就是非抢占式的先来先服务（*First Come First Serve, FCFS*）算法了。
FCFS 调度算法
顾名思义，先来后到，每次从就绪队列选择最先进入队列的进程，然后一直运行，直到进程退出或被阻塞，才会继续从队列中选择第一个进程接着运行。
这似乎很公平，但是当一个长作业先运行了，那么后面的短作业等待的时间就会很长，不利于短作业。
FCFS 对长作业有利，适用于 CPU 繁忙型作业的系统，而不适用于 I/O 繁忙型作业的系统。
2 最短作业优先调度算法
最短作业优先（*Shortest Job First, SJF*）调度算法同样也是顾名思义，它会优先选择运行时间最短的进程来运行，这有助于提高系统的吞吐量。
SJF 调度算法
这显然对长作业不利，很容易造成一种极端现象。
比如，一个长作业在就绪队列等待运行，而这个就绪队列有非常多的短作业，那么就会使得长作业不断的往后推，周转时间变长，致使长作业长期不会被运行。
3 高响应比优先调度算法
前面的「先来先服务调度算法」和「最短作业优先调度算法」都没有很好的权衡短作业和长作业。
那么，高响应比优先 （*Highest Response Ratio Next, HRRN*）调度算法主要是权衡了短作业和长作业。
每次进行进程调度时，先计算「响应比优先级」，然后把「响应比优先级」最高的进程投入运行，「响应比优先级」的计算公式：
从上面的公式，可以发现：
如果两个进程的「等待时间」相同时，「要求的服务时间」越短，「响应比」就越高，这样短作业的进程容易被选中运行；
如果两个进程「要求的服务时间」相同时，「等待时间」越长，「响应比」就越高，这就兼顾到了长作业进程，因为进程的响应比可以随时间等待的增加而提高，当其等待时间足够长时，其响应比便可以升到很高，从而获得运行的机会；
4 时间片轮转调度算法
最古老、最简单、最公平且使用最广的算法就是时间片轮转（*Round Robin, RR*）调度算法。
RR 调度算法
每个进程被分配一个时间段，称为时间片（*Quantum*），即允许该进程在该时间段中运行。
如果时间片用完，进程还在运行，那么将会把此进程从 CPU 释放出来，并把 CPU 分配给另外一个进程；
如果该进程在时间片结束前阻塞或结束，则 CPU 立即进行切换；
另外，时间片的长度就是一个很关键的点：
如果时间片设得太短会导致过多的进程上下文切换，降低了 CPU 效率；
如果设得太长又可能引起对短作业进程的响应时间变长。
一般来说，时间片设为 20ms~50ms 通常是一个比较合理的折中值。
5 最高优先级调度算法
前面的「时间片轮转算法」做了个假设，即让所有的进程同等重要，也不偏袒谁，大家的运行时间都一样。
但是，对于多用户计算机系统就有不同的看法了，它们希望调度是有优先级的，即希望调度程序能从就绪队列中选择最高优先级的进程进行运行，这称为最高优先级（*Highest Priority First，HPF*）调度算法。
进程的优先级可以分为，静态优先级和动态优先级：
静态优先级：创建进程时候，就已经确定了优先级了，然后整个运行时间优先级都不会变化；
动态优先级：根据进程的动态变化调整优先级，比如如果进程运行时间增加，则降低其优先级，如果进程等待时间（就绪队列的等待时间）增加，则升高其优先级，也就是随着时间的推移增加等待进程的优先级。
该算法也有两种处理优先级高的方法，非抢占式和抢占式：
非抢占式：当就绪队列中出现优先级高的进程，运行完当前进程，再选择优先级高的进程。
抢占式：当就绪队列中出现优先级高的进程，当前进程挂起，调度优先级高的进程运行。
但是依然有缺点，可能会导致低优先级的进程永远不会运行。
6 多级反馈队列调度算法
多级反馈队列（*Multilevel Feedback Queue*）调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。
顾名思义：
「多级」表示有多个队列，每个队列优先级从高到低，同时优先级越高时间片越短。
「反馈」表示如果有新的进程加入优先级高的队列时，立刻停止当前正在运行的进程，转而去运行优先级高的队列；
多级反馈队列
来看看它是如何工作的：
设置了多个队列，赋予每个队列不同的优先级，每个队列优先级从高到低，同时优先级越高时间片越短；
新的进程会被放入到第一级队列的末尾，按先来先服务的原则排队等待被调度，如果在第一级队列规定的时间片没运行完成，则将其转入到第二级队列的末尾，以此类推，直至完成；
当较高优先级的队列为空，才调度较低优先级的队列中的进程运行。如果进程运行时，有新进程进入较高优先级的队列，则停止当前运行的进程并将其移入到原队列末尾，接着让较高优先级的进程运行；
可以发现，对于短作业可能可以在第一级队列很快被处理完。对于长作业，如果在第一级队列处理不完，可以移入下次队列等待被执行，虽然等待的时间变长了，但是运行时间也变更长了，所以该算法很好的兼顾了长短作业，同时有较好的响应时间。
数据库
MySQL和Redis的区别，应用场景？
MySQL 是关系型数据库，适用于需要保持数据一致性、进行复杂的数据分析和关联查询的场景。Redis是一种基于内存的数据存储系统，它主要用于缓存和高速数据访问。Redis适合处理高速读写和缓存需求，适用于需要快速响应和高并发的场景，例如实时计数器、会话缓存、消息队列、发布/订阅系统等。一般会用Redis 作为MySQL的缓存，主要是因为 Redis 具备「高性能」和「高并发」两种特性。
1、Redis 具备高性能
假如用户第一次访问 MySQL 中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据缓存在 Redis 中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了，操作 Redis 缓存就是直接操作内存，所以速度相当快。
如果 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的有序性，那么就需要频繁的重建索引，这个过程是会影响数据库性能的。