运维常见题-日常维护（一）

0x5c0f 收录于运维记事整理收集和运维记事运维常见题

2026-07-10 2026-07-20 约 5000 字预计阅读 24 分钟

Linux 内存中的 Buffer 与 Cache 有什么作用？

在Linux中内存管理中，Buffer(缓冲区)和 Cache(缓存)都是为了弥补CPU/内存的高速与磁盘I/O的低速之间的性能鸿沟，但他们的作用对象和关注点有所不同。
1. Cache (页面缓存 / Page Cache)
  - 作用对象：主要针对于文件系统(File System)的文件
  - 工作原理：当系统读取或写入磁盘上的文件时，内核会将文件的内容缓存在内存中。下次如果再有进程访问相同的文件数据，系统会直接从内存的Cache中读取，从而极大的提高了文件读写的命中率和速度
  - 关键点：他是"文件级别"的缓存
2. Buffer (块缓冲区 / Buffer Cache)
  - 作用对象：主要针对原始块设备(Raw Block Device) 的裸数据。
  - 工作原理：它处于更底层，绕过了文件系统，直接记录磁盘块(Block)的元数据(Metadata)和控制信息。例如，当系统需要读取或写入磁盘的超级快(Superblock)、目录结构、索引节点(Inode)或者直接对磁盘进行 dd 等块级别操作时，数据会被缓存在Buffer中。
  - 关键点：它是"块级别"的缓冲区，主要用于合并和优化底层的磁盘I/O写入操作。
现代 Linux 的融合
- 在现代 Linux内核(2.4版本以后)中，这两者在实现上已经融合了。Buffer实际上指向的是 Cache 中对应的页面。简单来说: 1. 当我们讨论读取文件的读写优化时，他表现为 Cache; 2. 当我们讨论对磁盘块/元数据的组织和等待刷盘时候，他表现为 Buffer
协助记忆
- Cache缓存是信件内容(文件本身，方便重复阅读)
- Buffer缓冲是"装信纸的箱子"(底层的块，凑满一箱在一起发货)
进阶思考
- 在 Linux 中，如果我们发现 free 内存很少，但是 buff/cache 很大，这时候系统算不算内存不足？我们需要手动去释放它吗?
  - 系统不算内存不足，通常也完全不需要手动去清理。linux 有自己的管理机制,我们更多需要关注的是 available 那一列
  - 如何释放?
    - 通过修改 /proc/sys/vm/drop_caches 来进行，修改前必须先执行 sync 来强制将内存中尚未写入磁盘的脏页（Dirty Pages）立即刷写到存储介质中, 否则可能会导致部分正在高速写入的数据丢失，或者引发文件系统损坏。
      1. echo 1 > /proc/sys/vm/drop_caches 仅释放页缓存（Page Cache）
      2. echo 2 > /proc/sys/vm/drop_caches: 仅释放可回收的对象（包括 inode 和 dentry）
      3. echo 3 > /proc/sys/vm/drop_caches: 同时释放页缓存和可回收对象(完整清理，相当于执行了 1 + 2)
    - 如果执行了 echo 3 > /proc/sys/vm/drop_caches buffer/cache 变化仍然不明显，这是为什么？
      1. 存在大量“脏页”（Dirty Pages）：内核只能释放已经同步到磁盘的“干净缓存”。如果系统当前有高并发的写入操作，或者磁盘 I/O 存在瓶颈，导致内存中积压了大量的“脏页”（尚未刷盘的数据），这些数据是绝对不会被释放的。 (可以通过 cat /proc/meminfo | grep -i dirty 查看脏页大小。)
      2. 进程正在占用/锁定文件（Active Cache）：如果某些文件正被进程打开并持续读取或写入（例如数据库、大型日志收集程序），或者进程使用了 mmap 系统调用将文件映射到了自己的内存空间，甚至使用了 mlock 锁定了内存，这部分缓存被标记为“活跃（Active）”，内核为了保证运行安全，不会释放它们。
      3. 共享内存（Shared Memory / tmpfs）的占用：在 Linux 的 free 命令中，共享内存（Shared Memory）和 tmpfs（内存文件系统）也是被计入 cache 列的。常见的诸如 Oracle/PostgreSQL 的共享内存段（Shared Buffers）、Docker 容器的部分运行数据，或者 /dev/shm 路径下存放的文件，这部分内存在底层本质上是匿名内存（Anonymous Memory），它们不是文件缓存，drop_caches 对它们完全无效。要释放它们，必须杀掉对应进程或删除 tmpfs 中的文件。(可执行 ipcs -m 查看共享内存，或查看 free -m 中的 shared 列是否很高。)

Linux 系统 CPU 持续飙高，如何排查？

首先，在终端执行 top/htop 查看一下几个特定指标状态,同时按P键位按CPU使用率进行排序，找出消耗CPU最高的那个程序
- us(User): 用户态, 如果这个指标过高，那么说明是应用程序(java/php/go/…)的代码在进行大量的计算
- sy(System): 内核态，如果这个指标过高，那么说明系统调用频繁，可能存在大量的磁盘I/O、网络I/O或者是锁竞争
- wa(I/O Wait)：等待 I/O, 如果是这个指标过高，那说明磁盘读写成了瓶颈，CPU 在空转等待。
定位到具体的PID后，使用 top -H -p <PID> ，获取到所有的线程ID, 找到 CPU 占用最高的线程ID(TID: 一般就是第一个，即PID)，如果是java等应用，线程ID通常为十六进制，需使用 printf "%x\n" <TID>将我们获取到的TID(十进制)转换为十六进制(假设转换后的结果为4e8)，然后使用 jstack <PID> | grep -A 20 0x4e8 就能直接精确捕获到该线程正在执行的具体代码行数（例如某段死循环、频繁的 GC 线程、或者序列化操作），如果是GO、C/C++等应用，可以使用 pstack <PID>
协助记忆
1. 找进程 (top 看整体)
2. 抠线程 (top -H 定线程)
3. 换进制 (printf 转十六)
4. 抓代码 (jstack / perf 显原形)
进阶思考 如果通过 top 发现系统 CPU 确实很高，但是按 P 排序后，却找不到任何一个明显占用高的进程，所有进程的 CPU 看起来都很低，这可能是什么原因导致的？该怎么排查？
- 此类问题通常是由短生命周期进程疯狂周期性死循环或系统被植入了隐蔽的挖矿木马导致的
  1. 使用 pidstat 抓取瞬时进程 (sysstat 工具集)
    - 执行 pidstat -u 1每秒滚动一次，有几率抓出具体的问题进程
  2. 暂时只了解过这种方式

Linux 服务器如何查看硬件信息？

查看CPU信息: cat /proc/cpuinfo、lscpu
查看内存信息：free -h（或 free -m）、dmidecode -t memory
查看磁盘及存储信息：
- df -h: 查看当前已挂载的文件系统磁盘空间使用率
- lsblk：以树状图形式列出所有磁盘（如 sda、nvme0n1）及其分区结构，能一眼看出磁盘的大小和类型
- fdisk -l、 smartctl -a /dev/sda(smartmontools)：查看全量硬件及健康状态
查看网卡与 PCIE 设备：
- ip a、ifconfig：网卡 IP、MAC 地址和状态。
- ethtool eth0：网卡硬件速率
- lspci：主板总线设备
一个低估了的神器: inxi， inxi 能够跨发行版整合所有硬件、驱动甚至系统组件信息，并以极具可读性的彩色排版输出。

简述 Iptables 四表五链及其作用？

iptables的核心结构可以概括为表(tables) > 链(chains) > 规则(rules), 他们共同决定了一个数据包在经过linux内核时候的去留和处理方式。
- 四表(Tables),他决定做什么：表的定义决定了对数据包进行什么类型的操作，按照优先级从高到底(排队处理顺序)
  1. RAW表：负责状态跟踪脱离，他可以让特定的数据包绕过连接跟踪机制(Connection Tracking)，通常用于高并发下不需要追踪状态的数据包，以节省CPU资源.
  2. mangle表：负责拆解与修改数据包。他可以修改数据包的头部信息，如 TTL、TOS，或者给数据包打上特定的标记，常用于策略路由或流量整形。
  3. NAT表: 负责网络地址转换(Network Address Translation)，用于修改数据包的源IP/端口(SNAT)或目标IP/端口(DNAT)。比如让内网服务器共享上网或进行端口映射。
  4. filter表：负责过滤与安全(防火墙默认表)，决定是否放行(INPUT)、拒绝(REJECT)、丢弃(DROP)数据包
- 五链(Chains),他决定在哪做：链的作用是定义在网络传输的那个阶段(时机)去执行这些表里的规则。这五个链对应了内核网络栈的五个关键检查点
  1. PREROUTING链：路由前。数据包刚到达网卡、尚未经过路由决策（不知道该发给本地还是转发）时触发。常用于 DNAT（目的地址转换）
  2. INPUT链：入站。通过路由决策后，发现数据包的目的地是本地系统，在进入用户空间应用之前触发。常用于本地防火墙入站策略。
  3. FORWARD链：转发。通过路由决策后，发现数据包目的地不是本地，而是需要通过本机转发到其他网络时触发。常用于把 Linux 当作路由器/网关。
  4. OUTPUT链：出站。由本地应用程序产生的、准备发往外部网络的数据包，在离开本地前触发。常用于限制本地向外的访问。
  5. POSTROUTING链：路由后。数据包在完成所有路由决策、即将从网卡发送出去的最后一刻触发。常用于 SNAT（源地址转换/源地址伪装）。
协助记忆
1. 四表功能（优先级）：Raw -> Mangle -> Nat -> Filter（谐音速记：热（R）面包（M）拿（N）来放（F））
2. 五链时机：进前（Pre）、入内（Input）、转发（Forward）、出本地（Output）、出网卡（Post）。
进阶思考 请用具体的 iptables 命令分别写出如何实现 SNAT（源地址转换）和 DNAT（目的地址转换）？并在什么场景下使用？
- SNAT（源地址转换）
  - 场景：公司内网有大量私网服务器（如 10.0.2.0/24），只有一台公网网关（外网 IP 172.15.31.10）。需要让内网服务器能够访问外网。
    - 核心命令（在 POSTROUTING 链）：iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -j SNAT --to-source 172.15.31.10
- DNAT（目的地址转换）：
  - 场景：公司的核心数据库在内网（10.0.2.10:3306），现在需要让公网上的出差员工通过访问公网网关的 3306 端口，直接连接到内网的数据库。
    - 核心命令（在 PREROUTING 链）： iptables -t nat -A PREROUTING -d 202.100.1.1 -p tcp --dport 3306 -j DNAT --to-destination 192.168.1.10:3306

简述 RAID0、RAID1、RAID5 和 RAID10 的区别与适用场景？

RAID 0(条带化/Stripping)
- 工作原理：将数据切分成块，均匀地、交错地写入到所有磁盘中。
- 磁盘利用率：100%（ $N$ 块盘，容量为 $N \times \text{单盘容量}$ ）。
- 优缺点：
  - 优点：读写性能在所有 RAID 中最高，因为多块盘可以并行读写。
  - 缺点：没有任何冗余能力。任何一块盘损坏，整个阵列的数据全部崩溃。
- 适用场景：对安全性零要求，但对读写速度要求极高的临时数据或缓存场景，如视频剪辑的临时渲染盘、分布式计算的临时缓存区（Swap / Scratch Space）。
- 最少磁盘数：1 块（通常 2 块及以上才能体现性能优势）。
RAID 1(镜像/Mirroring)
- 工作原理：将数据完全复制到所有磁盘中。
- 磁盘利用率：50%（ $N$ 块盘，容量为 $\frac{N}{2} \times \text{单盘容量}$ ）
- 优缺点：
  - 优点：安全性极高，只要有一块盘存活，数据就不会丢失。读取性能好（可以从两块盘并行读）。
  - 缺点：写入性能受限于最慢的那块盘，且磁盘利用率极低，成本高。
- 适用场景：对数据安全性要求极高、系统盘或者核心配置存储。例如操作系统的引导盘（OS Boot Disk）、金融系统的核心日志盘。
- 最少磁盘数：2 块。
RAID 5（分布式奇偶校验 / Distributed Parity）
- 工作原理：数据条带化存储，但每次写入时会计算出奇偶校验信息（Parity），并将校验数据轮流循环存储在每块磁盘上。
- 磁盘利用率： $\frac{N-1}{N}$ （ $N$ 块盘，牺牲一块盘的容量来存校验信息）
- 优缺点：
  - 优点：兼顾了性能、安全和成本。允许任意一块磁盘损坏而不丢失数据（通过其余盘和校验块计算恢复）。
  - 缺点：写入时需要重新计算校验码（写惩罚较大），写入性能一般。如果坏了一块盘，在更换新盘进行"数据重构（Rebuild）“时，剩余磁盘的 I/O 压力极大，此时极易再坏第二块盘导致整个阵列瘫痪。
- 适用场景：适合读多写少、对性价比要求高的大容量存储。例如企业内部的常规文件服务器、非核心业务的日志存储、代码仓库。
- 最少磁盘数：3 块。
RAID 10（先镜像再条带化 / RAID 1 + 0）
- 工作原理：它是 RAID 1 和 RAID 0 的组合拳。先每两块盘组成一个 RAID 1 镜像对保证安全，再将这些镜像对组合成一个 RAID 0 进行条带化提升性能。
- 磁盘利用率：50%。
- 优缺点：
  - 优点：继承了 RAID 0 的高读写性能和 RAID 1 的高安全性。在最理想的情况下，即使坏掉一半数量的磁盘（只要不是同一个 RAID 1 镜像对里的两块盘同时坏），阵列依然能正常运转。数据重构时只需在镜像对内对拷，速度极快，风险较低。
  - 缺点：成本昂贵，磁盘利用率低。
- 适用场景：高并发、高负载、对数据安全和性能都有极高要求的核心生产环境。例如大型核心关系型数据库（MySQL / Oracle / PostgreSQL）、虚拟化宿主机的底层存储。
- 最少磁盘数：4 块（通常 6 块及以上才能体现性能优势，必须是偶数）。
协助记忆：
- 快(RAID 0) -> 保(RAID 1) -> 省(RAID 5) -> 豪(RAID 10)
进阶思考：
- 如果线上一个核心数据库的 RAID 10 阵列（由 4 块盘组成）中，突然有一块硬盘报红灯损坏（Degraded 状态）。此时作为运维，你该如何处理？在处理过程中有哪些高风险点需要注意？
  - 第一步：立即确认数据备份；在对硬件进行任何物理操作之前，必须第一时间检查该数据库的自动化备份（如全备、增量日志/binlog）是否完整、可用。因为任何硬件更换都有引发二次故障的极端风险，必须有备份兜底
  - 第二步：通过工具定位故障盘物理位置；使用服务器厂商提供的命令行工具（如戴尔的 perccli、华为的 storcli 或 MegaRAID 的 MegaCli）查看阵列状态，确认损坏盘的 Slot（槽位号），并开启定位灯（Enclosure Beacon），防止在线拔错盘（运维大忌：拔错盘会导致阵列直接崩溃）。
  - 第三步：在线热插拔更换新盘（同型号、同容量）； RAID 10 支持热插拔。确认槽位后，拔出坏盘，插入准备好的同型号、同容量新盘。
  - 第四步：监控数据重构（Rebuild）状态与系统负载，新盘插入后，阵列会自动开始 Rebuild。此时需要：
    - 监控重构进度（使用 storcli /c0/eall/sall show rebuild）
    - 控制业务线上的 I/O 负载：数据重构会极大地消耗剩余那块镜像盘的 I/O 性能。如果此时线上依然有高并发的密集写入，可能会导致重构时间拉长，甚至让仅存的那块镜像盘过载损坏。因此，必要时应该在业务低峰期进行、或者限制重构的 I/O 速率（Throttling）。
