Go context 超时控制:给下游调用装上保险丝
调用第三方 API 不设超时,一个慢下游能拖垮整个服务的 goroutine 池。用 context.WithTimeout 贯穿 HTTP/DB/RPC 调用链,超时自动取消并释放资源,是高可用服务的基本功。
后端开发 · Linux 运维 · 网络协议 · 数据库 · 容器与自动化,偶尔写点折腾笔记。
调用第三方 API 不设超时,一个慢下游能拖垮整个服务的 goroutine 池。用 context.WithTimeout 贯穿 HTTP/DB/RPC 调用链,超时自动取消并释放资源,是高可用服务的基本功。
把域名转发到本机端口的服务,proxy_pass 后面要不要加斜杠、Host/X-Forwarded-For 怎么传、WebSocket 要加 Upgrade 头,这几个细节最容易 404 或 502。给一份能直接抄的模板。
没有绝对优劣,只有场景匹配。需要复杂查询/JSONB/地理信息偏向 PG;生态成熟、运维资料多、团队熟悉偏向 MySQL。小团队更该选「自己最熟、出问题能搜到答案」的那个。
cron 简单直接但日志和错误处理弱;systemd timer 能依赖服务、随机延迟、missed 后补跑、journalctl 统一看日志。对跑在 systemd 体系里的维护脚本,timer 往往更省心。
TCP 可靠但有队头阻塞,三次握手+重传带来延迟;UDP 不保证交付但快。DNS、游戏、实时音视频多用 UDP;而很多代理协议会在 UDP 之上自己实现可靠传输或 relay UDP over TCP。
当缓存用就配 allkeys-lru,内存满了自动淘汰最久没用的 key;当存储用就别轻易淘汰,用 noeviction 让写入报错暴露问题。配错策略会出现「热点 key 莫名其妙消失」。