Linux

问题不在快，而在失控 很多 io_uring 服务在压测里吞吐漂亮，线上却出现尾延迟飙升。根因通常是提交队列无限推进，完成队列消费跟不上。 背压触发条件 SQ ring 使用率超过 80%。 CQ backlog 持续增长。 业务层处理耗时超过 IO 完成速率。 建议的三层背压 提交层：限制 in-flight 请求上限。 协程层：队列超阈值时暂停新任务调度。 入口层：对上游返回 retry-after 或降级响应。 伪代码 if (inflight > max_inflight || cq_backlog > cq_limit) { pause_accept(); shed_low_priority(); } while (io_uring_peek_cqe(&ring, &cqe) == 0) { handle_cqe(cqe); io_uring_cqe_seen(&ring, cqe); } 关键指标 submit_to_complete_latency cq_backlog inflight shed_count 小结 io_uring 的上限很高，但系统稳定性的上限由背压机制决定。先把“慢下来也不爆炸”做对，再追求“快”。

先说结论 多数业务服务里，epoll 依然是稳妥选择。io_uring 在某些高并发 IO 场景能更快，但复杂度也更高。 epoll 的优势 生态成熟，排障资料多 编程模型稳定 与现有网络库兼容性好 对于大部分 API 服务，epoll 足够用。 io_uring 的价值点 减少系统调用次数 提升批量提交与完成处理效率 在特定负载下降低延迟 但它要求你理解提交队列、完成队列、内核版本差异等细节。 选型建议 先压测当前 epoll 方案，定位真实瓶颈 若瓶颈明确在 IO 提交/完成路径，再评估 io_uring 预留回退方案，避免一次性全量切换 团队视角 技术选型不只看 benchmark，还要看： 团队掌握程度 线上问题可定位性 长期维护成本 小结 新能力值得关注，但架构决策应以稳定收益为中心。对大多数团队来说，逐步引入比激进替换更现实。

背景 裸重启进程很简单，但线上会带来短暂不可用。优雅重启的目标是： 停止接收新连接 等待在途请求处理完 平滑切换到新进程 Go 侧的退出处理 srv := &http.Server{Addr: ":8080", Handler: mux} go func() { if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatal(err) } }() sigCh := make(chan os.Signal, 1) signal.Notify(sigCh, syscall.SIGTERM, syscall.SIGINT) <-sigCh ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second) defer cancel() _ = srv.Shutdown(ctx) Shutdown 会先关闭监听，再等待连接收尾。 systemd 关键配置 [Service] ExecStart=/opt/app/server Restart=always RestartSec=2 TimeoutStopSec=20 KillSignal=SIGTERM KillSignal=SIGTERM 给应用机会走优雅退出逻辑 TimeoutStopSec 要大于应用 Shutdown 超时 发布建议 先在网关层摘流量 再重启实例 观察错误率与连接数回落 小结 优雅重启不是一个函数调用，而是应用与进程管理器协同设计。把退出路径做好，发布风险会明显下降。