03. 针对岗位要求的查漏补缺：非语言知识点补充（深挖版）¶

这篇不是泛泛而谈的“再补一点八股”，而是直接对照下面这类岗位要求做补强：

TCP/UDP 网络协议及相关编程

进程间通讯编程

算法、操作系统、软件工程、设计模式、数据库系统、网络安全

MySQL / SQL

NoSQL、Key-Value 存储原理

分布式系统、负载均衡、系统容灾、高可用系统

云原生相关技术

仓库里原本已经有：操作系统、网络、MySQL/Redis、基础架构、项目排障等主干内容。这篇重点补的是：原仓库里相对分散、薄弱、或者缺少“面试成体系回答”的部分。

先把这一章的知识骨架搭起来¶

岗位要求补强这章，目的不是再堆一份八股，而是把 JD 里常见但你准备不足的点系统补齐。很多岗位描述看似只是列关键词，背后对应的其实是能力缺口：TCP/UDP 对应网络编程基础，IPC 对应系统编程能力，数据库和缓存对应服务端数据链路，安全和软件工程对应工程边界感。

因此这章要按“岗位词汇 → 实际能力 → 具体知识点 → 面试表达方式”去看。只有这样，补强才会直接提升投递匹配度。

进入问答前，先把最小前置知识补齐¶

这章的作用不是重复八股，而是把 JD 里那些“你可能零散知道、但还没形成稳定表达”的要求重新整理成能力缺口。只有把“岗位要求到底在映射什么能力”想清楚，补强才有方向。

所以阅读时最好一直做映射：这个岗位词条背后要补哪部分知识、哪种场景、哪种表达方式。这样你补的就不是目录，而是岗位匹配度。

0. 先给结论：目前仓库相对缺哪些点？¶

如果先不看语言本体，只看这个岗位的非语言要求，你现在仓库的情况大致可以分成三类。

已有较强覆盖¶

操作系统基础：进程/线程/内存/IO 多路复用/文件系统/信号
计算机网络：TCP/UDP/HTTP/RPC/MQ/DNS/CDN
数据库与缓存：MySQL、Redis、事务、索引、MVCC、缓存一致性
架构基础：设计模式、高并发、线程池、线上排障
算法基础

已有内容，但还不够“岗位定向”¶

进程间通信：已有基础，但缺少服务端工程视角下的取舍总结
高可用/分布式：有零散内容，但缺少一篇系统总览
项目排障：已有，但缺少监控/可观测性体系化视角

当前最值得补齐的缺口¶

软件工程基础：代码评审、测试、CI/CD、回滚、发布流程、可维护性
网络安全基础：认证、授权、TLS、常见攻击、防刷、防重放、接口安全
NoSQL / Key-Value 原理：不只是会说 Redis 快，还要知道 KV 系统怎么组织写放大、压缩、分片和一致性
分布式系统 / 负载均衡 / 容灾 / 高可用：这块很像 JD 明确加分项，值得专门补成一章
可观测性与稳定性工程：监控、日志、链路追踪、告警、SLO、容量治理
云原生基础：容器、K8s、服务发现、配置、弹性、健康检查

一句话概括：

你现在的仓库已经像“C++ / 后端基础知识库”，但如果要更贴这个岗位，还需要再补上工程体系、分布式体系、安全体系、云原生体系这四条线。

1. 软件工程：为什么后端岗也会问？¶

很多人会把软件工程理解成“写文档、画图、背瀑布模型”，但真正的后端 / 基础设施岗位里，软件工程问的是：

你能不能把代码长期维护住？
你有没有质量意识？
你做改动时，是否知道怎么降低风险？
你是否理解团队协作、测试、发布、回滚这些工程闭环？

1.1 基础知识：软件工程在服务端里到底是什么？¶

核心目标¶

软件工程本质上是在解决四个问题：

可维护性：代码以后还能不能改
可测试性：改完能不能验证
可协作性：多人一起做会不会互相踩
可交付性：功能能不能稳定上线