- RAID 3 是什么？
  - RAID 3（专用校验盘 + 字节级条带化）：
    - 机制：它把数据分成很小的字节（Byte）级别，轮流写入各个数据盘。最核心的是，它固定使用一块专门的磁盘来存储所有的校验数据。
    - 缺点：由于每次写数据都要更新校验信息，那块专用的校验盘就会遭遇严重的 I/O 瓶颈（写热点），极易过载损坏。因此，RAID 3 在现代运维中几乎已经被淘汰。
- RAID 10 和 RAID 01 有什么区别？
  - RAID 10（先镜像，再条带化 - 推荐）：
    - 结构：假设有 4 块盘，两两一组。A1 和 A2 组成 RAID 1 镜像，B1 和 B2 组成另一个 RAID 1 镜像。然后这两个独立的镜像组再拼成一个 RAID 0。
    - 坏盘容错：如果 A1 坏了，只有 A1 所在的局部镜像受影响。此时只要 A2 不坏，整个阵列完好无损，依然拥有高性能。更换 A1 时，也只需要从 A2 单对单对拷，重构极快。
  - RAID 01（先条带化，再镜像 - 极少使用）：
    - 结构：A1 和 B1 拼成一个具有高性能的 RAID 0，A2 和 B2 拼成另一个 RAID 0。然后这两个庞大的 RAID 0 互为镜像。
    - 坏盘容错：如果 A1 坏了，导致它所在的左侧整个 RAID 0 直接瘫痪。此时系统只能完全依靠右侧的 RAID 0 顶着。更换 A1 新盘时，由于左侧阵列已经崩了，必须从右侧的 A2 和 B2 整组读取数据来重构左侧，这会导致剩余磁盘面临巨大的 I/O 压力，极易引发二次坏盘崩溃。
  - RAID 10 vs RAID 01：RAID 10 在安全性上完爆 RAID 01。在生产环境中，请永远选择 RAID 10，忘掉 RAID 01。

提示磁盘空间已满，该如何解决？

如果在生产环境中遇到提示磁盘空间已满（Disk Full），通常会分两个大方向去快速排查和定位：第一是空间真正被占满，第二是 Inode 节点耗尽。

应急止血，恢复可用性：磁盘写满可能导致服务崩溃甚至 SSH 登不上，先腾点空间让系统喘口气(建议可以在服务器初始化的时候，就创建一个几GB大小的文件，用于应急时候的清理)
1. 确认哪个挂载点满了: df -h
2. systemd 日志，清理一天前的内容，释放很快: journalctl --vacuum-time=1d
3. 清空日志内容但不删文件，进程句柄不受影响(truncate -s 0 /var/log/messages)。尽量别用 rm，否则进程还抓着旧 inode 空间不归还
4. 清理临时目录: rm -rf /tmp/* /var/tmp/*
精准定位元凶：
- df -i 查 Inode（经典坑：df -h 显示正常但写不进文件）
  - Inode 满了说明海量小文件撑爆了inode表。用 find /path -type f | wc -l 定位目录，然后 find /path -type f -delete 或 xargs rm -f 批量清理
  - lsof | grep '(deleted)' 查已删文件但进程还抓着句柄不放
  - lsof 用 (deleted) 标记未释放的句柄，找到对应 PID 后 systemctl restart <service> 或 kill 掉
  - du -h --max-depth=1 /var | sort -hr | head 10 逐级往下找大目录
  - find / -type f -size +1G 直接盘全盘的大文件
协助记忆
- 一止血（journalctl / truncate），二排雷（df -i / lsof / du），三根治（logrotate + 监控）
进阶思考
- truncate 了日志但空间没变化？
  - 进程没收到 SIGHUP，还在往旧 inode 写。kill -HUP <PID> 让进程重新 open 日志文件。logrotate 的 postrotate 脚本就是这个原理
- df 和 du 不一致？
  - 大概率有进程在写一个大文件并且中途被删了。lsof | grep ‘(deleted)’ 定位后重启服务

简述 DNS 解析过程？

DNS（Domain Name System）解析的核心是将人类可读的域名（如 www.example.com）转换为机器可读的 IP 地址（如93.184.216.34）。整个过程涉及多级缓存和多级递归查询，目的是尽量让解析结果在离用户最近的地方命中，减少逐级往上问的耗时
1. 本地缓存与 hosts 文件（系统级命中）：
  - 浏览器自身缓存 → 操作系统缓存（如 systemd-resolved / nscd）→ /etc/hosts 文件, /etc/nsswitch.conf 控制解析顺序（通常配置为 hosts: files dns，先查 hosts 再走 DNS）, 这一步如果命中就直接返回，不产生网络请求
2. 向本地 DNS 递归服务器发起查询
  - 检查 /etc/resolv.conf 里配置的 nameserver（通常是网关、运营商 DNS 或内网 DNS 如 8.8.8.8 / 114.114.114.114）; 如果本地 DNS 有缓存，直接返回；没有则往下走
3. 逐级递归查询（从根到叶子）
  - 根域名服务器（Root Server）：全世界共 13 组（a.root-servers.net ~ m.root-servers.net），返回顶级域（.com / .cn / .org 等）的 NS 地址
  - 顶级域名服务器（TLD Server）：返回该域名的权威 NS 地址，例如 example.com 的权威 NS 是 dns1.namecheap.com
  - 权威域名服务器（Authoritative Server）：这是域名的最终归宿，直接返回域名对应的记录（A / AAAA / CNAME / MX 等
4. DNS 记录类型（常见的几种）
  - A / AAAA：域名对 IPv4 / IPv6 地址
  - CNAME：别名指向（www → example.com）
  - MX：邮件交换记录
  - NS：域名服务器记录
  - TXT：文本记录（常用于域名验证 / SPF / DKIM）
常用排查命令
- dig +trace example.com：完整追踪递归路径
- nslookup example.com：基础查询
- host example.com：快速查 IP
协助记忆：
- 查通讯录（本地缓存/hosts）→ 问总机（递归 DNS）→ 总台指引区域（根）→ 区域指到门牌（TLD）→ 门牌给电话（权威）
进阶思考：
- dig 返回了结果但浏览器就是打不开，还可能是什么问题?
  - ：可能是 /etc/nsswitch.conf 里 hosts: dns files 顺序颠倒了，或者 systemd-resolved 的缓存污染了，resolvectl flush-caches 清一下
- DNS 解析异常缓慢，怎么定位瓶颈?
  - dig + trace 看每级响应时间，如果根或 TLD 响应慢是运营商递归 DNS 的问题；如果权威 NS 慢是对方的服务问题。也可以对比 dig @8.8.8.8 和 dig @114.114.114.114 看谁的递归
- 内网 DNS 解析公司内部域名怎么设计的？
  - 通常自建 DNS 服务器（如 dnsmasq / CoreDNS / Bind），配置内部域名转发到内网权威 NS，外部域名转发到上游运营商或 8.8.8.8。核心要点是内外分离，避免内网域名泄漏到公

简述 Linux 系统启动过程？

Linux 从按下电源到出现登录提示符，大体经过五个阶段：固件自检 → Boot Loader → 内核加载 → init 进程 → 服务启动
- 第一阶段：固件（BIOS / UEFI）
  - 通电后 CPU 执行固件代码，进行 POST（Power-On Self Test），检测 CPU、内存等基础硬件
  - 按配置的启动顺序检查设备（硬盘 / U盘 / 网络），找到包含 Boot Loader 的设备并执行
  - UEFI 比传统 BIOS 多了安全启动（Secure Boot）和 GPT 分区支持
- 第二阶段：Boot Loader（GRUB 2）
  - 读取 /boot/grub2/grub.cfg（或 /boot/efi/EFI/redhat/grub.cfg），显示系统选择菜单
  - 选中内核后，GRUB 把内核文件（vmlinuz）和 initramfs 加载到内存
  - 可以在此阶段编辑内核参数（如 single 进入单用户模式、rd.debug 调试 initramfs
- 第三阶段：内核初始化
  - 内核解压后执行，检测 CPU、内存、总线等硬件
  - 挂载 initramfs（临时根文件系统），加载磁盘控制器、文件系统等必要驱动
  - 挂载真正的根文件系统（/），执行 switch_root 切换到真实根
  - initramfs 通常在完成后会被回收，释放内
- 第四阶段：init 进程（systemd）
  - 内核找到 /sbin/init（软链接到 systemd）作为 PID 1
  - systemd 读取 /etc/systemd/system/default.target（通常指向 multi-user.target 或 graphical.target）
  - 按依赖关系并行启动各单元（Unit），如挂载分区、启动网络、启动 sshd
- 第五阶段：服务启动与登录
  - systemd 执行该 target 下的所有必要服务
  - 最后启动 getty（虚拟终端）或 display manager（图形界面），显示登录提示
常用排查命令：
- dmesg 或 journalctl -k：查看内核日志
- journalctl -b：查看本次启动的 systemd 日志
- systemd-analyze：查看总启动耗时
- systemd-analyze blame：按耗时排序各服务的启动时间
- systemctl list-dependencies multi-user.target：查看依赖
协助记忆： 固件通电自检 → GRUB 捞内核 → 内核解压跑驱动 → switch_root 交棒 → systemd 拉起全家桶
进阶思考：
- 系统启动卡住了，怎么定位是哪一步的问题(相关命令未测试)？
  - dmesg 看内核阶段有没有 panic 或挂载失败；
  - journalctl -b 看 systemd 阶段哪个 unit 超时；
  - GRUB 启动时按 e 编辑内核参数加 systemd.log_level=debug 或 rd.debug 输出更多信息, Ctrl+x 或 F10 启动
- Boot Loader 坏了进不了系统怎么修复(相关命令未测试)
  - 用安装 U 盘进入 Rescue 模式 chroot 后：
    - BIOS 环境：grub2-install /dev/sda（RHEL 系）或 grub-install /dev/sda（Debian 系）
    - UEFI 环境：grub2-install --target=x86_64-efi --efi-directory=/boot/efi
    - 重建配置：grub2-mkconfig -o /boot/grub2/grub.cfg（RHEL 系）或 update-grub（Debian 系）
- initramfs 损坏或缺失怎么办(相关命令未测试)？
  - Rescue 模式 chroot 后：
    - RHEL 系：dracut -f
    - Debian 系：update-initramfs -u

请说一下你经常用的 Linux 系统性能分析工具及用途？

Linux 性能分析通常按 USE 原则（Utilization / Saturation / Errors）; 去拆：CPU、内存、磁盘、网络，每个维度有对应的工具链，从宏观到微观逐级缩小范围。
- Top — 整体概览
  - 一上来先跑 top，看几个核心指标：us（用户态）、sy（内核态）、wa（IO 等待）、id（空闲）、st（被宿主机偷走的 CPU）
    - us（User）— 用户态：过高说明应用程序在做大量计算
      - 常见原因：Java 应用的业务逻辑死循环、频繁 GC、序列化/反序列化；数据库的全表扫描；Nginx/OpenResty 的 Lua 脚本运算过重
      - 排查方向：top -H 定位线程 → jstack / perf 抓堆
    - sy（System）— 内核态：过高说明系统调用频繁
      - 常见原因：大量的上下文切换（线程数过多）、磁盘/网络 IO 中断密集、锁竞争激烈
      - 排查方向：vmstat 1 看 cs（context switch）是否异常；pidstat -w 1 看具体进程的上下文切换次数
    - wa（I/O Wait）— 等待 IO：过高说明磁盘读写成了瓶颈
      - 常见原因：磁盘 IOPS 或带宽达到上限、RAID 卡缓存策略问题、文件系统层面的 lock contention
      - 排查方向：iostat -xz 1 看 %util / await / r/s+w/s 是否超标；iotop 确认是哪个进程在大量读写
    - hi（Hardware IRQ）— 硬中断：过高说明硬件设备在频繁打断 CPU
      - 常见原因：万兆网卡的中断风暴、NVMe 盘中断过多
      - 排查方向：cat /proc/interrupts 看哪个设备在刷中断数；调整中断亲和性（irqbalance 或 /proc/irq/*/smp_affinity）
    - si（Software IRQ）— 软中断：过高说明内核在排队处理软件中断
      - 常见原因：网络收发包量过大（特别是单队列网卡场景）、CPU 核心数较少时大量小包打进来
      - 排查方向：cat /proc/softirqs 看 NET_RX 是否异常；sar -n DEV 1 看 PPS（每秒包数）是否打到上限
    - st（Steal）— 被偷走的 CPU：虚拟机环境下宿主机在占用本应分配给你的时间片
      - 常见原因：宿主机超分严重、同宿主机的其他 VM 在大量抢资源
      - 排查方向：st 超过 10% 就需要跟虚拟化团队沟通调整资源分配
    - id（Idle）— 空闲：这个本身不是问题指标，但 id 为 0 且 CPU 都是 us/sy，说明系统在全力工作；id 为 0 但 wa 占了大头，说明 CPU在空等磁盘
  - 按 P 按 CPU 排序，按 M 按内存排序，快速锁定异常进程
  - top -H -p <PID> 看具体线程
- vmstat — 系统级快照
  - vmstat 1（每秒输出一次），重点看这四列：
    - r：正在运行的进程数（超过 CPU 核数说明 CPU 饱和）
    - b：不可中断睡眠的进程数（IO 阻塞）
    - si / so：swap 换入换出（大于 0 说明内存不足）
    - us / sy / wa / id：CPU 时间分布
- iostat — 磁盘 IO 分析
  - iostat -xz 1，重点关注：
    - %util：磁盘忙绿比例（警惕，但 NVMe 盘在高 IOPS 下即使 100% 也可能正常，要看 r/s + w/s）
    - r/s / w/s：每秒读写次数
    - await：IO 平均等待时间（超过磁盘标称值说明有排队）
    - svctm：服务时间（现代内核已不准确，仅供参考）
- sar — 历史回溯(需要在 /etc/default/sysstat 中开启 ENABLED="true")
  - /var/log/sa/saXX 记录了系统历史的 CPU / 内存 / 网络 / 磁盘数据
  - sar -u -f /var/log/sa/sa11 看 11 号那天的 CPU 走势
  - 线上排查时最常用的命令之一，出问题时先看 sar 回放确认时间点
- ss — 网络连接
  - ss -tuln：查看所有监听端口
  - ss -s：连接数统计（TIME_WAIT / ESTAB 数量）
  - ss -t -a 或 ss -o state time-wait：精确过滤特定状态的连接
- perf / strace — 深挖到底
  - perf top：直接看 CPU 在跑哪些内核函数或用户态函数，跳过 PID 的干扰
  - strace -cp <PID>：统计该进程的系统调用耗时分布
  - 这两步通常是前几项定位不到根因时才上
协助记忆：
- top 挂号看整体，vmstat 量血压（CPU/内存快速读数）
- iostat 拍 X 光（磁盘在忙什么），sar 翻病历（回看历史指标）
- ss 听心跳（网络连接状态），perf/strace 上 CT 扫描（深挖到底
进阶思考：
- iostat 里的 %util 达到 100% 一定说明磁盘有问题吗？
  - 不一定。%util 统计的是磁盘设备在采样周期内有多长时间在处理请求。对于机械盘，100% 通常意味着饱和；对于 NVMe 固态盘，因为它支持多队列并发，100% 的 util 下可能还有大量余量，要结合 r/s + w/s（是否达到盘标的 IOPS 上限）和 await（请求是否在排队）综合判断
