MySQL 深分页越来越慢：从 OFFSET 扫描到游标分页的改造实践
## 适用场景 本文适用于按时间倒序展示订单、流水、审计日志或消息列表的接口。典型特征是：第一页很快，翻到几千页后响应时间明显上升；数据库 CPU 和磁盘读取随页码增长；接口仍使用 `LIMIT offset, size`。 示例使用 MySQL 8.0，表结构如下： ```sql CREATE TABLE or
Today
持续记录，慢慢变好
技术笔记、项目复盘、阅读摘录和问题清单。
Kubernetes 节点维护时 Pod 驱逐卡住：PDB 预算与安全排空实践
## 适用场景 集群管理员准备升级内核、更换节点或缩容节点池，执行 `kubectl drain` 后命令长时间重试，并反复出现 `Cannot evict pod as it would violate the pod's disruption budget`。业务当前未必已经中断，但维护窗口正在被耗尽。 本文适
Python 并发子任务失败后仍在运行：TaskGroup 取消与资源回收实践
## 适用场景 一个聚合接口同时读取用户资料与订单摘要，只有两项都成功才返回页面。某个依赖提前失败后，其他查询的结果已经没有用途，却仍占用连接和并发名额。本篇用纯标准库示例讨论这种“共同成功、共同结束”的请求边界。 示例需要 Python 3.11 或以上版本，本文在 Python 3.14 环境执行验证。演示使用
Webhook 验签通过仍被重复扣款：HMAC 签名与重放攻击防护实践
## 适用场景 支付、订单、代码托管或消息平台通过 Webhook 主动回调业务系统。接口已经校验 HMAC 签名，但偶尔仍出现同一事件被重复执行，甚至攻击者截获一条合法请求后，可以在数小时后原样重放。 本文以 Python 3.11、FastAPI 和 Redis 为例，实现一套可直接落地的接收端：对原始请求体进
PostgreSQL 连接池耗尽：从 idle in transaction 到事务边界治理
## 适用场景 应用运行一段时间后，新请求开始等待数据库连接，接口 P99 持续升高，最终出现连接池获取超时或 PostgreSQL `too many connections`。数据库 CPU、磁盘 I/O 和慢 SQL 指标却不高，重启应用后又能短暂恢复。 这类现象经常不是“连接池太小”，而是业务代码开启事务后
FastAPI 接口并发升高后全站变慢：阻塞调用卡住事件循环的定位与治理
## 适用场景 FastAPI 服务平时响应正常，但只要某个文件处理、旧版 SDK 调用或报表计算接口并发升高，健康检查、登录和其他无关接口也一起变慢。CPU、内存和数据库连接数未必异常，扩容 Uvicorn worker 后只能暂时缓解。 这类问题常见于 `async def` 路由中直接调用同步阻塞函数。本文给
Nginx 大文件上传返回 413：从限制链路定位到安全放行的排查实践
## 适用场景 业务通过 Nginx 上传图片、安装包、备份文件或导入数据时，小文件正常，大文件刚提交便收到 `413 Request Entity Too Large`。应用日志没有请求记录，客户端通常只看到一个 Nginx 错误页。 本文以“上传 80 MB 压缩包失败、10 MB 图片正常”为例，说明怎样确认
MySQL 主从复制延迟持续扩大：从现场取证到并行复制治理的排查实践
## 适用场景 本文适用于 MySQL 8.0 或已启用 GTID 的 MySQL 5.7 主从/主备架构：监控显示 `Seconds_Behind_Source` 持续增长，报表、读库或故障切换的恢复点开始不可接受。目标是先确认延迟真实原因，再在不破坏复制一致性的前提下恢复追平。 ## 现象描述 一次订单促销后
Nginx 反向代理后客户端 IP 全变内网地址：从 realip 配置到防伪造的排查实践
## 适用场景 业务服务部署在负载均衡、CDN、Kubernetes Ingress 或四层代理之后。应用日志中的 `remote_addr` 全是代理的内网地址，限流、风控和审计都无法识别真实访问者；更危险的是，直接信任请求携带的 `X-Forwarded-For`，会让攻击者伪造来源 IP 绕过白名单。 本文以
Linux 时间漂移导致 JWT 校验失败与 TLS 握手异常：从证据采集到 chrony 治理
## 适用场景 适用于运行在 Linux 虚拟机、物理机或容器节点上的 Web 服务。业务表现为同一版本在部分机器上间歇出现登录失效、JWT `token is not active` / `token expired`、HTTPS 握手失败或调用云 API 返回签名过期；重试、重启应用有时短暂恢复，但问题会再次出现