brpc 初始化必须调用 google::InitGoogleLogging 和 brpc::StartAllAsService，否则 RPC 调用会静默失败或崩溃；需正确配置连接池、健康检查、超时、负载均衡及异步处理，并启用 bthread 栈保护与内存泄漏检测。
brpc 初始化必须调用 google::InitGoogleLogging 和 brpc::StartAllAsService
不初始化日志和基础服务，后续所有 RPC 调用都会静默失败或崩溃，且错误信息极难定位。常见现象是 Channel::Init 返回 0（成功），但发请求时直接 core dump 或卡死在 CallMethod。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
google::InitGoogleLogging("your_service_name")必须在 main() 开头尽早调用，否则 brpc 内部日志模块未就绪，连 warning 都打不出来 -
brpc::StartAllAsService()要在创建Server前调用，它会初始化线程池、定时器、bthread 调度器等全局资源；漏掉会导致高并发下 bthread 创建失败，表现为brpc::start_background_thread返回 -1 - 不要在 fork 后再初始化——brpc 不支持 fork 后重复初始化，子进程需用
brpc::ForkedChildInit
Channel 配置不当导致连接复用失效或超时抖动
默认 Channel 使用短连接 + 无健康检查，线上压测时容易出现大量 Connection refused 或 EHOSTUNREACH，实际并非网络问题，而是连接池未复用或探测延迟过高。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须显式设置
ChannelOptions.connection_type = brpc::CONNECTION_TYPE_POOLED，否则每次调用都新建 TCP 连接 - 启用健康检查：
options.health_check_interval_s = 1，配合options.max_idle_time_ms = 60000及时剔除僵死连接 - 超时要分层设：全局
options.timeout_ms控制整个 RPC 生命周期；options.connect_timeout_ms单独设为 50–200ms，避免 DNS 解析慢拖垮整条链路 - 若后端是多实例（如 etcd 发现的 service），务必开启
options.load_balancer_name = "rr"或"citus"，否则默认轮询策略不生效
Server 处理函数里不能阻塞或长耗时，必须用 bthread 或异步回调
直接在 Done 回调或服务方法里 sleep、同步 DB 查询、调用阻塞 IO，会导致 worker 线程被占满，吞吐量断崖下跌，监控显示 server_bthread_count 持续高位但 QPS 上不去。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有可能超过 10ms 的操作（如 MySQL 查询、Redis
GET、文件读写）必须用异步 SDK 或包裹进bthread_start_background - 不要在
Controller::Failed()后继续执行业务逻辑——失败路径也要快速返回，否则影响线程复用 - 若必须同步调用第三方库（如 legacy C API），用
brpc::BackgroundClosure包装，并设max_concurrency限流，防止线程池耗尽 - 注意
bvar统计变量（如latency_us）只在主线程更新，别在 bthread 里直接 ++，要用bvar::Adder等线程安全类型
生产环境必须开启 bthread stack guard 和内存泄漏检测
brpc 默认 bthread 栈大小为 1MB，野指针或递归过深极易越界覆盖相邻栈帧，表现为偶发 crash 且堆栈不可读；长期运行的服务还容易因 new / malloc 不配对导致 RSS 持续上涨。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 启动时加参数
-bthread_stack_size=2097152（2MB）并启用保护：-enable_bthread_stack_guard=true，越界立即 abort 并打印上下文 - 每日凌晨触发一次
brpc::MemoryStat报告，重点关注malloced_bytes和in_use_bytes差值是否持续扩大 - 用
brpc::ResourcePool管理高频小对象（如 request context），避免频繁 new/delete 引发 lock contention - 上线前跑
valgrind --tool=memcheck --leak-check=full，特别检查Channel、Server析构是否完整释放了内部连接池和 timer
brpc 的高吞吐不是靠配置开关打开的，而是每层资源（bthread、fd、内存块、连接池）都得对齐业务毛刺特征；最常被忽略的是健康检查间隔与后端扩缩容节奏不匹配，导致流量打到已下线节点上，这种问题在灰度阶段几乎无法复现。
