FWDD.NET · 技术文档站

范文多多

聚焦后端工程实践：语言教程、功能实现、面试题与运维脚本。每篇都从真实踩坑场景出发，给出可直接复用的代码与取舍依据。

方向
全部语言教程功能实现面试题运维工具脚本AI 实践
分类
Go 教程Python 教程JavaScript 教程TypeScript 教程Rust 教程PHP 教程Java 教程限流与容错数据处理缓存设计数据库优化Go 面试题数据库面试题网络面试题综合面试题Java 面试题AI 面试题Shell 脚本进程管理定时任务容器运维监控告警

容器日志体积失控：json-file 驱动的 max-size 与 max-file 配置脚本

Docker 默认使用 json-file 日志驱动，而且默认不做任何轮转。一个打印量稍大的服务，跑上两周就能把宿主机的 /var/lib/docker 撑满，然后你会在 docker ps 里看到容器状态变成 Up 但业务全挂，或者在 dmesg 里看到 No space left on device。更麻烦的是，日志文件被删掉之后磁盘空间并不一定释放——

多主机时间同步与漂移巡检：一个 Ansible Playbook 全覆盖

集群里最容易被忽略、又最容易引发"玄学故障"的基础项，就是时间。NTP 漂移几百毫秒，可能让 JWT 校验随机失败、让 Kafka 消费者位点错乱、让分布式锁提前释放、让 ELK 里的日志时间线对不上。而这类问题往往不具备可复现性，排查成本极高。 手工逐台 ssh 上去看 chronyc tracking 的运维方式，在几十台机器规模下就完全不可接受了。本文

服务健康检查脚本：curl 超时与状态码分级判定

用 curl 做服务健康检查几乎是所有运维脚本的标配，但大多数实现只写了一行 curl -s -o /dev/null -w "%{http_code}"，然后判断是否等于 200。这种写法在真实生产环境里会暴露三个问题：没有设置超时导致脚本被挂死、把「服务不可达」和「服务返回业务错误」混为一谈、无法区分 HTTP 状态码中哪些属于自身异常、哪些属于上游依赖

MVCC 中 ReadView 的可见性判断规则详解（附面试答题模板）

面试里问 MVCC，八成的候选人能说出「快照读」「undo log」「ReadView」，但一旦追问「ReadView 里到底存了什么、四个字段怎么比、为什么 RR 和 RC 结果不一样」，回答就开始含糊。这篇把 InnoDB 的 ReadView 拆到字段级别，用可复现的 SQL 走一遍可见性判断的完整分支，最后给出一份面试可直接背的答题骨架，以及几个高频