- 什么情况下优先用 pidstat 而不是 top？
  - 遇到 CPU 飙高但 top 按 P 排序找不到高占用进程时（短生命周期进程频繁起停）。pidstat 1 每秒采样，能捕捉到瞬间出现又消失的进程。原理是 pidstat 在内核里抓 /proc 的统计快照，短进程死之前留下了足迹（这个之前在 CPU 隐蔽故障篇有覆盖）

简述 FTP 工作模式？

FTP（File Transfer Protocol） 基于 客户端-服务端 模型，使用两条 TCP 连接：一条控制连接（端口 21）传输指令，一条数据连接（动态端口）传输文件。它的工作模式核心区别在于数据连接由谁发起

主动模式（PORT / Active Mode）
- 客户端随机打开一个高位端口（假设 N）作为数据接收端，通过 PORT 命令告知服务端 IP 和 N
- 服务端从端口 20 主动连接客户端的 N 端口，建立数据通道
- 致命问题：客户端必须开放一个高位端口等待服务端连接。如果客户端在 NAT 网关或防火墙后面，外部无法主动连接到这个端口，连接会失败
- 极少用，现代 FTP 基本只在服务端防火墙限制严格时才被迫开启
被动模式（PASV / Passive Mode）
- 客户端发送 PASV 命令
- 服务端打开一个随机高位端口（假设 P），通过 PASV 响应告知客户端
- 客户端从自己的高位端口主动连接服务端的 P 端口，建立数据通道
- 优点：客户端只需要能发起出站连接即可，不要求公网 IP 或开放入站端口
- 现代 FTP 的默认模式

两种模式对比

特征	主动(PORT)	被动(PASV)
数据连接发起方	服务端 -> 客户端	客户端 -> 服务端
防火墙友好度	❌ 需客户端开放入站端口	✅ 仅需客户端出站
NAT 环境可用	❌ 基本不能	✅ 正常使用
服务端防火墙配置	只需开放 21 + 20 端口	需开放 21 + 一个高位端口池

相关协议区分（易混淆） ：
- FTPS（FTP over SSL/TLS）：标准 FTP + TLS 加密，仍用 PORT/PASV 模式，端口 990（隐式）或 21（显式 AUTH TLS）
- SFTP（SSH File Transfer Protocol）：基于 SSH 的文件传输协议，不是 FTP 的加密版，端口 22，完全不同的协议栈

常用服务端配置参考（vsftpd） ：

1
2
3
4
5
# 强制使用被动模式
pasv_enable=YES
pasv_min_port=30000
pasv_max_port=31000
pasv_address=<公网 IP>  # NAT 环境需指

协助记忆：
- 主动模式：你去找人拿快递，你告诉店家你在门口等，店家走出来递给你 → 需要你能接收
- 被动模式：你去找人拿快递，店家说"我在门口等你”，你出门去他那取 → 你主动去取就行
- 一句话：主动是服务端连客户端，被动是客户端连服务端数据端口
进阶思考：
- 为什么 FTP 不像 HTTP 只用一条连接？
  - FTP 设计于 1971 年，当时控制通道和数据通道分离的设计是为了在传输大文件时不受控制指令干扰，且能在传输中随时中断/续传。HTTP 是现代协议，一条连接同时承载控制（Header）和数据（Body），适用于短连接轻量传输。从协议设计哲学上就是两代产物
- 主动模式在什么场景下反而更适合？
  - 服务端防火墙极其严格、只允许开放 20 和 21端口，不允许开放高位端口池时。例如某些银行内部的文件传输，安全策略要求尽量少开放端口，就会让客户端自己去接收连接。但代价是客户端必须有公网 IP 且防火墙放行入站
- EPSV 和 EPRT 是什么？
  - 扩展被动/主动模式，用于 IPv6 环境。PASV 的响应格式中 IP 地址是点分十进制（IPv4），在 IPv6 下无法表示，EPSV改用更简洁的协议号表示（EPSV → 229 Entering Extended Passive Mode (|||port|)），不传输 IP 地址，兼容性更好

简述 ext4 日志文件系统原理？

ext4 是 ext3 的演进版本，继承了 ext3 的日志（Journal）机制，在此基础上引入了区段、延时分配、多块分配等核心改进

日志机制（Journaling）—— ext3 继承的核心, 日志的目的是保证文件系统在意外崩溃后能快速恢复一致性，不需要像 ext2 那样跑几小时的 fsck。原理是 先写日志、再落数据：
1. 事务开始（Begin）：内核准备修改元数据（如分配 inode、创建目录项），标记一个事务开始
2. 写日志（Journal Write）：将即将修改的元数据块提前写入日志区域（/proc/fs/ext4/dm-X/journal 或磁盘上的保留区域）
3. 提交（Commit）：所有日志条目写入完成后，写入提交记录，表示该事务已完成
4. 回放（Checkpoint）：将日志中的内容真正应用到文件系统对应位置，完成实际写操作
5. 崩溃重启后，内核检查日志——如果有未完成的提交则重放（replay），如果没有则直接跳过，不需要全盘 fsck

三种日志模式（man mount → data=journal / data=ordered / data=writeback，ordered 是默认模式）

模式	行为	安全性	性能
`journal`	元数据+文件数据都写日志	最高，断电能恢复全部数据	最慢
`ordered（默认）`	仅元数据写日志，数据先落盘	中等，日志保证元数据一致	中等
`writeback`	仅元数据写日志，数据可后写	最低，崩溃后文件内容可能全是零或垃圾	最快

ext4 相比 ext3 的核心改进
- 区段（Extents） ：传统 ext3 用块映射（block mapping），每个文件需要一个间接块树来记录占用了哪些数据块。大文件（如 4GB）的块映射非常庞大。ext4 改用区段树（extent tree），每个区段记录一段连续物理块的起始位置 + 长度，大幅减少元数据量
  - 类比：以前是一个格子一个格子记"我占了第 1000 块、第 1001 块、第 1002 块……"，现在是一句话"我占了第 1000 到 2000 块"
- 延时分配（Delayed Allocation）：应用程序发起 write() 时，ext4 不立即分配磁盘块，而是先在内存中攒着，等攒够了或真正要刷盘（flush）时再一次性分配连续的物理块
  - 好处：减少文件碎片（攒够了一个 extent 再分配）、提高写入合并效率
  - 风险：异常掉电时未分配的数据会丢失（写入承诺但还没入盘的内容）
- 多块分配器（mballoc） ：传统文件系统一次只分配一个块，ext4 优先一次性分配多个连续块，减少 CPU 开销和碎片
- Flex 块组：将多个块组的元数据（inode table、block bitmap）集中存放，减少磁盘寻道时间
- 校验和（Checksum） ：对日志和元数据增加校验，崩溃恢复阶段可以检测损坏
- 纳秒时间戳：inode 的时间戳精度从秒级提升到纳秒级，并增加了 crtime（文件创建时间）
常用排查命令
- tune2fs -l /dev/sda1 | grep -i 'Filesystem features'：查看该 ext4 分区开启了哪些特性
- dumpe2fs -h /dev/sda1：查看文件系统详细信息
- fsck.ext4 -fn /dev/sda1：不修复只检查，确认是否有日志不一致

协助记忆
- 日志机制：先记账（写日志）→ 再报账（落数据）→ 烂账了翻账本（崩溃重放）
- 三种模式：journal（全记账）→ ordered（记摘要，原文先发）→ writeback（只记摘要不动原文）
- ext4 的改进：区段省地（一块连续的只记一次）→ 延时攒批（减少碎片）→ 多块分配（少跑几趟）
进阶思考
- ordered 模式下断电，文件内容会不会出现脏数据？
  - 会。ordered 只保证元数据一致（文件系统不会损坏），但不保证应用层写入的数据 100% 完整。例如你正在用 Vi 写文档，断电后重新开机文件可能不是保存时的最终版本。要保证应用层数据完整性，需要上层做 fsync/fdatasync（数据库 redo log 就是这个原理）
- ext4 和 xfs 应该如何选？
  - 说结论——没有绝对优劣，关键看场景：
    - ext4：单文件系统容量不大（< 50TB）、文件数量不多、通用场景。RHEL 7+ 默认就是 xfs，但 ext4 依然广泛用于 Ubuntu 默认选和嵌入式场景
    - xfs：大容量（单文件系统支持到 EB 级）、海量文件并行读写（如文件服务器、大数据存储）。xfs 的分配组（AG）设计使它并发写入性能更好
    - 一句话：通用场景 ext4 足够，大容量高并发上 xfs
- ext4 的 Inline Data 是什么？
  - 极小的文件（默认 60 字节以内）直接存放在 inode 结构体内，不分配数据块。这对于保存大量小文件（如 Git 对象、邮件存储）能极大减少磁盘寻道和元数据开销。tune2fs -l 里看到 inline_data 特性就是开启了这个。

Linux 进程有哪几种状态？

Linux 内核将进程状态定义在 include/linux/sched.h 中，ps 和 top 里看到的字母对应内核中的宏定义。总共分为运行、睡眠（两种）、暂停、僵尸、退出五种大类
- R（TASK_RUNNING）— 运行态
  - 进程正在 CPU 上执行，或者已经准备好随时可以被调度器切换到 CPU 上运行
  - 单纯看到 R 不一定是坏事，也可能只是刚在排队
  - 如果 R 状态的进程数持续超过 CPU 核心数（可以通过 vmstat 的 r 列看），说明 CPU 饱和了
- S（TASK_INTERRUPTIBLE）— 可中断睡眠
  - 进程在等待某个条件满足（等待 IO 完成、等待锁、等待 socket 数据），但可以被信号唤醒
  - 这是最正常的睡眠状态，大部分服务进程（nginx worker、sshd 等）大部分时间处于此状态
  - 如果系统空闲时大量进程停在 S 上是正常的
- D（TASK_UNINTERRUPTIBLE）— 不可中断睡眠
  - 进程在内核态等待某个事件（通常是磁盘 IO），在此期间不响应任何信号，即使 kill -9 也杀不掉
  - 正常的 D 状态是瞬时的（磁盘 IO 完成就切回），但如果大量进程长期卡在 D 状态，说明磁盘 IO 或存储系统出了问题
  - 内核开发者也意识到了纯 D 状态的问题，后来引入了 TASK_KILLABLE（内核宏 SK），这是一种"可被杀死的 D 状态"——ext4 和 NFS 的一些 IO 路径已改用此模式
- T（TASK_STOPPED）— 暂停态
  - 进程收到 SIGSTOP / SIGTSTP / SIGTTIN / SIGTTOU 等停止信号后被挂起
  - 用 kill -CONT 发送 SIGCONT 可以让其恢复运行
  - 常见场景：Shell 中按 Ctrl+Z 将一个前台任务放到后台暂停
- t（TASK_TRACED）— 追踪态
  - 进程正在被 ptrace 系统调用跟踪，最常见的就是被 strace 或 gdb 附加的时候
  - 本质上也是暂停状态，但专门由调试器控制
- Z（EXIT_ZOMBIE）— 僵尸态
  - 子进程已退出，资源已释放，但父进程没有调用 wait() / waitpid() 来读取它的退出码，进程描述符还留在系统进程表中
  - 少量短暂的 Z 是正常的（子进程刚死，父进程还没反应过来），但如果大量 Z 持续存在，说明父进程有 Bug，没有正确回收子进程
  - ps aux | grep Z 可以查到，kill 杀不掉——因为它已经死了
  - 处理方式：僵尸进程的父进程如果是 init/systemd（PID 1），systemd 会自动回收；如果是其他进程，需要 kill 掉它的父进程，僵尸会被 init 继承并回收
- X（EXIT_DEAD）— 死亡态
  - 进程已完全退出，正在被内核做最后清理（释放 task_struct）。这个状态在 ps 中几乎看不到，因为它只持续一瞬间
协助记忆
- R：在跑或等着跑
- S：在等资源，响了就醒
- D：在等磁盘，打死也不醒
- T：被暂停了，Ctrl+Z 就它
- t：被调试器绑起来了
- Z：死了但爹还没收尸
- X：尸体正在火化，看不到了
进阶思考
- 有一个进程卡在 D 状态很久了，kill -9 也杀不掉，怎么办？
  - D 状态意味着进程在内核态等待 IO，不响应任何信号。首先确认是哪个存储设备出了问题——cat /proc/<PID>/status 看 Wchan（等待的内核函数）和 cat /proc/<PID>/stack 看内核调用栈。通常是 NFS 服务端挂了、磁盘硬件故障、或 iSCSI 链路断了。解决方法是先恢复存储链路，如果还不行，只能重启系统。在日常运维中如果遇到不可恢复的 D 状态进程较多且影响业务，可以考虑 sysrq 触发紧急重启：echo 1 > /proc/sys/kernel/sysrq && echo b > /proc/sysrq-trigger
- 大量僵尸进程怎么清理？
  - 先找到僵尸进程的父进程 ps -eo pid,ppid,stat,cmd | grep Z，确认父进程是谁。如果父进程还能正常运作，检查它是否没正确调用 waitpid()，这应是应用 Bug；如果父进程本身就是坏的，kill -9 <父PID> 杀掉父进程，僵尸被 systemd（PID 1）继承后自动回收。如果父进程已经是 PID 1（出现在容器场景中比较常见），那就比较棘手，可能需要重建容器或触发容器的重新初始化
- TASK_KILLABLE 是什么时候引入的？
  - TASK_KILLABLE（内核中定义为 TASK_UNINTERRUPTIBLE | TASK_WAKEKILL）在 Linux 2.6.25 左右引入，目的是解决部分 D 状态进程连 kill -9 都杀不掉的问题。应用此机制的包括 NFS 客户端的一些等待路径、ext4 的部分 IO 操作。它在不可中断睡眠的基础上增加了一个可被杀死的标记——内核在进入睡眠时如果把 TASK_WAKEKILL 标记加上，收到致命信号（SIGKILL）时就会被唤醒并退出。但这没有覆盖所有 D 状态场景，所以普通的磁盘驱动 IO 路径上还是纯 D
- ps aux 里看到的 Ss、S+、Sl 等不是单一字母，这些附加字母代表什么？
  - 大写字母（S / D / R / Z）是内核基础进程状态，附加小写字符描述额外属性：
    - s（session leader）：会话领导者，通常是登录 Shell（bash）或终端会话的第一个进程
    - +（foreground）：在前台进程组中，你正在当前终端跑的命令
    - l（multi-threaded）：多线程进程（Java、mysqld、Nginx worker）
    - <（high priority）：高优先级（负 nice 值），通常被 renice 提权
    - N（low priority）：低优先级（正 nice 值），如 nice -n 10 启动的后台任务
  - 组合示例：Ss = 可中断睡眠 + 会话领导者（bash 等命令），Sl = 可中断睡眠 + 多线程（Java 应用），R+ = 正在前台运行的命令

Linux 进程间有哪些通信方式？

