bRPC 完整实战指南高性能 C RPC 框架如何扛住长尾延迟【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpcbRPCbetter RPC是一个工业级的 C RPC 框架源自百度搜索、存储、机器学习、广告推荐等场景在百度内部以 baidu-rpc 之名运行着 100 万个以上实例和上千种服务。它把分布式系统里一堆琐碎但棘手的问题打包解决数据序列化与前后兼容、连接的建立复用与断线重试、从命名服务发现节点、超时与重试策略。值得投入的原因是它不满足于单机吞吐高而是把设计重心放在一个更现实的指标上——当 1% 的请求变慢时剩下 99% 的请求能不能不被拖累。一、快在哪QPS 数字之外看它怎么消化长尾请求很多 RPC 框架的基准测试只比 echo 吞吐这种测试里 brpc 反而显得吃亏它每个请求都会付出一次线程跳转单次跳转代价约 320 微秒还伴随独立的 L1/L2 cache 失效变量访问从纳秒级被拉长到微秒级。brpc 在 2015 年重做了一整套基准测试见 docs/cn/benchmark.md规则是请求不等长混入 1% 耗时 5 毫秒的长尾请求有 server 内嵌 client 访问下游的多级链路有单 client 打多 server、多 client 打多 server 的场景。在这种更贴近生产环境的设定下结果差异明显长尾隔离固定 QPS 下 brpc 的延迟 CDF 曲线几乎没有被 5ms 长尾干扰而对比实现中有的框架 30% 的普通请求被长尾严重拖慢有的甚至出现一批请求直接超时。全并发收包不同连接的读取完全并发同一连接内不同消息的解析也并发某个超大 protobuf 消息的解析不会波及同一客户端或其他客户端的消息。wait-free 写出多个线程同时向同一个 fd 写入时第一个线程原地写其余线程以无等待方式托付写请求实测 1 秒内对同一 fd 写入 500 万个 16 字节消息。锁极少创建 bthread、设置定时器、按回复定位 RPC 上下文、累加性能计数器都是高并发路径QPS 超过 50 万时contention profiler 里几乎看不到框架自身造成的锁竞争。图1固定 QPS、混入 1% 长尾请求时的延迟 CDF 对比brpc 曲线几乎不受干扰二、一张图看懂架构请求从 Channel 到 Service 的完整链路brpc 的接口面很小核心用户类只有三个Server服务端、Channel客户端、Controller参数集合分别对应服务端、客户端和请求上下文不需要理解什么 Manager、Context 的组合关系。图2bRPC 请求链路Client 侧 Channel/LB 选节点后经由 Socket 收发Server 侧由 Event Dispatcher 分发到 Parse 和 Process把这张图拆成两侧看Client 侧Channel 持有命名服务NamingService和负载均衡器LB每次请求先选节点再落到 Socket 上响应回来后经过 Parse、Process Response多个 Channel 之间通过 bthread swap 相互切换互不阻塞。Server 侧Acceptor 接单后交给 Event Dispatcher请求按fd 之间并发 fd 内部并发两级并行推进最终路由到具体的 Service。图中不同颜色代表不同线程可以直观看到收包、解析、处理在不同线程间流动。命名服务用字符串就能表达写在配置文件里即可bns://节点名、file://列表文件、list://addr1,addr2、http://域名走 DNS。想支持 zk、etcd 等新后端实现一个新的 NamingService 后在 src/brpc/global.cpp 里注册即可。三、关键设计拆解三个为什么3.1 线程模型为什么是 M:N 的 bthread而不是协程或裸线程bthread 是 M:N 线程库M 个 bthread 映射到 N 个 pthread workerM 远大于 N创建耗时数百纳秒。官方 FAQ 直接回答了它是不是协程——不是详见 docs/cn/bthread.md。不用 N:1 协程协程切换虽快100200ns但一个协程阻塞会卡死整个 event loop 上的所有请求。百度搜索链路里几十人协作开发一个慢函数或一次卡顿的下游访问就会放大成大规模超时。不用纯 1:1 线程池每个请求跑在独立 bthread 中请求结束线程即销毁线程数天然随负载自动伸缩不用手动调节 worker 数量同时 M 个 bthread 共享少量 pthreadthread-local cache如 tcmalloc的效果不被稀释。隔离靠两个机制work stealing 调度让空闲 worker 从别的 worker 那里偷任务butexblocking thread synchronization让 bthread 和 pthread 可以互相等待唤醒。一个 bthread 因 bthread API 阻塞就让出 worker因系统调用阻塞时它名下待运行的 bthread 会被其他 worker 偷走执行。图3bthread worker 使用率的 bvar 监控曲线负载上来后各 worker 使用率同步抬升3.2 连接与并发为什么没有IO 线程和业务线程之分传统实现把 fd 静态散列到若干 IO 线程一个 IO 线程解析慢消息时它名下的其他连接全部排队。brpc 的做法是 Event Dispatcher 全并发读写不存在这个隔离带。连接方式上提供三档单连接、连接池、短连接。官方基准给出的结论很明确单连接下 brpc 吞吐超过 800MB/s足以打满万兆网卡且写出过程是 wait-free 的CPU 消耗约为多连接模式的一半——真实系统优先用单连接大包场景内核单连接写入成为瓶颈时连接池模式可以达到测试中的最高 2.3GB/s。3.3 服务治理命名、负载、熔断为什么做成可插拔的三件套这三层各管一件事且都能按字符串注册扩展命名服务负责节点列表从哪来支持定期拉取bns默认 5 秒间隔、文件监听file://、内嵌列表list://、DNShttp://。负载均衡负责每次挑谁内置 round-robin、randomized、consistent-hashingmurmurhash3 或 md5、locality-aware 四种见 docs/cn/consistent_hashing.md 与 docs/cn/lalb.md。熔断与健康检查负责坏的什么时候踢。默认策略常开且不可关闭节点返回 ECONNREFUSED、ENETUNREACH、EHOSTUNREACH、EINVAL或连续三次连接超时即被熔断被熔断的连接会启动一个动态创建的 bthread 做健康检查连上后复活重新参与 LB。另外可选基于出错率的激进熔断enable_circuit_breaker用 EMA 平滑延迟维护长/短两个出错窗口适合TCP 能连上但业务线程全卡死这类故障节点。四、实战避坑清单问题 → 做法 → 收益问题做法收益自定义超时后故障节点永远触发不了熔断保证timeout_ms connect_timeout_ms否则 rpc 超时先于连接超时触发连续三次连接超时的判定永远不成立故障节点能被正常剔除避免流量持续打到坏节点大量 bthread 调用阻塞系统调用worker 被占满调大bthread_concurrency或在 server 端限制最大并发保留足够的 worker 处理网络收发在锁内发起 RPC极端情况下全部 worker 阻塞在同一把 pthread mutex 上养成锁内不做 RPC的习惯需要兜底时启用 pthread 模式避免 unlock 依赖的 RPC 回调没有线程执行彻底死锁线上服务状态是黑盒靠打日志排查用内置 HTTP 服务查看/connections连接与熔断数据含 nBreak、RecentErr 字段、/varsbvar 指标、rpcz以及 CPU、Heap、Contention 三个 profiler不重启、不打日志即可定位热点、内存分配和锁竞争性能测试结论与生产表现对不上测试请求加入长尾覆盖多级 server 与多 client 场景参考 benchmark 的测试设计测试暴露的是真实瓶颈而不是 echo 吞吐图4通过浏览器/curl 查看 server 内部状态连接数、指标、profiler 都从这里进入五、上手入口克隆仓库即可开始git clone https://gitcode.com/GitHub_Trending/brpc/brpc建议按这个顺序读docs/cn/getting_started.md 走通第一个 echo 服务docs/cn/overview.md 理解 RPC 抽象与 brpc 的定位docs/cn/bthread.md 和 docs/cn/io.md 补上线程与网络层的细节。框架层面它已经把长尾隔离、并发写出、可观测性做成了默认行为接下来值得关注的方向是 streaming RPC、RDMA 支持以及和 braft 组合搭建高可用分布式系统——这些在 docs 目录里都有对应的专题文档。【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 bRPC 完整实战指南：高性能 C++ RPC 框架如何扛住长尾延迟
bRPC 完整实战指南高性能 C RPC 框架如何扛住长尾延迟【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpcbRPCbetter RPC是一个工业级的 C RPC 框架源自百度搜索、存储、机器学习、广告推荐等场景在百度内部以 baidu-rpc 之名运行着 100 万个以上实例和上千种服务。它把分布式系统里一堆琐碎但棘手的问题打包解决数据序列化与前后兼容、连接的建立复用与断线重试、从命名服务发现节点、超时与重试策略。值得投入的原因是它不满足于单机吞吐高而是把设计重心放在一个更现实的指标上——当 1% 的请求变慢时剩下 99% 的请求能不能不被拖累。一、快在哪QPS 数字之外看它怎么消化长尾请求很多 RPC 框架的基准测试只比 echo 吞吐这种测试里 brpc 反而显得吃亏它每个请求都会付出一次线程跳转单次跳转代价约 320 微秒还伴随独立的 L1/L2 cache 失效变量访问从纳秒级被拉长到微秒级。brpc 在 2015 年重做了一整套基准测试见 docs/cn/benchmark.md规则是请求不等长混入 1% 耗时 5 毫秒的长尾请求有 server 内嵌 client 访问下游的多级链路有单 client 打多 server、多 client 打多 server 的场景。在这种更贴近生产环境的设定下结果差异明显长尾隔离固定 QPS 下 brpc 的延迟 CDF 曲线几乎没有被 5ms 长尾干扰而对比实现中有的框架 30% 的普通请求被长尾严重拖慢有的甚至出现一批请求直接超时。全并发收包不同连接的读取完全并发同一连接内不同消息的解析也并发某个超大 protobuf 消息的解析不会波及同一客户端或其他客户端的消息。wait-free 写出多个线程同时向同一个 fd 写入时第一个线程原地写其余线程以无等待方式托付写请求实测 1 秒内对同一 fd 写入 500 万个 16 字节消息。锁极少创建 bthread、设置定时器、按回复定位 RPC 上下文、累加性能计数器都是高并发路径QPS 超过 50 万时contention profiler 里几乎看不到框架自身造成的锁竞争。图1固定 QPS、混入 1% 长尾请求时的延迟 CDF 对比brpc 曲线几乎不受干扰二、一张图看懂架构请求从 Channel 到 Service 的完整链路brpc 的接口面很小核心用户类只有三个Server服务端、Channel客户端、Controller参数集合分别对应服务端、客户端和请求上下文不需要理解什么 Manager、Context 的组合关系。图2bRPC 请求链路Client 侧 Channel/LB 选节点后经由 Socket 收发Server 侧由 Event Dispatcher 分发到 Parse 和 Process把这张图拆成两侧看Client 侧Channel 持有命名服务NamingService和负载均衡器LB每次请求先选节点再落到 Socket 上响应回来后经过 Parse、Process Response多个 Channel 之间通过 bthread swap 相互切换互不阻塞。Server 侧Acceptor 接单后交给 Event Dispatcher请求按fd 之间并发 fd 内部并发两级并行推进最终路由到具体的 Service。图中不同颜色代表不同线程可以直观看到收包、解析、处理在不同线程间流动。命名服务用字符串就能表达写在配置文件里即可bns://节点名、file://列表文件、list://addr1,addr2、http://域名走 DNS。想支持 zk、etcd 等新后端实现一个新的 NamingService 后在 src/brpc/global.cpp 里注册即可。三、关键设计拆解三个为什么3.1 线程模型为什么是 M:N 的 bthread而不是协程或裸线程bthread 是 M:N 线程库M 个 bthread 映射到 N 个 pthread workerM 远大于 N创建耗时数百纳秒。官方 FAQ 直接回答了它是不是协程——不是详见 docs/cn/bthread.md。不用 N:1 协程协程切换虽快100200ns但一个协程阻塞会卡死整个 event loop 上的所有请求。百度搜索链路里几十人协作开发一个慢函数或一次卡顿的下游访问就会放大成大规模超时。不用纯 1:1 线程池每个请求跑在独立 bthread 中请求结束线程即销毁线程数天然随负载自动伸缩不用手动调节 worker 数量同时 M 个 bthread 共享少量 pthreadthread-local cache如 tcmalloc的效果不被稀释。隔离靠两个机制work stealing 调度让空闲 worker 从别的 worker 那里偷任务butexblocking thread synchronization让 bthread 和 pthread 可以互相等待唤醒。一个 bthread 因 bthread API 阻塞就让出 worker因系统调用阻塞时它名下待运行的 bthread 会被其他 worker 偷走执行。图3bthread worker 使用率的 bvar 监控曲线负载上来后各 worker 使用率同步抬升3.2 连接与并发为什么没有IO 线程和业务线程之分传统实现把 fd 静态散列到若干 IO 线程一个 IO 线程解析慢消息时它名下的其他连接全部排队。brpc 的做法是 Event Dispatcher 全并发读写不存在这个隔离带。连接方式上提供三档单连接、连接池、短连接。官方基准给出的结论很明确单连接下 brpc 吞吐超过 800MB/s足以打满万兆网卡且写出过程是 wait-free 的CPU 消耗约为多连接模式的一半——真实系统优先用单连接大包场景内核单连接写入成为瓶颈时连接池模式可以达到测试中的最高 2.3GB/s。3.3 服务治理命名、负载、熔断为什么做成可插拔的三件套这三层各管一件事且都能按字符串注册扩展命名服务负责节点列表从哪来支持定期拉取bns默认 5 秒间隔、文件监听file://、内嵌列表list://、DNShttp://。负载均衡负责每次挑谁内置 round-robin、randomized、consistent-hashingmurmurhash3 或 md5、locality-aware 四种见 docs/cn/consistent_hashing.md 与 docs/cn/lalb.md。熔断与健康检查负责坏的什么时候踢。默认策略常开且不可关闭节点返回 ECONNREFUSED、ENETUNREACH、EHOSTUNREACH、EINVAL或连续三次连接超时即被熔断被熔断的连接会启动一个动态创建的 bthread 做健康检查连上后复活重新参与 LB。另外可选基于出错率的激进熔断enable_circuit_breaker用 EMA 平滑延迟维护长/短两个出错窗口适合TCP 能连上但业务线程全卡死这类故障节点。四、实战避坑清单问题 → 做法 → 收益问题做法收益自定义超时后故障节点永远触发不了熔断保证timeout_ms connect_timeout_ms否则 rpc 超时先于连接超时触发连续三次连接超时的判定永远不成立故障节点能被正常剔除避免流量持续打到坏节点大量 bthread 调用阻塞系统调用worker 被占满调大bthread_concurrency或在 server 端限制最大并发保留足够的 worker 处理网络收发在锁内发起 RPC极端情况下全部 worker 阻塞在同一把 pthread mutex 上养成锁内不做 RPC的习惯需要兜底时启用 pthread 模式避免 unlock 依赖的 RPC 回调没有线程执行彻底死锁线上服务状态是黑盒靠打日志排查用内置 HTTP 服务查看/connections连接与熔断数据含 nBreak、RecentErr 字段、/varsbvar 指标、rpcz以及 CPU、Heap、Contention 三个 profiler不重启、不打日志即可定位热点、内存分配和锁竞争性能测试结论与生产表现对不上测试请求加入长尾覆盖多级 server 与多 client 场景参考 benchmark 的测试设计测试暴露的是真实瓶颈而不是 echo 吞吐图4通过浏览器/curl 查看 server 内部状态连接数、指标、profiler 都从这里进入五、上手入口克隆仓库即可开始git clone https://gitcode.com/GitHub_Trending/brpc/brpc建议按这个顺序读docs/cn/getting_started.md 走通第一个 echo 服务docs/cn/overview.md 理解 RPC 抽象与 brpc 的定位docs/cn/bthread.md 和 docs/cn/io.md 补上线程与网络层的细节。框架层面它已经把长尾隔离、并发写出、可观测性做成了默认行为接下来值得关注的方向是 streaming RPC、RDMA 支持以及和 braft 组合搭建高可用分布式系统——这些在 docs 目录里都有对应的专题文档。【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. brpc means better RPC.项目地址: https://gitcode.com/GitHub_Trending/brpc/brpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考