面试里常问的基础点¶

1）为什么要做代码评审？¶

不只是为了找 bug，更是为了：

保持代码风格和抽象一致
提前发现设计问题
让知识在团队里扩散
避免单点依赖

2）单元测试、集成测试、端到端测试区别？¶

单元测试：验证局部函数/模块逻辑
集成测试：验证模块之间协作是否正常
端到端测试：从用户入口到最终结果做全链路验证

3）为什么要做 CI/CD？¶

因为手工流程容易：

漏步骤
环境不一致
发布不可重复
回滚不标准

CI/CD 的意义不是“自动化很酷”，而是降低人为失误，提高交付确定性。

4）什么是灰度发布？¶

先让一小部分流量进入新版本，确认：

功能正常
性能没恶化
错误率没升高

再逐步放量。

5）为什么回滚方案和发布方案一样重要？¶

因为真正的线上改动不是“上线成功就结束”，而是：

出问题能快速止损
影响范围可控
能恢复到稳定状态

一句标准总结¶

软件工程在后端场景里，不是抽象理论，而是如何把代码从“能跑”提升到“能维护、能验证、能稳定上线”。

1.2 面试可能追问的进阶点¶

追问 1：代码质量怎么衡量？¶

可以从几个维度答：

正确性
可读性
可测试性
可扩展性
复杂度控制
运行时性能与资源成本

不要把“代码质量”只理解成格式整齐。

追问 2：为什么有些系统测试很多，还是容易出事故？¶

因为问题可能不在“有没有测试”，而在：

测试覆盖不到真实流量结构
缺少异常路径和边界条件
环境和生产不一致
没有容量压测和回归验证

追问 3：重构和重写怎么选？¶

高分回答通常会说：

优先局部重构，控制风险
只有当历史债务和架构约束太大，才考虑重写
重写最大风险不是技术，而是新旧系统长期并行和需求漂移

追问 4：如何避免需求迭代把系统做烂？¶

可以说：

把变化点收敛到明确模块
做接口边界和依赖管理
用 review 保持一致抽象
控制技术债，别无限堆 patch

2. 进程间通信（IPC）：从“背名字”到“服务端取舍”¶

仓库里已经有 IPC 基础，但岗位要求里明确写了“进程间通讯编程”，这类题经常会从基础继续追到工程选型。

2.1 基础知识：常见 IPC 方式及适用场景¶

1）管道 / 命名管道¶

适合本机、简单、字节流传输
无名管道常见于父子进程
命名管道适合无亲缘关系进程

2）消息队列¶

提供消息边界
比字节流更像“传消息”而不是“传字节”
适合解耦，但有拷贝和排队开销

3）共享内存¶

速度很快
适合大块数据交换
但同步复杂，需要额外锁/信号量控制

4）信号量¶

本身不是数据通道
更像同步与资源计数工具

5）Socket / Unix Domain Socket¶

最通用
Unix Domain Socket 适合同机进程通信，省去了完整网络协议栈的一部分开销
TCP Socket 更适合跨机

6）mmap¶

常用于文件映射，也可结合共享映射做高效共享

一句总结¶

IPC 的选择不是记忆题，而是吞吐、延迟、同步复杂度、是否跨机、是否需要消息边界之间的权衡。

2.2 面试高频追问¶

追问 1：共享内存为什么快？¶

因为它减少了数据在内核态/用户态之间的多次拷贝，多个进程可以映射同一块物理内存。

追问 2：共享内存为什么难？¶

因为“共享”虽然快，但意味着：

并发同步自己负责
生命周期管理更复杂
崩溃恢复和脏数据处理更难

追问 3：同机服务通信为什么有时会用 Unix Domain Socket？¶

因为它既保留了 socket 编程模型的通用性，又比完整 TCP 栈更轻，适合本机服务进程间通信。

追问 4：什么时候消息队列比共享内存更合适？¶

当你更在意：

解耦
顺序语义
生产消费模型
开发复杂度