Linux 下进程间通信（IPC）的方式很多，从最简单的信号传递到高效的共享内存，各自适用不同场景和性能需求
- 管道 / Pipe（|）
  - 内核维护的一块环形缓冲区，一个进程写另一端读，单向数据流
  - 无名管道：pipe() 系统调用创建，仅用于父子进程或有亲缘关系的进程
  - 命名管道 / FIFO：mkfifo 创建，有文件路径名，没有亲缘关系的进程也能通信，但依然单向
  - 内核保证写不超过 PIPE_BUF（通常 4096 字节）的原子性
- 信号 / Signal
  - 异步通知机制，进程收到信号后执行预置的处理函数（默认动作 / 自定义 / 忽略）
  - 发送端：kill() / raise() / sigqueue()
  - 接收端：signal() / sigaction() 注册处理函数
  - 传输信息量极少，只有信号编号 + siginfo_t 附带的一小段数据（PID、UID、错误码等），主要用于通知"发生了某事件"而不是传递业务数据
- 消息队列 / Message Queue
  - 内核维护的消息链表，每个消息有类型标识符，进程可以按类型读取
  - POSIX 版本：mq_open() / mq_send() / mq_receive()
  - SysV 版本：msgget() / msgsnd() / msgrcv()
  - 相比管道，消息队列支持按消息类型优先读取，多个读者时可以做到定向分发
  - 但所有消息都要经过内核拷贝，性能不如共享内存
- 共享内存 / Shared Memory
  - 最快的 IPC 方式——两个（或多个）进程将同一块物理内存映射到各自的虚拟地址空间，数据写入后对方立刻可见，不需要经过内核拷贝
  - POSIX 版本：shm_open() + mmap()（内存映射文件到共享内存）
  - SysV 版本：shmget() + shmat()（传统 System V 接口）
  - 共享内存本身没有同步机制，必须配合信号量或互斥锁使用，否则会出现竞态条件
  - ipcs -m 可以查看系统当前的共享内存段
- 信号量 / Semaphore
  - 不是传递数据的通道，而是同步原语，用于协调多个进程对共享资源的访问
  - POSIX 版本：sem_open() / sem_wait() / sem_post()（命名信号量，可用于不相关进程）
  - SysV 版本：semget() / semop()（集合式信号量，支持同时操作多个）
  - 典型用法：共享内存 + 信号量组合使用，信号量控制"能不能读/写"而共享内存承载数据
- 套接字 / Socket
  - 最通用、最灵活的 IPC 方式，不仅用于网络通信，也可用于同一台机器的进程间通信
  - Unix domain socket（AF_UNIX / AF_LOCAL）：不走网络协议栈，在内核内部直接拷贝数据，比 TCP loopback 快得多。有流式（SOCK_STREAM）和数据报（SOCK_DGRAM）两种
  - 典型应用：MySQL 的 /var/run/mysqld/mysqld.sock、Docker 的 /var/run/docker.sock
- 内存映射文件 / mmap
  - mmap() 将文件映射到进程的虚拟地址空间，多个进程映射同一个文件时共享物理内存页
  - 和共享内存类似，但以文件为后端（file-backed），数据会同步回磁盘，掉电不丢失
  - MAP_SHARED 标志使所有进程的修改互相可见，MAP_PRIVATE 则触发写时复制（COW）
协助记忆
- 管道: 两个人之间用一根管子传递纸条，单向
- 命名管道: 一个带名字的公用管子，大家都可以往里塞纸条，但也单向
- 信号: 你朝对面喊一声"食堂开饭了"（信息量很少，通知作用）
- 消息队列: 每个人的信箱里扔带标签的信，收件人按标签取信
- 共享内存: 一块公共白板，谁都能写谁都能读
- 信号量: 一个令牌，只有拿到令牌的人才能碰白板
- 套接字: 电话 / 对讲机，可以来回说话，最灵活
- mmap: 大家共用一本笔记本，写的内容会自动存进档案柜
进阶思考
- 共享内存既然是性能最好的，为什么不是所有场景都用它？
  - 共享内存的维护成本高。一是必须自己处理同步（信号量/锁），容易出竞态条件；二是共享内存在进程崩溃时如果不清理会一直残留在内核中（ipcs -m 可以看到残留段），需要手动 ipcrm 或进程注册清理钩子。对于不需要极致性能的场景，Unix domain socket 和消息队列在易用性上更好
- Unix domain socket 和 TCP loopback（127.0.0.1）哪个性能好？
  - Unix domain socket 性能更好。TCP loopback 即使是本地通信也要经过完整的 TCP 协议栈（三次握手、校验和、滑动窗口），而 Unix domain socket 在内核内部直接调用 socket 层的内存拷贝，不需要封装 IP 头、不需要计算校验和。对于高频的本地 IPC（如 Nginx 转发请求、Docker 客户端与 daemon 通信），差异很明显
- pipe 和 FIFO 的读写原子性有什么实际影响？
  - write() 写入不超过 PIPE_BUF（4096 字节）的数据是原子的——即多个写者同时写管道时，不会出现内容交错。但如果一次写入超过 4096 字节，内核可能分多次写入，与其他写者的内容混在一起。因此管道常用于"一个写一个读"的模式，多个写者同时写入就需要考虑互斥或使用消息队列

Linux 服务器如何调优？

Linux 调优不存在一套放之四海皆准的参数，它一定是先明确瓶颈在哪，再针对性地调整对应子系统。按照 CPU → 内存 → 存储 → 网络 → 内核参数的顺序逐层排查和调整。
- CPU 层面
  - 进程/线程数与 CPU 核数的关系：CPU 密集型的应用，线程数通常设为 CPU核数 + 1 即可；IO 密集型的可以适当增加，但过多的上下文切换反而会降低吞吐。通过 vmstat 1 看 cs（context switch）列，如果每秒几十万次以上且 sy 偏高，说明线程数太多了
  - CPU 调度策略：服务器环境使用 performance 调速器，避免 powersave 导致频率频繁跳变。cpupower frequency-set -g performance 可临时设置，持久化需配置 /etc/default/cpupower 或 tuned (cpupower 属于 kernel-tools, RHEL 和 Ubuntu 均可用)
  - 中断亲和性：在多核系统上，将网卡、NVMe 的中断绑定到指定 CPU 核心，避免所有中断都打到 CPU 0 上。cat /proc/interrupts 看中断分布，/proc/irq/<IRQ>/smp_affinity 设置亲和性
- 内存层面
  - swappiness：控制内核使用交换的积极程度，范围 0 ~ 100，默认 60。数据库服务器通常设 1 ~ 10，普通服务保持默认即可。sysctl vm.swappiness=10(内存使用率 达到 100-vm.swappiness 时,开始使用交换分区; 但不是设为 0，内核 3.x 之后 vm.swappiness=0 意味着仅在内存绝对不足时才 swap，RHEL 8+ 又调整了行为——0 表示不主动 swap，OOM 优先级更高)
  - 透明大页 / THP：内核自动将连续的 4KB 内存页合并成 2MB 大页，目的是减少 TLB miss。但对数据库类应用（MongoDB、Cassandra 等），THP 的自动合并和拆分会触发内存 compaction，导致不可预测的短暂停顿。MongoDB 官方文档明确建议关闭。临时关闭：echo never > /sys/kernel/mm/transparent_hugepage/enabled；持久化可选两种方式之一：在 /etc/rc.d/rc.local 加入上行命令，或在 /etc/default/grub 的 GRUB_CMDLINE_LINUX 追加 transparent_hugepage=never 然后 grub2-mkconfig -o /boot/grub2/grub.cfg。注意 tuned 的某些 profile 会自动重开 THP，关闭后需 cat /sys/kernel/mm/transparent_hugepage/enabled 确认状态
  - OOM 策略：/proc/<PID>/oom_adj 或 oom_score_adj 调整进程被 OOM Killer 选中的权重。核心数据库可以设为 -1000（永远不被杀）
- 存储层面
  - I/O 调度器：机械盘用 kyber 或 mq-deadline，NVMe 固态盘建议用 none（不调度，直接走 blk-mq 的直通路径）。cat /sys/block/sda/queue/scheduler 查看当前调度器，echo none > /sys/block/nvme0n1/queue/scheduler 修改 -挂载参数：noatime 或 relatime 避免每次读文件都更新 access time（默认 relatime 已开启，但显式加上 noatime 可以减少一次元数据写入）。大文件场景加 nobarrier（但需要文件系统本身能保证一致性）
  - 预读大小：blockdev --setra 4096 /dev/sda 调整磁盘预读值。顺序读为主的场景增大预读能提升吞吐
  - deadline 与瓶颈：iostat -xz 1 看 await 如果持续超过磁盘标称 IO 延时（机械盘通常 5 ~ 15ms，NVMe 通常 < 1ms），说明有排队或磁盘达到上限
- 网络层面
  - TCP 连接优化
    - net.core.somaxconn：监听队列长度，高并发 Web 服务建议从 128 加大到 65535
    - net.ipv4.tcp_tw_reuse：允许将 TIME_WAIT 状态的连接用于新的出站连接，配合 tcp_timestamps 使用
    - net.ipv4.tcp_fin_timeout：FIN_WAIT2 的超时时间，默认 60 秒，可适当降低
    - net.core.rmem_max / wmem_max：增大 socket 缓冲区上限，配合 tcp_rmem / tcp_wmem 调大初始/最小/最大窗口
  - 连接追踪 / conntrack：net.netfilter.nf_conntrack_max 默认 65536，在高并发场景下容易打满导致丢包。可以加大到 1048576 或更高，同时相应调整 net.netfilter.nf_conntrack_buckets
  - 全连接队列溢出：ss -lnt 看 Send-Q（实际 backlog）和 Recv-Q（排队情况），如果 Recv-Q 持续不为 0 说明有连接堆积。netstat -s | grep overflowed 看是否有溢出计数
- 内核参数整体应用
  - 新增 /etc/sysctl.d/99-tuning.conf 文件，避免直接编辑 /etc/sysctl.conf， sysctl --system 重新加载。典型的一组生产环境参数示例： ```ini # CPU kernel.sched_migration_cost_ns = 5000000 kernel.sched_autogroup_enabled = 0
```
  # 内存
  vm.swappiness = 10
  vm.vfs_cache_pressure = 50

  # 网络
  net.core.somaxconn = 65535
  net.ipv4.tcp_tw_reuse = 1
  net.ipv4.tcp_fin_timeout = 15
  net.core.rmem_max = 16777216
  net.core.wmem_max = 16777216
  net.ipv4.tcp_rmem = 4096 87380 16777216
  net.ipv4.tcp_wmem = 4096 65536 16777216
  net.nf_conntrack_max = 1048576

  # 文件句柄
  fs.file-max = 2097152
  ```
```
协助记忆
- 调优思路：先找瓶颈再调参，不是上来就改 sysctl
- 五层记忆：CPU 绑核别打架 → 内存别急着 swap → 硬盘选对调度器 → 网络队列别溢出 → 参数统一一个文件
进阶思考
- RHEL 8+ 默认已经用 tuned 了，还需要手动调这些参数吗？
  - tuned 提供了预设配置集（如 throughput-performance / latency-performance 等），覆盖了大多数常见场景。如果 tuned 的配置集能满足业务需求，优先使用 tuned，不需要手动改 sysctl。tuned-adm list 查看可用集，tuned-adm profile latency- performance 切换。但如果业务负载非常特殊（如极低延迟交易系统、高密度虚拟化），仍然需要 tuned 之上再覆盖自定义参数
- net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 有什么区别？为什么都推荐 reuse 而不推荐 recycle？
  - tcp_tw_reuse 用于出站连接（客户端角色），在内核分配新连接时允许重用 TIME_WAIT 状态的连接。tcp_tw_recycle 用于入站连接（服务端角色），会快过期 TIME_WAIT。但 tcp_tw_recycle 开启了 PAWS（Protection Against Wrapped Sequences）机制，会丢弃那些时间戳比上一个连接还旧的包，导致 NAT 后面的客户端频繁出现连接失败（时间戳不同步）。Linux 4.12 内核已经彻底移除了 tcp_tw_recycle，所以不管你设不设它都没用了

简述 Keepalived 工作原理？

Keepalived 是一个基于 VRRP（虚拟路由冗余协议）实现的高可用集群软件，核心作用是实现服务器故障自动切换和虚拟 IP（VIP）漂移。
- 核心机制：VRRP 多播心跳
  - 一组服务器共享一个 VIP 对外提供服务，任何时候只有 Master 持有 VIP 并响应请求，其余 Backup 处于待命状态
  - Master 每隔 1 秒向多播地址 224.0.0.18 发送 VRRP 通告报文，告知 Backup 自己还活着
  - Backup 收到通告后保持等待状态。如果连续 3 个通告间隔（即约 3 秒）没收到 Master 的通告，Backup 认为 Master 已宕机，开始竞选新 Master
  - 竞选依据优先级（priority），范围 1 ~ 254，数值越大越优先，默认 100。胜出的 Backup 将 MAC 地址绑定到 VIP，发送免费 ARP（gratuitous ARP）刷新交换机 ARP 表，之后发给 VIP 的流量走新 Master
- 双进程架构
  - vrrp 子进程：负责 VRRP 协议交互、VIP 浮动和主备切换
  - checkers 子进程：负责对后端真实服务（如 LVS 后端的 Web Server）做健康检查，如检测到后端大面积故障也可触发 VRRP 降级
- 两种工作模式
  - 抢占模式（preempt）：默认模式。当优先级更高的 Backup 恢复上线后立刻抢夺 VIP，原 Master 降级为 Backup。适用于"主服务器永远优先"的场景
  - 非抢占模式（nopreempt）：已切换的 Master 即使优先级更低也不会被抢回，除非它自己再宕机。避免频繁切换导致的抖动
- track_script — 让 Keepalived 不再"盲"
  - Keepalived 本身不负责检测你的业务进程是否正常，它只检测 VRRP 心跳是否可达。如果 Master 上的 nginx 已经挂掉但 Keepalived 进程还在跑，它照样会发心跳宣告自己是 Master，VIP 不会漂， track_script 解决的就是这个问题：配置自定义检测脚本（如检查 nginx 进程是否存活、某个关键端口是否可通），如果脚本执行失败，通过 weight参数自动降低节点优先级，使 VIP 漂移到其他健康节点
  - 线上基本原则：track_script 必须配，否则你跑的就是盲的高可用
协助记忆
- Keepalived 是基于 VRRP 的高可用软件，一组服务器共享一个 VIP，任何时候只有 Master 持有它；Master 挂了，Backup 顶上，VIP 漂移过去
- 比喻：谁分高谁当擂主（Master），擂主每秒敲锣报平安，三声锣响没听到就换人
- 核心提醒：配置 track_script，否则服务挂了 Keepalived 还在那死发心跳，VIP 根本不会飘
进阶思考
- Keepalived 出现脑裂（Split-brain）是什么原因？
  - 两台节点同时认定自己是 Master，都绑了 VIP，导致流量混乱。最常见的原因是 VRRP 多播被防火墙拦截（IP 协议号 112，目标地址 224.0.0.18）、交换机 IGMP Snooping 配错、或两台节点的 router_id 重复导致互相认为对方是另一个集群的成员。排查方向：检查 iptables 是否放行多播、交换机端口配置、两台节点的 keepalived.conf 中 router_id 是否唯一
  - 注意：脑裂和 track_script 未配置是两回事——脑裂是两个节点都在抢，track_script 没配是唯一 Master 上的业务已死但无人知道。
