云南白药校招 IT 工程师面试经验——求职精灵（finsight.work）

回答时分两层：先说服务清单，再点出每个服务的协议与端口，面试官通常顺着端口继续追问。常见服务包括：NTP 或 Chrony 负责时钟同步，集群环境里时间不一致会直接导致认证失败；DHCP 动态分配主机地址，基于 UDP 67 端口；DNS 做域名解析，跑在 UDP 53 端口之上；NFS 是网络文件系统，依赖 RPC，可以跨操作系统共享目录；Postfix 提供邮件服务；rsync 做远程数据备份与增量同步；VPN 提供加密的远程接入通道。收尾可以补一句：生产环境一般用 systemd 统一管理这些服务，排查时先看 systemctl status 再看端口监听。

FTP 的工作模式按服务端视角分为主动与被动两种，区别在于数据连接由谁发起。主动模式（PORT）：客户端把自身的数据端口告诉服务端，服务端用 20 端口主动连回客户端一个大于 1024 的随机端口传输数据，21 端口始终用于控制连接。被动模式（PASV）：服务端开放一个随机端口等待客户端来连，数据连接由客户端发起。实际生产中几乎都用被动模式，因为客户端多在 NAT 或防火墙后面，服务端主动回连经常被拦截。回答时把「控制连接 21、数据连接 20」和「谁主动发起」讲清楚，就足以应对追问。

先给定义再给特征。云计算是基于虚拟化技术、把计算存储网络等资源池化后，以按量付费方式提供的按需服务，核心是把资源的使用权和使用者解耦。五个基本特征：1. 按需自助服务，用户可自行开通资源，不需要人工审批；2. 广泛的网络访问，任何联网终端都能接入；3. 资源池化，多租户共享同一资源池，物理位置对用户透明；4. 快速弹性，可以快速扩容与释放；5. 可计量的付费，按实际用量结算。回答时最好补一句落地形态：IaaS、PaaS、SaaS 三层，以及私有云、公有云、混合云的取舍，这样答案就从概念走到了工程。

Kubernetes 是基于容器的分布式编排平台，源自 Google 内部的 Borg，现在是 CNCF 的旗舰项目。它解决的问题是：当容器数量从几个涨到几百上千时，如何自动部署、调度、扩缩和自愈。核心能力包括：以 Pod 为最小调度单元，通过 Deployment、StatefulSet 管理副本与滚动升级；Service 提供稳定的服务发现与负载均衡；ConfigMap 与 Secret 做配置和密钥注入；配合 HPA 实现弹性伸缩；节点故障时自动迁移重建。回答时建议带一句架构：控制面的 apiserver、etcd、scheduler、controller-manager，加上每台机器上的 kubelet 与 kube-proxy，能立刻显出深度。

两者都只存实际字符长度加 1～2 字节的长度前缀，磁盘占用几乎一样，差别在内存与约束。1. 内存分配：排序、临时表、连接缓冲会按声明长度预留，varchar(200) 更耗内存，join 或 order by 时容易落到磁盘临时表；2. 索引限制：MySQL 单列索引前缀有长度上限，InnoDB 常见为 767 字节，开启大前缀后可到 3072 字节，utf8mb4 下 varchar(200) 占 800 字节，建索引需要指定前缀长度；3. 语义约束：长度声明本身就是业务校验，药品编码、批次号应按实际规则定长，不要一律给 255。结论是按业务上限的 1.2 倍左右取值，既留余量又不浪费。

主从复制本质是 binlog 的异步重放，分四步：1. 主库把变更写入 binlog，ROW 格式记录行级变更，比 STATEMENT 更安全；2. 从库的 I/O 线程连上主库，请求指定位置的 binlog；3. 主库的 dump 线程推送日志，从库写入本地 relay log；4. 从库的 SQL 线程读取 relay log 并重放，从而与主库保持一致。排查延迟时要分清是 I/O 线程卡住（网络、大事务）还是 SQL 线程卡住（从库写入压力、无主键表全表扫描）。生产上通常配合半同步复制降低丢数据风险，读写分离时还要注意主从延迟导致的读旧数据问题。

Nginx 的 upstream 支持多种策略：1. 轮询，默认按顺序分发，适合后端配置一致的场景；2. 加权轮询，用 weight 控制比例，机器配置不同时按算力分配；3. IP 哈希，同一客户端固定落到同一台机器，解决会话保持，但节点故障时会话会丢；4. 最少连接，发给当前连接数最少的节点，适合长连接或请求耗时差异大的服务；5. URL 哈希，同一 URL 落到同一节点，提高缓存命中率，配合一致性哈希可以减少节点变动带来的抖动。回答时补一句健康检查与失败重试的配置，并说明会话保持优先用共享 session，而不是长期依赖 IP 哈希。

区分的关键是「代理谁」和「在哪配置」。正向代理部署在客户端一侧，替客户端访问外部网络，服务端只看到代理的地址，典型场景是企业上网行为管理与访问控制。反向代理部署在服务端一侧，替后端服务器接收请求，客户端以为自己访问的就是真实服务器，典型场景是负载均衡、静态加速、SSL 卸载和隐藏真实后端。三点区别：代理对象不同，正向代理客户端、反向代理服务端；配置位置不同，正向在客户端、反向在服务端；透明度不同，正向对服务端透明，反向对客户端透明。一句话记忆：正向是「我替你出去」，反向是「我替你挡在前面」。

准确说法是「命令执行单线程，网络 I/O 在 6.0 之后可以多线程」。1. 核心网络模型基于 I/O 多路复用（epoll），单线程轮询就足以支撑十万级 QPS，因为瓶颈通常在内存与网络而不是 CPU；2. 单线程天然避免了锁竞争和上下文切换，命令具备原子性，实现也简单；3. Redis 6.0 引入多线程只用于读写 socket 和协议解析，命令仍在主线程串行执行，所以不用担心数据竞争；4. 真正会阻塞主线程的是大 key、keys 命令和复杂 Lua 脚本。回答时补一句：需要多核时用集群分片，而不是给单实例开多线程。

三者都会把压力打到数据库，但触发条件不同。缓存雪崩：大批 key 在同一时间过期，或缓存服务整体宕机，请求全部回源。解法是过期时间加随机抖动、热点数据预热、多级缓存，以及熔断降级兜底。缓存穿透：查询的是根本不存在的数据，缓存永远不命中，请求直穿数据库，常见于用不存在的 ID 刷接口。解法是布隆过滤器前置拦截、缓存空值并设短过期、入参合法性校验。缓存击穿：单个热点 key 过期瞬间，大量并发同时回源。解法是互斥锁只放一个请求回源、逻辑过期不物理删除、异步更新。记法是：雪崩是「面」，穿透是「无」，击穿是「点」。