而不是极致吞吐时，消息队列通常更省心。

3. 数据库系统：别只会 MySQL 名词，还要会“系统视角”¶

你仓库里已经有 MySQL 和 Redis，但 JD 写的是“数据库系统”，面试官常会把问题往更抽象的系统层面推。

3.1 基础知识：数据库系统应该怎么整体理解？¶

数据库系统的几个核心目标¶

数据组织与查询效率
并发控制
崩溃恢复
一致性与持久性
扩展能力

高频基础点¶

1）为什么数据库需要 WAL？¶

WAL（Write-Ahead Logging）核心思想是：

先写日志
再写数据页

这样崩溃恢复时，可以根据日志：

重做已提交事务
回滚未完成事务

2）为什么数据库要有 Buffer Pool？¶

因为磁盘太慢，热点页放内存里可以显著减少随机 IO。

3）为什么索引不是越多越好？¶

因为索引会增加：

写入维护成本
空间占用
Buffer Pool 压力
执行计划复杂度

4）读写分离解决什么问题？¶

核心是：

主库承接写
从库承接读

提升读吞吐，但代价是：

复制延迟
主从切换复杂
一致性窗口问题

5）分库分表解决什么问题？¶

单机容量、单表规模、热点和吞吐瓶颈。

但它会引入：

跨分片事务难
跨分片 join 难
全局 ID 问题
路由规则复杂

一句总结¶

数据库系统面试不只是在问“会不会 SQL”，更在问你是否理解存储、并发、恢复和扩展之间的系统权衡。

3.2 面试可能追问的进阶点¶

追问 1：为什么数据库复制通常做不到绝对强一致？¶

因为复制链路存在：

网络延迟
异步传播
故障切换窗口

所以很多系统只能做到最终一致或近实时一致。

追问 2：分库分表后最麻烦的是什么？¶

高分回答通常不会只说“查询麻烦”，而会补：

跨分片事务
聚合统计
分页排序
热点 key / 热点用户
扩容数据迁移

追问 3：数据库慢，应该优先看什么？¶

执行计划
是否走索引 / 是否回表很多
锁等待
热点页竞争
Buffer Pool 命中率
IO 与 CPU 分布

4. NoSQL / Key-Value：这块是当前仓库最值得补的一个缺口¶

岗位要求明确写了 NoSQL、Key-value 存储原理。你现在仓库里有 Redis，但如果面试官问的是“KV 系统原理”，不能只答“Redis 基于内存所以快”。

4.1 基础知识：NoSQL 到底在解决什么问题？¶

NoSQL 并不是“不要 SQL”，而是在解决传统关系型数据库在某些场景下的限制：

超大规模数据
高写入吞吐
灵活 schema
分布式扩展
低延迟 key-based 访问

常见类别¶

Key-Value：Redis、RocksDB、LevelDB、etcd 底层存储思想
Document：MongoDB
Column Family：HBase、Cassandra
Graph：Neo4j

这份岗位里最重要的是 Key-Value 思维。

4.2 基础知识：Key-Value 存储原理的核心点¶

1）KV 系统最基本的访问模型¶

核心就是：

Put(key, value)
Get(key)
Delete(key)

很多时候它不强调复杂 join 和关系查询，而强调：

单 key 快速访问
范围扫描（某些系统）
高吞吐写入

2）哈希表型 KV 与 LSM 树型 KV 区别¶

哈希表型¶

典型特点：

单 key 查询快
内存型系统常见
不擅长有序范围扫描

LSM Tree 型¶

典型于 LevelDB / RocksDB：

写入先顺序追加 WAL / MemTable
内存表刷盘成 SSTable
后台做 Compaction
读取时需要查多个层级

LSM 树的核心优点是：

把随机写尽量转成顺序写
更适合 SSD / 日志型写路径

3）为什么 LSM 树适合高写入？¶

因为它避免频繁原地随机更新，而是：

先写日志
再写内存表
批量刷盘
后台合并

这种方式对磁盘尤其友好。