- VIP 已经漂移到备机了但客户端还是连不上，可能是什么原因？
  - 备机发出 gratuitous ARP 后交换机/上游路由器的 ARP 表没有及时刷新（特别是静态 ARP 配置的场景）。备机上可手动 arping -I eth0 -c 3 -U <VIP> 强制刷新。另一个可能是备机的 iptables 规则没有放行访问 VIP 的流量，切换后数据包到了备机上却被防火墙拦截
- Keepalived 和 Heartbeat / Pacemaker 有什么本质区别？
  - Keepalived 只做 VIP 漂移，适合"主备两台机器，谁活着谁来接流量"的简单场景。Heartbeat / Pacemaker 是完整的集群资源管理器，能控制多资源的启停顺序、依赖关系、隔离失效节点（fencing），适用于复杂的多节点、多服务高可用场

LVM 解决了什么问题？有什么特点？

LVM（Logical Volume Manager）解决的是传统分区方案在磁盘管理上的刚性约束问题。传统分区方案中，分区创建后大小固定，一旦空间不足只能通过重新分区或挂载新盘来解决，过程涉及备份、卸载、分区、恢复等复杂操作，生产环境很难在不停机的情况下完成
- 解决了三个核心问题
  - 分区无法在线扩容：传统 /dev/sda1 分区创建后大小固定，如果 /home 分区满了但 /data 还有很多空间，在传统分区方案下只能备份后重建分区，无法直接从另一个分区"借"空间过来。LVM 允许将多个磁盘空间的空闲部分纳入一个池子统一管理，灵活分配给各个逻辑卷
  - 分区受限于单个磁盘：传统分区方案中一个分区不能跨越多块物理磁盘。LVM 可以将多个物理磁盘的空间加入到一个卷组（VG）中，逻辑卷（LV）的大小可以超过任何一块单盘，实现了跨磁盘的存储聚合。例如两个 1TB 的盘组成卷组后，你可以创建一个 1.5TB 的逻辑卷
- 分区管理不够灵活：LVM 支持在系统运行时在线扩展或缩小逻辑卷（文件系统层面也需要配合），支持基于快照在秒级创建卷的"快照"用于备份恢复或测试环境复制
- 核心概念：PV → VG → LV 三层架构
  - PV（Physical Volume，物理卷） ：将物理磁盘或分区初始化为 LVM 可管理的底层单元，LVM 会在 PV 的头部写入元数据（设备标签 + 元数据区域）。pvcreate /dev/sdb 可将一块整盘初始化为 PV
  - VG（Volume Group，卷组） ：由一个或多个 PV 组成的存储资源池。你可以把 VG 理解成一个"存储仓库"，所有加入 VG 的 PV 空间都汇入这个池子统一管理。vgcreate vg_data /dev/sdb /dev/sdc
  - LV（Logical Volume，逻辑卷） ：从 VG 中划分出的逻辑存储单元，格式化后挂载使用，功能上等价于传统分区。lvcreate -n lv_home -L 500G vg_data
  - 架构关系：物理磁盘 → PV → 加入 VG → 从 VG 切出 LV → 格式化 → 挂载
- 核心特性与常用操作
  - 在线扩展 LV（最常用的功能） ：
    - 卷组中还有空闲空间的 LV：lvextend -L +100G /dev/vg_data/lv_home，然后 resize2fs /dev/vg_data/lv_home（ext4）或 xfs_growfs /mount_point（xfs）
    - 卷组空间不足时：先加新盘 pvcreate /dev/sdd → vgextend vg_data /dev/sdd → 再扩展 LV
  - 跨盘条带化：类似 RAID 0，可以让你写入一个 LV 的数据条带化到多块物理盘上以提升性能。lvcreate -i 2 -I 64 -n lv_stripe -L 500G vg_data（-i 2 表示条带分布在 2 块 PV 上）
  - 快照（Snapshot） ：在秒级创建某个 LV 在某一时刻的静态只读副本，通常用于数据库备份时的"冻结点"创建。lvcreate -s -n lv_db_snap -L 20G /dev/vg_data/lv_db。注意快照不是全量复制，它基于 COW（Copy-on-Write）机制——只记录原始卷中被修改的块，所以快照空间耗尽后快照会失效
  - 查看 LVM 状态：pvdisplay、vgdisplay、lvdisplay 分别查看各层详情，pvs、vgs、lvs 是简洁版
协助记忆
- 传统分区像独立的小仓库，满了一个仓库里的东西搬不出来，建新仓库还要从头砌
- LVM 像一个大的公共仓库（VG），不同区域用隔板划分（LV），隔板可以随时往两边挪（在线扩展/收缩），不够用了再在旁边加个连体仓库（加新 PV 到 VG）
- 三层关系：盘就是砖（PV）→ 堆成堆的砖（VG）→ 从堆里划出一块给你砌墙（LV）
进阶思考
- LVM 和 RAID 是什么关系？能一起用吗？
  - LVM 是逻辑卷管理层，RAID 是物理冗余层，两者解决的问题维度不同，完全可以组合使用。经典的生产架构是：硬件 RAID（多块盘组成 RAID 10 阵列）→ 将整个 RAID 设备识别为一个磁盘 → 在这个磁盘上创建 PV → 划 VG → 切 LV。这样既有 RAID 的冗余和性能，又有 LVM 的灵活扩展能力
- LVM 快照能做 MySQL 的在线备份吗？
  - 可以，但前提是要先让 MySQL 进入一致状态（FLUSH TABLES WITH READ LOCK + 记录 Binlog 位置），然后创建快照，最后释放锁。快照备份的优势是飞快（秒级完成冻结），对业务窗口影响小。但快照属于 Crash Recovery 级别的一致性，回滚后 MySQL 需要进行 InnoDB 崩溃恢复。另外快照空间要预留够，否则写爆快照后整个快照直接失效
- 某个 PV 物理损坏了，LVM 能恢复吗？
  - 这取决于你的配置。如果该 PV 是 VG 中唯一的物理卷，数据全部丢失。如果 VG 中还有其他 PV 且使用了镜像（mirror）或 RAID（LVM 也支持内置 RAID 1/5/6），可以通过 vgreduce –removemissing 移除损坏的 PV 继续工作。否则只有从备份恢复。LVM 本身不提供冗余保护，冗余需要靠上层（RAID）或 LVM 本身的内置 RAID 功能来实

有 500 台服务器，你该如何管理？

500 台服务器靠手工管理已经不现实了。核心思路是标准化 + 自动化 + 集中化，让日常运维从"逐台操作"变成"批量编排"。
- 标准化是一切的基础
  - OS 标准化：统一操作系统版本和发行版，同时规划好磁盘分区标准、文件系统类型、主机命名规范、时区/NTP/DNS 等基础配置。没有标准化就没有自动化的前提
  - 部署标准化：使用 Cobbler 或 PXE + Kickstart 实现自动化安装，新机器上架后网卡启动即可自动完成系统安装和初始化配置，不需要运维人员逐台手动装系统
  - 镜像标准化：结合 HashiCorp Packer 构建基础镜像，在虚拟化或私有云环境中作为模板直接克隆部署，从系统安装阶段就开始规范化
- 配置管理工具批量管理
  - 基础维护工具: 选择 Ansible（无 Agent，通过 SSH 执行）、SaltStack 或 Puppet 等配置管理工具，后续所有系统层面的操作都通过它来下发，禁止逐台 SSH 改配置
  - 配置即代码：所有系统配置（repo、sysctl、防火墙规则、NTP、用户管理）放在版本控制中管理。改配置先在模板测试，然后批量推送到全量服务器。既保证一致性又能追溯变更
  - 基线管理：定义一个"安全基线"的 Role，包含基础优化参数、安全加固规则、时间同步等，新服务器上线时执行一次，后续定期巡检
- 集中监控与告警
  - Prometheus + Grafana 或 Zabbix 作为监控系统核心：
    - 基础监控：CPU、内存、磁盘 IO、网络流量
    - 中间件监控：Nginx、MySQL、Redis、RabbitMQ 等
    - 业务指标：QPS、延迟、错误率 — 监控平台的告警级别区分 P0（P0 电话通知/P1 即时通讯/P2 工单），避免告警疲劳导致关键告警被淹没
  - 500 台的规模可以考虑一个日志集中收集平台，用于后续故障排查和安全审计。
- 批量命令执行与文件分发
  - pssh / pdsh：pssh -h server.list -P ‘uptime’ 批量执行命令；pscp 批量分发文件，在日常巡检和紧急操作时可以快速响应，不需要依赖配置管理工具的 agent 通道
  - 如果将配置管理工具作为日常变更的唯一入口，批量命令执行更多用于紧急启动或临时查询。
- 资产管理与 CMDB
  - 500 台的资产信息再靠 Excel 根本管不住。搭建 CMDB 统一纳管服务器基本信息和状态，需要包含 IP、机房、机柜位置、硬件配置、OS 版本等
  - 自动发现：CMDB 定期从监控系统和云 API 同步数据，自动更新服务器状态（如上线/下线/故障），减少人工录入的出错
- 日常操作规范化
  - 变更流程：所有操作先在测试环境执行，验证通过后再分批推送到生产（灰度策略：先小批次验证，逐步扩大到全量）
  - 操作审计：关键操作记录操作人、操作内容、操作时间，后续出问题时可追溯历史
协助记忆
- 500 台的管理公式：标准化（从源头管） + 自动化（不让手碰） + 集中化（站高处看）
- 核心思路：配置走工具（Ansible/Puppet），监控走平台（Prometheus），日常走流程，禁止逐台 SSH
- 一句话总结：单机能修是本事，500 台能管是体系
进阶思考
- 500 台的规模下，有没有必要上 Kubernetes？
  - 500 台只有裸机的话其实没必要。Kubernetes 解决的是容器编排和微服务治理的问题，不是服务器管理的问题。500 台服务器的规模，重点应该是管好 OS/中间件和应用的生命周期，而不是为了上容器而上容器。等到应用层有强烈的弹性伸缩、微服务治理需求时再考虑引入 K8s
- 如果一个业务紧急要上线，需要改所有 Nginx 配置，最快的路径是什么？
  - 如果 Ansible 的 Playbook 已经写好了，直接在 Ansible 控制端执行 ansible nginx_group -m copy -a "src=./new_nginx.conf dest=/etc/nginx/nginx.conf" 并 ansible nginx_group -m shell -a "nginx -s reload"，整个过程不需要逐台上线操作。关键点在于集群所属的组定义需要准确分层，避免把测试和生产混在一起
- 500 台的规模下，时间同步（NTP）没有配置好会有什么影响？
  - 时间不同步会逐步引发灾难——日志时间错乱会导致故障排查非常困难，监控系统出现假告警，数据库主从复制的判断机制会出现误判，认证票据（Kerberos）验不过，HTTPS 证书时间校验失败等。标准操作是把 NTP 客户端的配置放在配置管理工具的基线模板中，新服务器接入集群时就已完成配置，不允许后期的遗漏

`/proc` 目录有什么作用？

/proc 是一个虚拟文件系统（procfs），它不占用磁盘空间，而是由内核在内存中动态生成，用于暴露内核内部的数据结构和运行时状态给用户空间。你可以通过读写 /proc 下的文件来获取系统信息和动态调整内核参数。
- 它是一个"活的"文件系统
  - 普通文件系统（ext4/xfs）存储的是磁盘上的持久数据。/proc 里的文件是内核在读取时才实时生成的，大小通常显示为 0 但内容不为空。ls -l /proc 看到的很多文件大小为 0 但 cat 能读到内容就是这个原因
  - 卸载 /proc 不会释放任何磁盘空间——因为它本身就不在磁盘上
- 核心用途一：查看系统运行状态
  - 进程信息：/proc/<PID>/ 是每个进程的运行状态快照
    - /proc/<PID>/status：进程状态、内存占用、线程数、Capabilities 等关键信息。cat /proc/1/status 可以查看 systemd 的详细状态
    - /proc/<PID>/cmdline：进程启动时的完整命令行（包含参数）
    - /proc/<PID>/fd/：进程打开的所有文件描述符（软链接形式，指向实际文件）
    - /proc/<PID>/environ：进程的环境变量
    - /proc/<PID>/stack：进程当前的内核调用栈（2.6.39+ 内核支持）
    - /proc/<PID>/maps：进程的内存映射区域，显示哪些地址段映射了哪些文件
  - 系统整体状态：
    - /proc/cpuinfo：CPU 详细信息（型号、核心数、标志位）
    - /proc/meminfo：内存详细使用情况（总内存、可用内存、脏页大小、Slab 等）
    - /proc/loadavg：系统平均负载（1 分钟 / 5 分钟 / 15 分钟）
    - /proc/uptime：系统已运行时间 + 空闲时间
    - /proc/diskstats：各磁盘的读写统计（IOPS、读写字节数、IO 延时分布）
    - /proc/net/tcp / /proc/net/dev：TCP 连接状态、网络接口流量统计
