brpc是百度开源的高性能RPC框架，专为高并发低延迟设计，需C++17、禁RTTI/exceptions，服务注册须优化etcd lease，单机高QPS需拆分bthread组，流控须动态自适应与客户端备选请求协同。
brpc 是百度开源的工业级 RPC 框架（不是 gRPC），专为高并发、低延迟、海量请求场景设计，在百度内部支撑日均千亿级调用。它和 gRPC 在定位上有重叠，但技术路线完全不同：不依赖 protoc + HTTP/2，而是基于自研的 baidu-rpc 协议、支持多种序列化（protobuf / json / sofa-pb）、内置服务发现与负载均衡，且 C++ 原生深度优化。
如果你正考虑用 brpc 搭建百亿级请求的微服务集群，先明确一点：brpc 本身不等于“集群”——它只是高性能通信底座；百亿级支撑能力取决于你如何组织服务拓扑、治理策略、线程模型和资源隔离，而非框架开箱即用。
brpc 编译链接必须显式启用 C++17 且禁用 RTTI
很多团队在首次集成时卡在链接失败或运行时崩溃，根源常是编译器标志不匹配。
-
brpc默认启用-fno-rtti -fno-exceptions，若你的业务代码用了dynamic_cast或try/catch，必须统一关闭 RTTI/exceptions，否则std::bad_cast等异常无法捕获 - CMake 中需显式设置：
set(CMAKE_CXX_STANDARD 17)，且add_compile_options(-fno-rtti -fno-exceptions) - 链接顺序敏感：
target_link_libraries(your_service brpc protobuf)中brpc必须在protobuf之前，否则符号解析失败
服务注册必须绕过 etcd/v3 的默认 lease 机制
brpc 自带 NamingService 接口，但直接连 etcd v3 时，默认 10 秒 lease 续约在百亿请求压测下会触发大量 watch event 冲突，导致服务列表抖动。
立即学习“C++免费学习笔记（深入）”；
- 改用长 lease（如 300 秒）+ 主动心跳上报，避免依赖 etcd 的自动过期
- 在
brpc::ChannelOptions中设connection_type = "pooled"，并启用timeout_ms = 500防止阻塞在 DNS 或服务发现上 - 生产环境建议部署独立的
brpc-naming-server（非 etcd），它用内存哈希表+定期快照同步，吞吐比 etcd 高 3–5 倍
单机 QPS 过 50 万必须拆分 bthread 执行队列
brpc 默认所有 RPC 调用共享一个全局 bthread 调度器，当单机承载超大流量时，调度锁成为瓶颈，bthread_id_lock 争用率飙升。
- 按业务域划分
bthread_group：例如「支付回调」、「风控校验」、「日志上报」各用独立调度组 - 服务端处理逻辑中，用
brpc::StartBackgroundTask()投递到指定 group，避免阻塞主线程池 - 客户端发起调用前，通过
brpc::Controller::set_timeout_ms()强制设 deadline，防止慢请求拖垮整个队列
流控不能只靠 server-side max_concurrency
百亿级集群里，单纯在 ServerOptions.max_concurrency 限流会引发雪崩：上游未感知限流信号，持续重试，放大下游压力。
- 必须开启
brpc::AdaptiveMaxConcurrency，它基于当前 CPU 使用率 + 延迟 P99 动态调整并发上限 - 客户端侧配置
ChannelOptions.fail_limit = 3+backup_request_ms = 50，对超时请求自动发备选节点 - 关键接口强制添加
brpc::RateLimiter实例，使用 token bucket（非 leaky bucket），burst 容量设为平均 QPS × 2，防脉冲流量打穿
真正难的不是把 brpc 跑起来，而是让每个服务实例在流量洪峰下保持确定性延迟——这要求你放弃“通用配置”，对每个接口的线程模型、bthread 栈大小、IO 超时、熔断阈值做精细化建模。没有银弹，只有层层压测后的参数刻度。