4）LSM 树的代价是什么？¶

读放大：查询可能要查 MemTable + 多层 SSTable
写放大：Compaction 会反复重写数据
空间放大：合并前可能有多份历史数据

5）Bloom Filter 为什么常和 KV 系统一起出现？¶

因为可以快速判断“某层 SSTable 里大概率没有这个 key”，减少无效磁盘查找。

一句总结¶

Key-Value 系统核心不是“能存 key-value 这么简单”，而是它如何组织写路径、读路径、日志、压缩和分层存储。

4.3 面试可能追问的进阶点¶

追问 1：B+ 树和 LSM Tree 怎么选？¶

B+ 树：读和范围查询更稳，更新是原地修改页
LSM Tree：写入吞吐更强，但要接受 compaction、读放大

这本质上是：

读优化结构
写优化结构

之间的取舍。

追问 2：分布式 KV 为什么会有热点问题？¶

因为 key 分布不均匀，某些热点 key / 热点前缀会让：

某个节点 CPU 打满
某个分片网络打满
某个存储层成为瓶颈

追问 3：如何做分片？¶

常见思路：

范围分片
哈希分片
一致性哈希

追问 4：一致性哈希解决什么？¶

核心解决节点增减时的数据迁移范围问题，尽量避免全量重分布。

追问 5：etcd / ZooKeeper 为什么也常被归到 KV 体系里？¶

因为它们也提供键值存储接口，但更偏：

元数据管理
配置中心
服务注册发现
强一致协调

也就是说，KV 系统不只是一种存储形态，还是很多分布式系统的基础组件。

5. 网络安全：这是很多后端候选人会被打空的一块¶

很多人会觉得“安全不是安全岗才问吗”，但这个 JD 明确提了网络安全。对后端来说，面试通常问的是基础安全意识，不是渗透测试。

5.1 基础知识：后端面试里最常见的安全知识点¶

1）TLS / HTTPS 到底解决什么问题？¶

核心是：

加密传输，防窃听
身份认证，确认你连的是正确服务
完整性校验，防篡改

2）对称加密和非对称加密区别？¶

对称加密快，适合大数据量传输
非对称加密适合密钥交换和身份认证

HTTPS 握手里通常是：

用非对称方式协商
之后用对称密钥传输数据

3）什么是数字证书？¶

数字证书本质上是在说：

某个公钥属于某个域名/实体
这个绑定关系由受信任 CA 背书

4）认证和授权区别？¶

认证（Authentication）：你是谁
授权（Authorization）：你能做什么

5）常见 Web 安全问题有哪些？¶

SQL 注入
XSS
CSRF
重放攻击
暴力破解
接口刷流量

虽然你偏 C++ / 后端，但这些基础必须知道。

6）什么是重放攻击？¶

攻击者截获一个合法请求后，在之后重复发送，伪造合法操作。

常见防护：

nonce
timestamp
签名
token 过期与一次性校验

7）为什么密码不能明文存？¶

因为数据库泄露时，明文密码会直接导致用户资产受损。

标准做法是：

加盐
哈希
使用专门密码算法（如 bcrypt / scrypt / Argon2）

一句总结¶

后端安全题最重要的不是会多少攻击技巧，而是理解数据在传输、鉴权、存储、调用链中的暴露面，并知道基本防护原则。

5.2 面试可能追问的进阶点¶

追问 1：为什么只靠 HTTPS 还不够？¶

因为 HTTPS 只解决链路安全，不自动解决：

权限越权
业务逻辑漏洞
重放
内部服务滥用
数据落库后的加密和脱敏

追问 2：JWT 一定安全吗？¶

不是。 JWT 只是令牌格式，不代表天然安全。安全性取决于：

签名算法
密钥管理
有效期
刷新机制
是否允许吊销

追问 3：接口防刷怎么做？¶

限流
人机校验
IP / 账号维度频控
行为风控
滑动窗口统计

追问 4：内部 RPC 需要安全控制吗？¶