- 核心用途二：动态调整内核参数（sysctl 的底层就是这个）
  - /proc/sys/ 下的文件允许你在不重启的情况下修改内核行为。sysctl 命令本质上就是读写 /proc/sys/ 下的文件
  - echo 1 > /proc/sys/net/ipv4/ip_forward 等价于 sysctl -w net.ipv4.ip_forward=1
  - sysctl --system 重新加载配置时实际上是把 /etc/sysctl.d/*.conf 的内容逐一写入 /proc/sys/ 下对应的文件
- 核心用途三：与内核交互
  - /proc/sysrq-trigger：向内核发送 SysRq 命令。echo b > /proc/sysrq-trigger 立即重启（相当于按下 SysRq + B; SysRq 即 Print Screen 键, 需要 cat /proc/sys/kernel/sysrq 为 1 才可使用），echo o > /proc/sysrq-trigger 关机。多用于系统卡死但内核还活着时的紧急操作
  - /proc/self/：指向当前进程自己的 /proc/<PID/ 目录。进程自身读取 /proc/self/status 等价于读取自己的状态，不需要事先知道自己的 PID
  - /proc/zoneinfo：内存区（Zone）的详细分配信息，用于分析内存碎片
协助记忆
- /proc 是内核的对外窗口——内核把所有的运行数据"贴"在这个窗口上，你想看什么直接去窗口看，想改什么也通过窗口递条子
- 和普通目录的区别：你书架上放着的书（ext4），而 /proc 是一块实时更新的电子屏，每次去看它时显示的数据都不一样
进阶思考
- /proc/<PID>/fd/ 下的文件描述符是数字，有些指向的是 pipe:[12345] 或 socket:[67890]，这些数字代表什么？
  - fd/ 下的软链接目标如果是 socket:[inode]，说明该文件描述符是一个 socket，inode 是内核 socket 结构的唯一编号。通过 /proc/net/tcp 可以查到该 inode 对应哪个 TCP 连接（源/目标 IP 和端口）。这对于排查"这个进程到底在连哪个服务"非常有用。lsof -i 底层也是通过遍历各个进程的 /proc/<PID>/fd/ 来获取连接信息
- 为什么 ls -l /proc/ 里某些文件的大小是 0，但用 cat 能读到内容？
  - 因为 /proc 中的伪文件不占用磁盘空间，也没有预知自己的内容长度。普通文件在 stat 时可以返回文件大小，因为它是写死的。而 /proc 的内容是在 open() 时动态构建的，构建前内核不知道会有多少输出，所以 st_size 返回 0。这也是虚拟文件系统和普通文件系统的一个根本区别
- /proc 挂载失败了会怎么样？
  - 很多工具无法正常工作——ps、top、free、lsof 等工具都依赖 /proc 获取信息。系统可能会卡在启动阶段或进入紧急模式。修复方式是用安装介质进入 rescue 模式，mount -t proc proc /sysroot/proc 重新挂载
扩展信息
- SysRq 即为键盘上的 Print Screen（PrtSc） 按键, 用它的前提是 cat /proc/sys/kernel/sysrq 需要为 1
  - 常见使用场景：系统完全卡死、SSH 还能连但正常关机命令无响应时，可以用 echo s > /proc/sysrq-trigger 先强制 sync 脏页（防止数据丢失），然后 echo b > /proc/sysrq-trigger 触发重启。比直接拔电源安全很多。
  - 位掩码的含义： Ubuntu / Debian 系：默认通常是 176 或 438（438 = 256 + 128 + 32 + 16 + 4 + 2）； RHEL / CentOS 系：默认通常是 1（全部允许）
    - 1 ：全部允许
    - 2 ：允许控制控制台日志级别
    - 4 ：允许控制键盘（SAK）
    - 8 ：允许进程调试转储
    - 16 ：允许 sync 同步磁盘
    - 32 ：允许重新挂载为只读
    - 64 ：允许信号操作（term/kill/oom-kill）
    - 128 ：允许重启/关机
    - 256 ：允许调整所有实时任务的 nice 值
  - 常规组合键含义
    - Alt + SysRq + B : 立即重启
    - Alt + SysRq + O : 立即关机
    - Alt + SysRq + S : 强制同步磁盘（sync）
    - Alt + SysRq + U : 重新挂载所有文件系统为只读
    - Alt + SysRq + E : 向所有进程发送 SIGTERM（请求终止）
    - Alt + SysRq + I : 向所有进程发送 SIGKILL（强制杀掉）
    - Alt + SysRq + T : 显示当前任务信息

top 中的 VIRT、RES 和 SHR 分别是什么意思？

这三个指标描述的是一个进程在内存层面的三种不同统计口径，很多人把 VIRT 当内存占用看导致误判，实际上真正反映物理内存压力的是 RES。
- VIRT / VSZ（虚拟内存，Virtual Memory Size）
  - 进程认为自己占用的总内存空间。包括了进程的代码段、数据段、堆、栈、所有加载的共享库（.so）、mmap 映射的文件（如 JAR 包、动态库），以及可能已经换出到 swap 的部分
  - VIRT 可以远大于物理内存，因为 mmap 映射一个大文件（如 10GB 的数据库文件）但只访问了其中一小部分时，VIRT 会显示 10GB，但实际上物理内存中只占用了访问过的少量页面
  - VIRT 本身几乎不反映该进程对系统内存的压力，看这个数字主要是用来判断进程启动是否异常（比如某个进程 VIRT 突然暴增到不合理的大小）
- RES / RSS（常驻内存，Resident Memory Size）
  - 进程当前真正驻留在物理内存中的部分。这部分数据不需要从磁盘读取就能直接被 CPU 访问
  - RES 包含了该进程独占的私有内存 + 与其他进程共享的共享内存段（如共享库的代码段）
  - 这是最接近"这个进程用了多少物理内存"的指标，但仍然需要注意 RES 中包含了共享内存的部分（SHR），这部分内存可能同时被多个进程统计，求和时会导致总量超过物理内存
  - 进程的私有物理内存 = RES - SHR
- SHR（共享内存，Shared Memory Size）
  - RES 中可以被其他进程共享的部分，主要是共享库的代码段（如 libc.so、libpthread.so）、IPC 共享内存、mmap 的共享映射
  - 例如 100 个进程都加载了 libc.so，每个进程的 RES 中都包含它的代码段，但物理内存中只加载了一份，每个进程的报告中的 SHR 部分都统计了它
- 实际关系与误区
  - 大小关系：VIRT >= RES >= SHR，因为 VIRT 包含了所有虚拟空间（包括未分配物理页的部分），RES 是实际在物理内存中的，SHR 是 RES 中可以共享的
  - 常见误区：把 VIRT 当作内存占用，看到 Java 进程 VIRT 几十 GB 就以为内存泄漏。实际上 Java 的 VIRT 包含堆 + 元空间 + 所有加载的 JAR 包 + JVM 自身的 mmap 区域，几十 GB 是正常的。真正要看的是 RES，如果 RES 持续不增长或者增长在堆空间范围内就没有问题
  - ps aux 中的 VSZ 对应 VIRT，RSS 对应 RES
协助记忆
- VIRT：画的饼有多大（进程认为自己占了多大空间）
- RES：真正吃进嘴里的有（实际占用的物理内存）
- SHR：大家一起吃的部分（共享库代码段 / 共享内存）
进阶思考
- 为什么 Java 进程的 VIRT 总是特别大（几十甚至上百 GB），但 RES 很正常？
  - 这是 JVM 的内存分配机制导致的。JVM 启动时会预先申请堆空间（由 -Xms / -Xmx 控制），申请了但还没用到的堆空间也计入 VIRT，但在物理内存中还没有分配页面。此外 JVM 还会 mmap 大量的 JAR 文件（包括 rt.jar、Spring 框架的依赖包等），这些 mmap 区域全部计入 VIRT。所以 VIRT 非常大是 Java 进程的正常现象，只要 RES 在合理范围内就没事。
- RES 的总和超过了物理内存总量，这是不是算错了？
  - 不是算错了，是共享内存重复统计导致的。如果 50 个进程都加载了同一个共享库，每个进程的 RES 中都计入了该共享库的代码段大小，加起来就会远远超出物理内存。实际物理内存中只有一份该共享库的数据。要准确评估系统内存压力，应该看 free -h 中的 available 列（系统实际可用内存），而不是把各进程的 RES 简单相加
- 某个进程 RES 持续增长但 SHR 不变，说明什么？
  - 说明增长的是私有内存（RES - SHR 在持续变大），有可能是内存泄漏或者业务数据量在正常增长。排查方向：pmap -x <PID> 看具体是哪个地址段在增长，确认是堆、栈还是 mmap 区域。如果是堆增长明显，配合 jmap / jstat 看 Java 的堆内分区情况
扩展信息
- top 默认输出中还有其他几个关键列：
  - PID：进程 ID
  - USER：进程所属用户
  - PR（Priority）：进程的内核调度优先级，数字越小优先级越高。PR 由内核动态计算，受 NI 值影响。实时进程显示为 rt
  - NI（Nice Value） ：用户可调整的优先级偏置，范围 -20 ~ 19。NI 值越接近 -20 优先级越高，越接近 19 优先级越低。renice -n -10 <PID> 可以提高进程被 CPU 调度的优先级，但 NI 不会改变 PR 的基础值，只能在内核分配给该进程的范围内调整
    - 关系：PR（最终）= PR（基础）+ NI。但内核的实际调度算法更复杂
- S（Process Status） ：进程当前状态，对应内核的进程状态标识。常见值：R（运行/可运行）、S（可中断睡眠）、D（不可中断睡眠）、Z（僵尸）
- %CPU：进程在上次刷新周期内占用的 CPU 使用率。注意这是累计所有线程的 CPU 时间，如果是多线程进程（如 Java），%CPU 可以超过 100%（例如 4 核跑满显示 400%）
- %MEM：进程占用的物理内存比例，计算方法为 RES / 总物理内存 × 100%
- TIME+：进程自启动以来累计消耗的 CPU 时间（精确到百分之一秒）。排查短生命周期进程时重点关注这一列：死得很快的进程在 %CPU 上可能抓不到，但 TIME+ 的累计值会暴露它
- COMMAND：进程的命令名或命令行

简述你对内核空间和用户空间的理解？

内核空间和用户空间是现代操作系统对内存进行的特权级别划分，目的是保护内核不被用户程序意外或恶意破坏，同时提供安全的应用隔离环境。CPU 通过硬件级别的特权环（Ring）来实现这一区分。
- 内核空间（Kernel Space）
  - 操作系统内核运行的地方，拥有对硬件资源的完全控制权。能直接访问所有物理内存、所有设备寄存器、执行特权 CPU 指令（如开关中断、修改页表、操作 MMU）
  - 运行在 CPU 的最高特权级（Ring 0），用户程序无法直接访问这个空间
  - 内核空间出现崩溃（如 NULL 指针解引用、内核 Panic）会直接导致整个系统挂掉
- 用户空间（User Space）
  - 普通应用程序运行的地方。进程的代码、数据、堆、栈都分配在这个空间，看到的是一段连续的虚拟地址空间但不是真正的物理地址
  - 运行在 CPU 的最低特权级（Ring 3），不能直接操作硬件、不能访问其他进程的内存、不能执行特权指令
  - 用户进程崩溃（Segmentation Fault）通常只杀掉该进程本身，不会影响系统稳定性
- 用户程序如何访问内核功能——系统调用（syscall）
  - 用户程序需要读写文件、创建网络连接、分配内存时，不能直接操作硬件，必须通过系统调用进入内核空间让内核代为执行
  - 流程：用户程序调用 write()（libc 封装） → CPU 从 Ring 3 切换到 Ring 0 → 内核执行写操作 → 返回 Ring 3 给用户程序
  - 常见的系统调用：read()、write()、open()、fork()、mmap()、socket() 等
  - 每次系统调用都有一定的开销（上下文切换、权限检查、数据拷贝），这也是为什么内核态和用户态频繁切换会影响性能的原因
- 分界线：/proc 和 /sys
  - /proc 和 /sys 是两个虚拟文件系统，位于内核空间和用户空间的交界处，用户程序通过读写这些文件间接获取和修改内核数据
协助记忆
- 内核空间：机长舱——机长（内核）可以触碰所有仪表盘和操纵杆，但普通乘客不能进去
- 用户空间：客舱——乘客（用户程序）在自己的座位上活动，不能碰飞行控制设备，需要什么服务按呼叫铃（系统调用）让空乘（内核）来处理
- 系统调用就是"按呼叫铃"的动作——每次想要机长舱的服务都得按一次铃，按太频繁了会吵到机长（性能损耗）
进阶思考
- 系统调用的开销具体在哪里？为什么频繁系统调用会影响性能？
  - 主要开销来自三方面：
    1. CPU 模式切换（Ring 3 → Ring 0 → Ring 3）需要保存和恢复寄存器状态、切换栈；
    2. 内核需要对用户传入的参数做合法性校验（指针是否可访问、权限是否足够），这部分是内核安全设计的必要成本；
    3. 部分系统调用需要在用户空间和内核空间之间拷贝数据（如 read() 从内核缓冲区拷贝到用户缓冲区）。高 IOPS 场景下这些开销会累积成显著的性能损耗，这也是为什么 io_uring 这类减少系统调用次数的异步 IO 接口被引入的原因
- 用户空间的进程能看到其他进程的数据吗？
  - 正常情况下不能，因为每个用户进程有独立的虚拟地址空间，页表映射互不重叠。但共享内存（shm）和 mmap 的 MAP_SHARED 可以打破这个隔离，让多个进程共享同一块物理内存。此外，如果有 root 权限的进程可以通过 /proc/<PID>/mem（需 ptrace 权限）或 ptrace 系统调用来读取其他进程的内存，这也是调试器和一些安全审计工具的工作方式
- 用户空间的进程崩溃了会影响到内核吗？
  - 通常不会，内核的进程管理机制会在用户进程崩溃时回收所有资源（释放内存、关闭打开的文件描述符），然后调度其他进程继续运行。但如果用户进程触发了某些内核 Bug（如潜在的内存越界写入了内核数据结构），或者通过 mmap 操作了某个特殊设备的内存映射区，则存在影响内核稳定性的风险。但这属于 Bug 层面的破坏，正常操作下用户进程无法直接破坏内核

现在要上线一个网站，你会如何设计高可用架构？

高可用架构的核心目标是消除单点故障（SPOF），使得任何一个组件（服务器、网络、存储、中间件）出现故障时，业务依然能正常对外服务。设计思路从接入层逐层往下，每层都做冗余和故障转移。
- DNS 层：多入口与智能调度
  - 将域名解析到多个公网 IP（对应不同机房或云 Region），配置智能 DNS 实现按地域或按线路的流量调度
  - 如果其中一个 IP 不可达，DNS 的健康检查将自动摘除该 IP，客户端重试后切换到其他入口
  - 注意 DNS 缓存 TTL 设为较低值（60 ~ 120 秒），避免故障切换后客户端仍访问已宕机的 IP 导致服务中断，同时配合 HTTP 层面的重试机制来减少切换延迟的影响
- 负载均衡层：统一入口，分发流量
  - 在 Web 服务器前面部署负载均衡器（硬件 F5 / 软件 Nginx + Keepalived / 云服务商 SLB）。负载均衡器对外暴露 VIP，后端挂载一组 Web 服务器
  - 健康检查：负载均衡器定期探测后端服务器的健康状态（TCP 端口探测或 HTTP 指定路径探测），如果某台服务器连续探测失败则自动摘除，流量只分发到健康节点。恢复后自动加回
  - 负载均衡器自身也要做高可用（Nginx + Keepalived 主备或云厂商自带的 SLB 主备）。负载均衡器本身如果挂了，整个入口就断了
- 应用层：无状态 + 水平扩展
  - 应用服务本身要做到无状态——Session 不存本地，统一存到 Redis 或其它集中式缓存中，这样任意一台 Web 节点宕机后流量切到其他节点不会影响用户会话
  - 无状态 + 多节点部署天然支持水平扩展：负载上升时增加节点数量即可，不需要修改应用代码。滚动更新或灰度发布也只需要逐台摘流量、更新、加回即可，不中断服务
  - 限流与熔断：在网关层配置限流（如 Nginx + lua-resty-limit-traffic）和熔断机制，防止突发流量打垮后端服务
- 数据层：主从复制 + 高可用切换
  - 数据库部署主从架构，主库承担写入，从库承担读取。主库宕机时通过 MHA / Orchestrator / 云 RDS 自动切换机制将某个从库提升为新主库
  - 跨机房部署时需要考虑主从同步延迟问题，通常情况下同城双活架构中延迟可控，异地灾备场景下需接受一定的数据丢失（RPO）或使用半同步复制来降低丢失风险
  - 非结构化数据（图片 / 附件）使用分布式存储，不直接挂在应用服务器本地磁盘。应用本地磁盘是单点故障
- 缓存层：缓存集群 + 容错
  - 使用 Redis 集群（Codis / Redis Cluster / 云 Redis）做热点数据缓存
  - 缓存穿透 / 缓存击穿 / 缓存雪崩是常见问题，对应策略：
    - 穿透：缓存未命中时对不存在的数据也缓存一个空值（短 TTL），或使用布隆过滤器前置拦截
    - 击穿：热点 key 过期瞬间大量请求打到数据库，用互斥锁（SETNX）控制只有一个线程去加载数据
    - 雪崩：大量缓存同时过期导致数据库压力暴增，设置 TTL 时加上随机偏移量，错开过期时间
- 监控与告警：可观测性
  - 从业务指标（QPS、错误率、延迟）到底层指标（CPU / 内存 / 磁盘 / 网络）到关键日志的集中收集，确保任何一个组件有问题时能快速发现
  - 监控告警的分级设置很有必要（P0 电话告警 / P1 即时通讯 / P2 邮件），避免告警疲劳
协助记忆
- DNS 层：门口的路牌，告诉客人去哪家分店
- 负载均衡层：门口的服务员，哪个餐位有空就引导过去，某个餐位有问题暂时不安排
- 应用层：厨师，没有固定灶台（无状态），哪个灶台空就在哪做菜
- 数据层：仓库里的账本，主账本在管写入，副本账本同步更新，主账本被偷了副账本顶上
- 缓存层：准备好的配菜放冰柜，到饭点直接取用，不用每次去仓库翻原材料
进阶思考
- 数据库的读写分离架构下，主库宕机到新主库切换完成这段时间，写请求怎么处理？
  - 写请求在这段时间内必然失败，因为唯一可写入的主库不可用了。目标是缩短切换时间而不是消除这段空档。自动化切换方案（如 Orchestrator）可以在 10 ~ 30 秒内完成探测和切换，配合应用层的重试机制（如队列暂存失败请求并自动重试），多数场景下客户端感知不到显著中断。如果业务对写入可用性要求极高（如金融交易），则需要考虑多主架构（MySQL Group Replication / Galera Cluster）或分布式数据库（TiDB / OceanBase），但需要接受相应的复杂度
- Nginx + Keepalived 的方案中，Keepalived 挂了怎么办？
  - Keepalived 本身很稳定，但它确实也是一个潜在的故障点。云上架构通常直接使用云厂商的负载均衡服务（SLB / ALB），云厂商负责 SLB 的 HA，用户只需要关心后端节点的状态。线下场景中，可以用 LVS（Linux Virtual Server）代替单独的 Nginx + Keepalived 组合（LVS 本质上就是内核级别的四层负载均衡），但配置和维护复杂度更高

Linux 系统出现大量 TIME_WAIT，是什么原因、如何优化？

TIME_WAIT 是 TCP 连接关闭流程中的一个状态。主动关闭连接的一方在发送完最后一次 ACK 后会进入TIME_WAIT，等待 2 倍 MSL（Linux 中默认 60 秒）后才会彻底释放连接。大量 TIME_WAIT 本身不是故障，但达到一定程度时会消耗端口资源，影响新的出站连接。
- TIME_WAIT 出现的原因
  - TCP 四次挥手完成后，主动关闭连接的一方必须停留在 TIME_WAIT 状态，等待时间足以让网络中残留的旧数据包过期消失，防止后面的新连接误收了上一个连接的延迟数据包
  - 大量 TIME_WAIT 的根本原因是短时间内大量短连接被主动关闭。哪些场景会产生：
    - 服务器通过反向代理（Nginx）转发请求到后端时，如果 Nginx 配置了短连接模式（如 HTTP/1.0 或 proxy_http_version 1.0），每次请求完成后 Nginx 会主动关闭到后端的连接，产生大量 TIME_WAIT
    - 应用服务器频繁连接外部服务（数据库、缓存、第三方 API）且每次使用完后主动关闭连接，未使用连接池
    - 高并发的客户端频繁向服务器发起短连接后主动断开
- TIME_WAIT 可能引发的问题
  - 端口耗尽：系统向外部发起出站连接时，需要从本地临时端口范围（net.ipv4.ip_local_port_range，默认 32768 ~ 60999）中分配一个端口。如果大量连接处于 TIME_WAIT，可用的临时端口被占满，新的出站连接就会失败（Cannot assign requested address）
  - 内存开销：每个 TIME_WAIT 状态的 socket 会占用内核内存（约 256 ~ 512 字节），一万个 TIME_WAIT 大约消耗几 MB 内存，通常不是主要问题
  - 注意：TIME_WAIT 不影响入站连接（别人连你的服务）。因为入站连接的服务端端口是固定端口（如 80、443），不消耗临时端口范围
- 优化方案
  - 方案一：启用 tcp_tw_reuse（推荐且安全）
    - sysctl net.ipv4.tcp_tw_reuse=1：允许内核在分配新的出站连接时，从 TIME_WAIT 池中复用那些时间戳已更新的连接。前提是开启了 net.ipv4.tcp_timestamps（默认就是开启的）
    - 适用于客户端主动关闭连接的场景（即这台机器是出站连接发起方）
    - 安全：内核只会在新连接的初始序列号大于旧连接的最后序列号时才允许复用，不会导致数据混淆
  - 方案二：调整临时端口范围
    - sysctl -w net.ipv4.ip_local_port_range="1024 65535"：扩大可用临时端口池，从默认的约 28000 个扩大到 64000 多个
    - 配合 tcp_tw_reuse 使用效果更好。这个方法不会减少 TIME_WAIT 数量，但增加了可用的端口资源天花板
  - 方案三：从应用层减少短连接
    - 使用 HTTP Keep-Alive 或连接池，让一个连接处理多个请求后再关闭，减少主动关闭的频率
    - 如果 Nginx 到后端的连接产生了大量 TIME_WAIT，确认 proxy_http_version 1.1 已配置，并打开 proxy_set_header Connection ""，让 Nginx 尽可能复用与后端的连接
    - 应用层（数据库连接池、Redis 连接池等）确保使用了连接池，而不是每次请求都建连和断连
  - 方案四：使用长连接 + 负载均衡器收敛
    - 在负载均衡器和后端服务器之间使用长连接，负载均衡器作为"连接收敛器"——客户端短连接打到 LB，LB 通过长连接转发到后端，这样 TIME_WAIT 集中在客户端一侧，服务端侧的 TIME_WAIT 大大减少
协助记忆
- TIME_WAIT 本质：快递员把包裹交给你后，他还得在原地等 60 秒，确保你没给他差评再走（等待残留数据包过期）
- 大量 TIME_WAIT 的原因：快递员每次送完一个包裹就要等 60 秒，结果同时送了几千个包裹，所有快递员都在原地等，新包裹没快递员可派了（端口耗尽）
- 优化方向：让快递员复用一个送货通道多送几件（长连接/连接池），而不是每送一件就等 60 秒
进阶思考
- tcp_tw_reuse 和 tcp_tw_recycle 有什么区别？
  - tcp_tw_reuse 作用于出站连接，允许内核分配新连接时复用 TIME_WAIT 状态的端口。tcp_tw_recycle 作用于入站连接，会更快地回收 TIME_WAIT 状态（缩短到 RTO 而不是 60 秒），但它开启了 PAWS（时间戳校验），会丢弃时间戳比上一个连接更新的包，导致 NAT 后面的客户端频繁掉线。tcp_tw_recycle 已在 Linux 4.12 被彻底移除，不需要再考虑它
- ss -s 显示 TIME_WAIT 有几万个，但 netstat -s 没有报端口耗尽，需要处理吗？
  - 如果临时端口没有耗尽（ss -s 看 TIME_WAIT 总数小于临时端口范围上限），且不影响新连接建立，可以暂时不处理。 TIME_WAIT 本身是 TCP 协议的正常行为。但建议配置 tcp_tw_reuse + 扩大端口范围作为基线优化，防止未来流量增长后出现端口耗尽
- 为什么 tcp_fin_timeout 调小不能缩短 TIME_WAIT？
  - 这是一个常见误会。tcp_fin_timeout（默认 60 秒）控制的是 FIN_WAIT_2 状态的超时时间，不是 TIME_WAIT。TIME_WAIT 的时长在内核中是硬编码的 2 * MSL（Linux 中 MSL = 30 秒，所以 TIME_WAIT 持续 60 秒），没有 sysctl 参数可以直接修改这个值
扩展信息
TCP 连接从建立到关闭的完整生命周期包括多个中间状态，TIME_WAIT 是其中之一
- 三次握手建立连接：CLOSED → SYN_SENT → ESTABLISHED（主动方）或 CLOSED → LISTEN → SYN_RCVD → ESTABLISHED（被动方）
- 四次挥手关闭连接：
  - 主动关闭方先发送 FIN 后进入 FIN_WAIT_1
  - 被动方回复 ACK 后主动方进入 FIN_WAIT_2，等待被动方也发送 FIN
  - 被动方发送 FIN 后主动方进入 TIME_WAIT，发送最后的 ACK
  - 被动方收到最后的 ACK 后进入 CLOSED
- 各状态快速排查：
  - TIME_WAIT：出站短连接过多，ss -tan state time-wait 查看具体数量
  - CLOSE_WAIT：被动关闭方收到 FIN 但没有调用 close()，通常是应用层没正确关闭 socket。需要用 ss -tan state close-wait 定位到具体进程分析代码
  - SYN_SENT：连接建立超时，目标端口不可达或防火墙拦截
  - FIN_WAIT2：被动关闭方不发送 FIN（应用层没调用 close），可调小 tcp_fin_timeout 自动清除

Linux 中 inode 和 block 分别是什么？

inode 和 block 是 Linux 文件系统的两个核心概念。可以把文件系统理解为一本图书馆藏书目录：inode 是每一本书的登记卡（记录书的元数据），block 是书架上存放书内容的实际格子（存储数据的物理单元）。
- inode（索引节点）
  - 每个文件（或目录）都有一个唯一的 inode，相当于文件在文件系统中的身份证号码
  - inode 存储了文件的所有元数据，但不包含文件名：
    - 文件类型（普通文件 / 目录 / 符号链接 / 套接字等）
    - 权限（rwxrwxrwx）
    - 所有者（uid）和所属组（gid）
    - 文件大小（字节）
    - 时间戳：atime（最后访问时间）、mtime（最后修改时间）、ctime（最后状态变更时间）
    - 链接计数（有多少个目录项指向这个 inode）
    - 指向数据块的指针（告诉系统文件内容存在哪些 block 中）
  - inode 本身不存文件名。文件名存储在目录文件中，目录项是一个"文件名 → inode 编号“的映射表
  - ls -i 查看文件的 inode 编号，stat <file> 查看 inode 的完整元数据
  - 文件系统格式化时 inode 的数量就固定了，所以会出现 inode 耗尽但磁盘空间没满的情况（海量小文件撑爆 inode 表）
- block（数据块）
  - block 是磁盘空间分配的最小单元，ext4 默认 block 大小为 4096 字节（4KB）
  - 文件的实际内容存储在 block 中。一个文件占用 block 的数量 = ceil(文件大小 / block 大小)，但最后一个 block 可能只有部分被使用，剩余空间称为"碎片空间"或"尾部浪费”
  - block 大小直接影响存储效率：
    - block 越小（如 1024 字节）：空间利用率高，适合存大量小文件，但文件系统元数据开销大，读写小文件慢
    - block 越大（如 4096 字节）：大文件读写性能好，小文件会浪费空间（一个 1 字节的文件也要占一个 4KB 的 block）
  - 超大文件需要多个 block 来存储，inode 通过指针系统（直接指针 + 间接指针）来定位这些 block。ext4 使用区段树机制，每个区段可以记录一段连续 block 的起止位置，大幅减少了连续大文件所需的指针数量
- inode 和 block 的关系
  - 创建文件的过程：分配一个空闲 inode（写入元数据）→ 分配足够的 block（写入文件内容）→ 在目录中创建"文件名 → inode 编号"的映射
  - 删除文件的过程：删除目录中的映射（文件名消失）→ 释放 block（可被新文件覆盖）→ 释放 inode（可被新文件使用）
  - 软链接和硬链接的区别在 block 和 inode 层面体现得更清晰：
    - 硬链接：两个文件名指向同一个 inode 编号，inode 的链接计数 + 1，不消耗新的 inode 或 block
    - 软链接：创建一个新的独立 inode，文件内容存储的是目标文件的路径名，不指向相同的 inode
协助记忆
- inode：每本书的编目卡片——卡片上记录作者、书号、摆放位置、借阅记录（元数据），但不写书的实际内容
- block：书架上的书籍格位，每格可以放多少册书（block 大小），最小的书也要占一整格
- 目录（directory） ：图书馆的索引台——你通过书名查到书的编目号（文件名 → inode 编号），然后去对应书架找书
- 文件名：书的外壳封面，和里面的编目卡片是两回事。可以有多个封面指向同一张编目卡片（硬链接），也可以有一个封面指向另一个书架的书的编目号（软链接）
进阶思考
- stat /etc/hosts 中 ctime 是创建时间吗？为什么改了权限之后 ctime 也会变？
  - ctime 是"状态变更时间"，不是创建时间。inode 的元数据（权限、所有者、链接计数等）每发生一次变更，ctime 就会更新一次。所以 chmod、chown、或者硬链接增加时 ctime 都会变。而 mtime 只跟踪文件内容的变化（write / truncate）。Linux 下文件的"创建时间"（birth time）在 ext4 中已经有支持（crtime 字段），但 stat 命令要较新的版本才能显示
- 在一个 ext4 分区上创建了 1 万个 10 字节的小文件，为什么剩余空间看起来少了很多？
  - 每个小文件占用 1 个 inode（inode 表空间） + 1 个 block（4KB）。所以 1 万个 10 字节的文件实际占用约 40MB 的 block 空间（而不是 100KB 的数据量），再加上 inode 表本身占用的空间。这就是"碎片浪费"——一个 10 字节的文件也要占 4KB 的 block。解决方案：如果大量小文件是固定场景（如 Git 仓库对象），可以调整 block 大小（如 mkfs.ext4 -b 1024）来减少浪费
- 硬链接可以跨文件系统吗？软链接可以吗？
  - 硬链接不能跨文件系统，因为 inode 编号只在同一个文件系统内唯一。不同文件系统上的文件 inode 编号可能相同但指向的是完全不同的文件。软链接则只是一个特殊文件存了目标路径，可以跨文件系统，甚至可以链接一个不存在的路径（断裂的软链接）
- inode有多少个时间戳属性
  - atime（Access）：最后访问时间，一般是由 cat、less、grep、head、tail、scp 等读操作触发更新
  - mtime（Modify）：最后修改时间，一般是由文件内容被写入时（vim 保存、echo >、cp 覆盖）触发更新
  - ctime（Change）：最后状态变更时间，一般是由 inode 元数据变更时（chmod、chown、硬链接增删、文件内容修改时也会变）
  - crtime / btime（Birth）：创建时间，ext4 文件系统新增，记录文件创建时间（stat 命令默认不显示，需要较新的 stat 版本）
扩展信息
atime 每次读文件时内核都要更新 inode 上的 atime，这意味着每次读文件都要产生一次写 IO。在高频读场景下（如静态文件服务器、Web 服务、NFS），这个开销非常可观。
- 所以现代内核引入了两个优化挂载参数:
  - relatime（相对 atime）：Linux 2.6.20 引入，现在很多发行版的默认挂载参数。只有以下条件满足时才会更新 atime （大部分读操作不会触发 atime 写入，只有真正"很久没人访问过"的文件才会更新一次）：
    1. 当前的 atime 比 mtime 或 ctime 旧
    2. 或者距离上一次 atime 更新已超过 24 小时
  - noatime：完全关闭 atime 更新，彻底避免读操作产生写 IO。性能提升最明显，但某些依赖 atime 的程序（如邮件系统的 mailbox 检查、Mutt、部分备份工具）可能行为异常。

你怎么理解系统负载（load average）？

系统负载是衡量 CPU 资源竞争程度的关键指标，很多人把它简单理解为"CPU 使用率"但两者不是一回事。负载度量的是正在运行 + 等待运行的进程数，而不是 CPU 有多忙。
- load average 的定义
  - 内核在采样周期内统计的处于 R（正在运行） 和 D（不可中断睡眠，等待 IO） 状态的进程总数的移动平均值
  - top 和 uptime 显示 1 分钟 / 5 分钟 / 15 分钟三个值，这三个值反映的是不同时间窗口内的平均等待队列长度
- 负载 vs CPU 使用率，本质区别
  - CPU 使用率（%CPU） ：CPU 有多忙。忙到 100% 不一定是问题，如果你的 CPU 一直闲着你反而该问问钱花哪去了
  - 负载（load） ：有多少进程在等待 CPU。等的人多才是问题，哪怕 CPU 只有 50% 利用率，但如果排队进程数远超过 CPU 核心数，说明 CPU 带宽不够分配了
- 如何判断负载是否合理（核心是 核数比值）
  - 判断标准不是绝对值看大小，而是和 CPU 核心数比
    - 负载 < 核心数：CPU 资源充裕，没有排队等待
    - 负载 ≈ 核心数（0.7 ~ 1倍）：CPU 基本饱和，但还没明显排队，这是合理的满载状态
    - 负载 > 核心数（1.5 倍以上）：进程在排队等待 CPU，需要排查 CPU 是否不够用或 IO 是否有瓶颈
  - 举个具体的：8 核服务器上负载 6 是正常的（每核不到一个任务在等），负载 80 就是灾难（平均每核有 10 个进程在排队）
- 高负载不等于高 CPU 使用率（经典误判场景）
  - 如果有大量进程卡在 D 状态（等待磁盘 IO），它们的等待也会计入负载统计，但此时 CPU 使用率可能很低（CPU 在空等 IO）。这就解释了为什么有时候负载很高但 CPU id 却很高——是 IO 瓶颈而不是 CPU 瓶颈
  - 所以看到高负载后不能直接加 CPU，要先看 top 里的 wa（IO Wait）列确认是不是 IO 导致的排队
- 三个值的解读（1分钟 > 5分钟 > 15分钟的走向判断）
  - load average: 12.5, 8.2, 4.0：负载在近期快速上升，说明问题正在发生或流量突然暴增
  - load average: 4.2, 8.5, 10.3：负载在近期下降，说明问题正在缓解或你已经在处理了
  - load average: 8.1, 8.3, 8.0：三个值接近，说明系统处于稳定的饱和状态，可能持续了较长时间
协助记忆
- CPU 使用率是你有没有在工作；负载是工作台前有多少人在排队等活干
- 一个人（1 核）干活：等的人不超过 1 个是正常；3、4 个人围着你等就是负载高
- 一根线判断：负载值超过 CPU 核数说明有人在排队了，超过核数越多队伍越长
进阶思考
- 为什么 uptime 显示的负载有时候能看到 8.0 以上但机器的 %CPU 并不高？
  - 因为负载统计包含了 D 状态（不可中断睡眠，等待 IO）的进程数。如果很多进程在等待磁盘或网络 IO，这些进程计入负载但 CPU 是空闲的。这时候该排查的是 IO 瓶颈而不是 CPU，重点看 iostat -xz 1 的 await 和 %util
- 单核服务器上负载 3.0 就卡得不行，40 核的服务器负载 30.0 可能还很流畅，为什么？
  - 因为负载是和核心数对比才有意义。单核上 3.0 意味着每核有 3 个任务在等，而 40 核上 30.0 对应每核不到 1 个任务在等，后者其实是很健康的负载
- 为什么有时候系统负载为零但 CPU 使用率显示 100%？
  - 这种情况通常是计算密集型单线程任务导致的。一个单线程程序占满单个 CPU 核心（使用率100%），但因为只有一个任务在执行且没有其他任务排队，所以负载很低（接近于 1 / 核心数）。这再次说明负载和使用率两个维度各自看不准全貌，要结合起来分析

如何提升运维工作效率？

提升运维效率不是买更好的工具就完事了，核心是把人的精力从重复劳动中解放出来，专注在真正需要判断和决策的事情上。从标准化、自动化、工具化、流程化四个方向入手。
- 标准化是一切自动化的前提
  - 操作系统版本、分区方案、主机命名规则、目录结构、端口分配规则全部统一。没有标准化，自动化的脚本要为每种"特例"写分支逻辑，越写越复杂最后没人维护
  - 部署标准化：新服务器上架使用 PXE + Kickstart 自动装机，或使用镜像模板克隆，从物理上机到系统可用做到无人值守
  - 配置标准化：基础配置（NTP、DNS、syslog、防火墙基线）纳入配置管理工具统一推送，每台机器开箱即用
- 自动化替代重复操作
  - 配置管理：Ansible / SaltStack / Puppet 统一管理服务器配置。所有变更先在测试环境验证，然后通过工具批量推送到生产。禁止逐台 SSH 改配置
  - CI/CD 流水线：代码提交后自动触发构建、测试、部署。减少人工介入的环节也就减少了出错的机会
  - 日志和监控自动化：监控平台的告警规则、日志轮转、备份策略全部通过配置管理工具下发，不依赖人工逐台配置
  - 故障自愈：对于一些已知的、有明确处理方案的故障（如磁盘使用率超过 90% 自动清理临时文件、Nginx 进程挂了自动拉起），配置自动化的处置策略，减少不必要的人工响应
- 工具化减少认知负载
  - 建立运维脚本库或内部工具平台，将常用的排查脚本（如系统巡检脚本、日志分析脚本、批量操作脚本）标准化沉淀下来，降低每个人的重复劳动
  - 操作审计和变更管理工具记录每一次操作，出问题时有日志可查，不用靠回忆和聊天记录追溯
  - 资产管理（CMDB）记录服务器的基础信息和生命周期状态，减少信息不同步带来的沟通成本
- 流程化降低沟通成本
  - 变更管理：任何生产变更都要经过申请 → 审批 → 执行 → 验证的流程，配上下线窗口和灰度策略。看似增加了步骤，实际上避免了"先改再说，出事了群里喊人"的混乱
  - 故障复盘：每次故障处理后输出复盘文档，记录故障根因、处理过程、改进措施，形成知识沉淀。一个团队踩过的坑不应该让另一个人再踩一遍
  - 值班轮转和知识交接：每个人维护的系统和工具要有文档沉淀，不能存在"只有某某人会搞"的单点依赖
- 监控与可观测性建设
  - 建立分层监控体系：基础设施（CPU/内存/磁盘/网络）→ 中间件（Nginx/MySQL/Redis）→ 业务指标（QPS/错误率/延迟），每一层都有明确的告警阈值
  - 日志集中收集（ELK / Loki），方便故障时跨系统关联排查
  - 告警分级避免告警疲劳：P0（电话通知，立即响应）、P1（即时通讯，工作时间处理）、P2（邮件，排期处理）
协助记忆
- 标准化：统一规矩，脚本不用写 if-else 处理特例
- 自动化：让机器干活，人做判断
- 工具化：把经验固化成工具，不靠记忆力
- 流程化：按规矩办事，不出事有记录，出事了可追溯
进阶思考
- 运维自动化做到什么程度算"到位"了？
  - 有一个简单的判断标准——新服务器从上架到接入监控，你还需要手动 SSH 上去敲命令吗？如果还需要，那就还有自动化的空间。另一个标准是值班手机响起来时，你希望它是告诉你故障已经被自动处理了，还是叫你起床手动处理？理想状态下，90% 以上的已知故障场景能自动处置，人工只需要处理那 10% 的未知故障和决策性变更
- 小团队（3 ~ 5 人）要不要上自动化平台？
  - 要，但要有选择。小团队资源有限，不需要一步到位建全量的运维平台。优先做投入产出比最高的几件事：Ansible 管理配置（减少逐台操作的重复劳动）、Prometheus + Grafana 基础监控（缩短故障发现时间）、日志集中收集（缩短故障排查时间）。这三件事覆盖了最痛的几个点，每件一个人花一两天就能搭起来，产出立竿见影
- 同事不愿意用自动化工具怎么办？
  - 这是个常见的组织问题，技术方案本身解决不了。核心原因是通常不是人懒，而是当前的工具不够好用。运维工具的门槛越低，大家越愿意用。与其要求所有人学会用 Ansible 写 Playbook，不如把常用的操作封装成"填一个表单、点一个按钮"就能执行的工具，让工具去适配人的习惯而不是反过来。第二步是建立规范——规定所有生产变更只能通过工具执行，SSH 直连改配置作为违规记录。

运维工程师如何保障数据安全？

数据安全不是装个防火墙就能解决的问题，它贯穿数据的整个生命周期——从生成、传输、存储、使用到销毁，每个环节都有对应的风险和控制措施。核心目标是保障数据的机密性（只有授权的人能看）、完整性（数据不被篡改）和可用性（数据随时能用）。
- 备份与容灾
  - 定期全量 + 增量备份是数据安全最基础也最重要的一道防线。勒索病毒、误删除、硬件故障、自然灾害——不管什么原因导致数据丢了，有备份就能恢复
  - 备份策略参考 3-2-1 原则：至少 3 份副本，存储于至少 2 种不同介质上，至少有 1 份异地存储
  - 备份必须定期做恢复演练，否则你无法确认备份文件是不是可用的。一个损坏的备份比没有备份更有欺骗性——你以为有退路，实际上没有
  - 数据库的备份策略区分逻辑备份（mysqldump/pg_dump，适用于单库迁移或部分恢复）和物理备份（XtraBackup/PG 基础备份，适用于全量恢复和搭建从库）
- 访问控制与权限管理（机密性的核心）
  - 最小权限原则：每个账号只分配完成任务所需的最小权限集合。数据库账号不留 root，只按业务拆分读写账号；服务器登录使用普通用户 + sudo 授权，不直接使用 root 登录
  - 堡垒机 / 跳板机：所有对生产环境的 SSH 访问通过堡垒机统一认证和审计。操作记录可以追溯，谁在什么时间执行了什么命令都有日志可查
  - 密钥管理：SSH 密钥、API Token、数据库密码等敏感信息集中管理。可以使用 Vault 或内部密钥管理平台，禁止在配置文件中明文写入密码。如果是小团队，至少也要用一个加密的密码管理工具统一管理。
- 数据传输与存储加密
  - 传输加密：所有生产环境的内部通信应使用 TLS/SSL 加密（HTTPS、FTP over TLS、数据库 SSL 连接）。即使在内网，也默认加密通信，防止内网嗅探
  - 存储加密：敏感数据在数据库中应该以加密形式存储（如身份证号、手机号、支付信息），使用数据库的加密函数或应用层加密。对于磁盘级别，可以使用 LUKS 全盘加密或云厂商的云盘加密功能
- 网络安全防护
  - 防火墙策略：只开放业务必需的端口，非必要端口不暴露。使用安全组或 iptables 做最小化放行策略
  - 入侵检测：部署 IDS/IPS（如 Snort、Suricata）监控异常流量模式。至少需要配置 SSH 登录失败的告警，防止暴力破解
  - 定期更新和漏洞扫描：系统和中间件的安全补丁及时更新，使用漏洞扫描工具（如 OpenVAS、Nessus）定期巡检
- 审计与合规
  - 操作日志集中收集和长期保存（至少 6 ~ 12 个月），包括系统日志、应用日志、数据库审计日志
  - Linux 下的 auditd 可以监控特定文件或系统调用的访问记录，用于排查谁在什么时候访问了敏感文件
  - 定期的权限审计：检查是否有长期未使用的账号、权限过大的账号、离职人员未回收的账号
协助记忆
- 备份：有副本才是真安全，没有恢复验证的备份都是心理安慰
- 权限：给最小够用的钥匙，不是万能钥匙
- 加密：传输和存储都加密，内网也不能裸奔
- 审计：所有操作有日志可查，出了事能追溯到人
进阶思考
- 数据库备份文件本身也是敏感数据，怎么保证它的安全？
  - 备份文件的安全同样重要。常规做法是：备份文件在生成后立即使用 GPG 或 openssl 进行加密（gpg --encrypt --recipient <key>），然后通过 scp 或 rsync 传输到异地存储服务器，传输过程走 SSH 加密通道。加密后的备份文件存储在独立的、访问权限严格受限的备份服务器上，并定期检查备份文件的完整性（checksum 校验）。这样即使存储备份的服务器被攻破，攻击者没有解密密钥也无法读取数据
- 勒索病毒加密了服务器，服务器上有备份，恢复后还需要做什么？
  - 直接恢复备份是不够的，必须先确认病毒是怎么进来的。如果入口没堵上，恢复后可能再次被感染。需要排查的内容包括：入侵路径（SSH 弱密码？Web 漏洞？钓鱼邮件？）、横向移动痕迹（病毒是否已经加密了其他服务器）、是否有后门程序残留。建议先隔离被感染的服务器，重建系统后再从备份恢复数据，而不是直接在原系统上恢复
- 容器化环境中数据安全和传统物理机/虚拟机有哪些不同？
  - 容器共享宿主内核，隔离性不如虚拟机，所以容器的数据安全侧重点不同。镜像仓库需要做安全扫描（检测基础镜像中的已知漏洞）；容器内的敏感数据优先使用 Kubernetes Secret 或外部密钥管理服务，而不是写在镜像里；容器运行时限制 root 权限（run as non-root、readOnlyRootFilesystem）、使用 seccomp/AppArmor 限制系统调用。但核心原则（备份、加密、最小权限、审计）没有变，只是实现方式从系统层面变成了容器编排层面的配置
扩展信息
- LUKS（Linux Unified Key Setup）— 磁盘加密标准
  - LUKS 是 Linux 下最通用的全盘加密方案，它不是一个独占分区或文件系统，而是在物理磁盘和文件系统之间加了一层加密映射。写入数据时自动加密，读取时自动解密，对上层应用完全透明
  - 核心操作：
    - cryptsetup luksFormat /dev/sdb：初始化 LUKS 分区，设置加密密码
    - cryptsetup open /dev/sdb mydata：输入密码后解锁，在 /dev/mapper/mydata 映射出一个明文设备，然后挂载使用
    - cryptsetup close mydata：锁定并断开映射
  - LUKS 最典型的应用场景是笔记本或移动硬盘的整盘加密——一旦设备丢失，没有密码就无法读取任何数据，即使把硬盘拆下来挂到其他机器上也读不出（因为是硬件级的加密块存储）。服务器场景中通常配合 TPM 或网络解锁（Tang 服务器）实现自动解锁，避免重启后需要人工输入密码才能挂载数据盘
    - 关键注意：LUKS 的密码如果忘记了，数据就永久丢失了——没有后门可以找回。密钥管理比加密本身更重要
- auditd（Linux Audit Framework）— 内核级审计系统
  - auditd 是 Linux 内核自带的审计框架，可以监控系统上发生的各种事件并记录到审计日志中。它的能力比 history 强得多——history 只记录 Shell 命令，auditd 可以记录系统调用级别的操作
  - 核心规则配置（/etc/audit/rules.d/audit.rules）：
    - 监控某个重要文件谁在读/写：-w /etc/passwd -p rwxa -k passwd_watch
    - 监控某个系统调用被调用：-a always,exit -S execve -k command_log（记录所有命令执行）
    - 监控某个目录下所有文件的变更：-w /data/secrets/ -p wa -k secrets
  - 查看审计日志：ausearch -k passwd_watch 按前面的 -k 标签过滤，或 aureport -l 生成登录汇总报告
  - 一个典型的排查场景：发现某个配置文件被改了但不知道是谁改的。如果 auditd 配置了对该文件的 -w 监控，ausearch -k <tag> 可以直接看到是哪个进程（PID）、什么时间、以什么用户身份修改了这个文件。没有 auditd 的话，文件只有 mtime 时间戳和最后修改的 uid，信息非常有限甚至找不到责任人
  - 注意 auditd 在高频路径上开启监控时会产生大量日志（如监控 execve 系统调用，每条命令执行都记录一条），建议只对关键路径开启精确监控，避免日志风暴