超时控制的关键是每个rpc独立使用wait_until(deadline)并基于steady_clock计算截止时间，grpc需每次preparecall后设set_deadline()，brpc需禁用重试且controller不复用，同时限制并发数≤8。
用 std::future + std::async 并发发起 RPC，但别直接 wait()
超时控制的关键不是“等多久”，而是“在截止时间前主动放弃”。std::async 返回的 std::future 支持 wait_for() 和 wait_until()，这才是真正可控的入口。直接调用 get() 或无参 wait() 会无限阻塞，和单次调用没区别。
常见错误是：先发所有请求，再统一 wait_for(1s) —— 这会导致最后一批请求的实际等待时间远小于 1s（因为前面已耗时），整体 deadline 失效。
- 每个
std::future必须单独用wait_until(deadline)判断是否就绪 - deadline 应基于系统时钟（如
std::chrono::steady_clock::now() + timeout），不能用相对时间累加 - RPC 客户端本身需支持异步发起（如 gRPC 的
AsyncUnaryCall、brpc 的CallMethod配合 callback），否则std::async只是把阻塞转移到线程里，没解决本质问题
gRPC c++ 中 WaitForConnected 和 Deadline 不是一回事
很多人以为设置 channel 的 WaitForConnected 就能控制整个调用超时，其实它只管连接建立阶段；真正的 RPC 超时必须在每次 PrepareCall 后显式设 set_deadline()。
典型坑：用同一个 Channel 发起多个 RPC，但只在第一次调用前 WaitForConnected，后续调用若 channel 断连，会卡在底层重连逻辑里，deadline 不生效。
立即学习“C++免费学习笔记（深入）”；
- 每次
PrepareCall后都要调用request->set_deadline(deadline)，其中deadline是gpr_timespec类型，需用gpr_time_add(gpr_now(GPR_CLOCK_MONOTONIC), timeout)构造 - 批量调用时，每个 RPC 的
deadline必须独立计算（从当前时刻起算），不能复用同一个gpr_timespec变量 - 如果用同步 stub，
set_deadline必须在PrepareCall之后、StartCall之前；异步 stub 则在Finish前检查status.ok()和status.error_code() == GRPC_STATUS_DEADLINE_EXCEEDED
并发数控制不当会让超时彻底失效
不加限制地用 std::async(std::launch::async, ...) 启动几十个 RPC，线程调度、网络缓冲、服务端限流都会让实际响应时间剧烈抖动。你设了 500ms 超时，但第 20 个请求可能因排队多等了 800ms，而你还在等它返回。
这不是代码写错了，是资源模型没对齐。RPC 批量调用的本质是「有限并发 + 硬 deadline」，不是「尽可能快发完」。
- 用固定大小的线程池（如
boost::asio::thread_pool）替代裸std::async，并发数建议 ≤ 4～8，具体看服务端 QPS 和平均延迟 - 发请求前检查当前活跃请求数，超限时用
std::this_thread::sleep_for()短暂退让，比盲目堆积更可靠 - 对已超时的 future，调用
future.wait_for(0s)确认状态后立即丢弃，不要等它自己结束——有些 RPC 库的异步回调在线程池里滞留很久
brpc 的 Controller::set_timeout_ms() 更适合批量场景
相比 gRPC 的 per-RPC deadline，brpc 的 Controller 设计更贴近批量需求：timeout 是从 CallMethod 开始计时，自动覆盖序列化、网络发送、接收、反序列化全过程，且支持毫秒级精度和自动重试控制。
但注意：brpc 默认开启失败重试，一次超时可能触发多次重发，导致实际耗时翻倍。批量调用中这往往是不可接受的。
- 必须显式调用
controller->set_max_retry(0)关闭重试 - 并发调用时，每个
Controller实例必须独立创建，不能复用——复用会导致 timeout 和上下文污染 - 用
brpc::Channel的Init设置连接级 timeout（如connection_timeout_ms），避免 DNS 解析或 TCP 握手拖慢整体启动
超时不是加个参数就能跑通的事。真正难的是 deadline 在客户端线程、网络栈、服务端队列、序列化开销之间如何传导和衰减。多数问题出在“以为设了就生效”，而没验证每个环节是否真受控。