需要。很多事故不是外部打进来，而是内部服务越权、配置泄露、凭证滥用导致的。

6. 分布式系统、负载均衡、容灾、高可用：这是和 JD 最贴的一条加分线¶

这块你仓库里有零散内容，但缺一篇统一视角。实际面试里，这一组很容易串起来追问。

6.1 基础知识：什么叫分布式系统？¶

分布式系统不是“服务拆成多个”这么简单，而是：

多个节点共同提供一个逻辑整体服务
节点之间通过网络协作
系统需要面对部分失败、延迟、不一致、扩容和运维问题

分布式和单机最大的区别¶

不是机器数量，而是：

网络不可靠
时钟不完全一致
节点可能部分失败
数据需要复制与协调

一句总结¶

单机系统主要在解决资源管理问题，分布式系统还要额外解决通信、不一致和局部故障问题。

6.2 负载均衡基础¶

什么是负载均衡？¶

把请求合理分发到多个后端节点，避免某个实例过载。

常见策略¶

轮询
加权轮询
最少连接
一致性哈希
基于响应时间/健康状态的调度

四层负载均衡 vs 七层负载均衡¶

四层：基于 IP/端口/TCP
七层：基于 HTTP 路径、Host、Header 等应用层信息

为什么要区分？¶

因为：

四层更轻、更通用
七层更灵活，但更复杂、开销更高

6.3 高可用基础¶

高可用在回答什么问题？¶

系统某个实例、某台机器、某个机房出问题时，还能不能继续提供服务。

常见手段¶

主从 / 多副本
健康检查
自动故障切换
限流降级
超时重试
隔离与熔断

为什么高可用不等于高一致性？¶

因为系统还能服务，不代表数据瞬时绝对一致。复制延迟、切主窗口、脑裂风险，都会带来一致性问题。

6.4 容灾基础¶

容灾和高可用区别¶

高可用：更偏局部节点/服务故障仍能扛住
容灾：更偏更大级别事故，如机房、可用区、地域故障

常见容灾级别¶

同机房冗余
跨机房双活 / 主备
跨地域灾备

面试里常见概念¶

RPO：最多允许丢多少数据
RTO：最多允许中断多久

这是容灾设计里特别典型的两个指标。

6.5 一致性与 CAP 的基础表达¶

CAP 怎么答更稳？¶

不要把它答成口诀题。更稳的说法是：

在发生网络分区时，系统无法同时完全满足强一致和可用性
不同系统会根据业务场景做取舍

最终一致性怎么理解？¶

不是“一会儿总会对”，而是：

允许短暂不一致
通过重试、补偿、异步同步等手段，最终收敛

一句总结¶

分布式系统的核心不是把系统拆开，而是如何在延迟、可用性、一致性和复杂性之间做工程取舍。

6.6 面试可能追问的进阶点¶

追问 1：重试为什么可能让系统更糟？¶

因为失败时重试会放大流量，尤其在下游已过载时，重试可能把局部问题扩大成雪崩。

追问 2：为什么要做隔离？¶

因为不同依赖、不同业务优先级不应该互相拖死。常见隔离包括：

线程池隔离
进程隔离
资源配额隔离

追问 3：双活为什么难？¶

因为双活不是“两个地方都部署一下”，而是要解决：

流量路由
多地写入冲突
数据同步延迟
故障切换一致性

追问 4：如何回答“设计一个高可用系统”？¶

可以按这个顺序：

单点在哪里
如何做冗余
如何检测故障
如何切流 / 切主
如何限制故障扩散
如何监控和演练

7. 可观测性、监控、稳定性：这块能把“会排障”和“会体系化治理”区分开¶

你现在仓库已有排障题，但还缺“可观测性体系”这一层。

7.1 基础知识：可观测性三件套¶

1）Metrics（指标）¶

常用于看：

QPS
RT
错误率
CPU/内存/磁盘/网络
线程池队列长度
连接池使用率

2）Logs（日志）¶

用来还原事件细节，适合：

错误上下文
参数记录
异常路径排查

3）Tracing（链路追踪）¶

适合跨服务调用链排查：

哪一跳慢
哪个下游超时
重试发生在哪

为什么三者不能互相替代？¶

指标适合快速发现趋势
日志适合看细节
链路适合看分布式调用路径

三者是互补关系。

7.2 面试高频基础点¶

1）什么是 SLI / SLO / SLA？¶

SLI：可量化指标，如成功率、延迟
SLO：内部目标，如 99.9% 成功率
SLA：对外承诺

2）为什么只监控平均值不够？¶

因为平均值会掩盖尾延迟。后端系统更应该看：

P95
P99
P999

3）告警为什么不能只靠阈值？¶

因为：

容易误报
容易漏报
不同业务高峰基线不同

更成熟的做法是结合：

趋势
同比/环比
业务指标
多指标联动

4）线上故障处理的标准思路是什么？¶

先止血
再定位
再修复
最后复盘

而不是一上来就在生产环境乱改。

一句总结¶

稳定性工程不只是“出问题会查”，更是平时就把监控、告警、限流、降级、容量评估这些机制搭好。

7.3 面试可能追问的进阶点¶

追问 1：为什么有监控还是会出事故？¶

因为可能：

监控点不对
告警阈值不合理
没有覆盖关键链路
没有人真正看懂指标

追问 2：复盘应该复什么？¶

不是只写“以后注意”，而是要复：

根因
触发条件
影响范围
为什么没提前发现
什么机制应该补上

追问 3：容量评估怎么做？¶

峰值流量估算
单实例容量基线
扩容阈值
冗余水位
压测验证

8. 云原生：岗位加分项里最容易低成本补强的一块¶

这类岗位写“对云原生相关技术有所了解”，一般不会要求你答到集群调度源码级别，但基础概念必须顺。

8.1 基础知识：云原生到底是什么？¶

云原生不是“用了云厂商”这么简单，通常指：

容器化部署
微服务化 / 服务化交付
弹性伸缩
自动化运维
基础设施即代码
更适合动态调度和快速交付

8.2 容器基础¶

容器和虚拟机区别¶

虚拟机隔离更完整，包含 Guest OS
容器共享宿主机内核，更轻量，启动更快

容器核心依赖什么？¶

Namespace：资源隔离
Cgroups：资源限制
Union FS / 镜像分层：构建与分发效率

为什么容器适合服务部署？¶

因为它提供了：

一致环境
更轻部署单元
更快启动与扩缩容

8.3 Kubernetes 基础¶

K8s 里最核心的几个对象¶

Pod：最小调度单元
Deployment：无状态应用部署与滚动升级
Service：服务发现与负载均衡入口
ConfigMap / Secret：配置与敏感信息管理
Ingress：HTTP/HTTPS 流量入口

健康检查为什么重要？¶

因为平台要知道：

实例是不是活着（liveness）
实例是不是准备好接流量（readiness）

为什么配置不能写死进镜像？¶

因为镜像应该尽量稳定、环境无关；配置应随部署环境变化而注入。

一句总结¶

云原生的核心不是把程序塞进 Docker，而是让服务以标准化、可调度、可弹性、可自动化治理的方式运行。

8.4 面试可能追问的进阶点¶

追问 1：为什么服务上了 K8s 不代表高可用就自动解决了？¶

因为 K8s 只提供调度与编排基础，业务层仍要自己处理：

无状态/有状态差异
数据一致性
下游依赖故障
配置错误
逻辑级雪崩

追问 2：为什么容器化后问题定位有时更难？¶

因为实例更短命、更动态，日志、网络、节点漂移、配置版本都更容易变化。

追问 3：什么是 Sidecar 思想？¶

把日志收集、代理、监控等通用能力从业务进程旁路抽出来，作为伴生容器运行。

9. 你可以怎么把这些知识点答成“更像这个岗位的人”？¶

如果面试官问得很散，你可以主动把回答往这个岗位画像上收：

这个岗位的核心画像¶

不只是会写功能
还要理解关键服务和基础设施
还要对稳定性、可用性、效率、协作有工程认知

所以回答时要多补这几个维度¶

这个机制解决什么问题
为什么这样设计
代价是什么
故障时怎么表现
线上怎么监控和验证

一个很好用的总括句¶

这类岗位不只要求把功能实现出来，还要求你理解服务在真实环境中如何运行、如何扩展、如何失败，以及失败后怎么定位和止损。

10. 一组针对这份 JD 的高频追问清单¶

下面这些问题，非常像这份 JD 对应岗位会问的：

软件工程¶

为什么代码评审是必要的？
单元测试、集成测试、端到端测试怎么分工？
为什么上线一定要有灰度和回滚？
重构和重写怎么选？

IPC / OS 工程化¶

共享内存为什么快？为什么难？
Unix Domain Socket 和 TCP Socket 什么时候分别用？
IPC 方案怎么按吞吐、复杂度、范围选型？

数据库系统¶

WAL 和 Buffer Pool 分别解决什么问题？
读写分离为什么会带来一致性问题？
分库分表后最麻烦的工程问题是什么？

NoSQL / KV¶

LSM Tree 为什么适合高写入？
Bloom Filter 在 KV 系统里做什么？
B+ 树和 LSM Tree 本质上在权衡什么？
分布式 KV 为什么容易遇到热点？

网络安全¶

HTTPS 除了加密还解决什么？
认证和授权有什么区别？
重放攻击怎么防？
接口防刷怎么做？

分布式 / 高可用¶

高可用和高一致性为什么不是一回事？
重试为什么可能放大故障？
四层和七层负载均衡怎么选？
容灾里的 RPO 和 RTO 分别是什么？
双活为什么难？

可观测性¶

指标、日志、链路追踪为什么缺一不可？
为什么只看平均 RT 不够？
事故复盘应该复哪些内容？

云原生¶

容器和虚拟机区别是什么？
Pod、Deployment、Service 分别是什么？
readiness 和 liveness 区别？
为什么上了 K8s 不等于系统天然高可用？

11. 最后的建议：如果你只补 3 条线，优先补哪 3 条？¶

如果你时间有限，我建议优先按下面顺序补：

第一优先级：分布式系统 / 高可用 / 负载均衡 / 容灾¶

这是这份 JD 最明显的加分方向，而且非常容易形成和你现有网络、数据库、缓存章节的串联。

第二优先级：NoSQL / Key-Value 原理¶

这是当前仓库最明显的结构性缺口。补上以后，你对“数据库系统”和“存储系统”的回答会更完整。

第三优先级：网络安全 + 可观测性 + 云原生基础¶

这三块单点不一定深问，但很容易作为“有没有工程视野”的加分题出现。

12. 一份更像面试现场的总结回答¶

如果按照这份岗位要求看，语言基础之外，后端候选人真正需要补齐的是四类能力：第一类是系统主干能力，包括操作系统、网络、数据库、缓存；第二类是分布式与高可用能力，包括负载均衡、容灾、一致性和故障治理；第三类是工程化能力，包括软件工程、可观测性、发布和回滚；第四类是现代基础设施能力，包括 NoSQL / Key-Value 原理、网络安全和云原生基础。前两类决定你能不能把服务做出来并跑稳，后两类决定你能不能把系统长期维护好并适应真实生产环境。

13. 对你当前仓库的补充建议（下一步）¶

这篇文档先作为“岗位定向查漏补缺总览”。如果继续往下深化，最值得单独拆成新章节的顺序建议是：

05_design_patterns_architecture/04_distributed_high_availability.md
04_database_cache/04_nosql_kv_storage_principles.md
05_design_patterns_architecture/05_observability_reliability_cloud_native.md
03_computer_network/04_network_security_basics.md

这样整套仓库会从“后端基础很全”，进一步升级成“更贴基础设施 / 核心服务岗位要求”的版本。