【免费下载链接】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/gh_mirrors/brpc3/brpc点击查看免费下载导读本文基于 brpc 开源仓库官方文档 docs/cn/benchmark.md 展开系统讲解 brpc 团队在 2015 年发起的一次跨框架基准性能测试——包括为什么 RPC 性能测试必须引入长尾请求、如何设计同机/跨机/多级 server 的测试拓扑、如何解读 QPS 与延时 CDF 曲线以及 brpc 与 UB、hulu-pbrpc、sofa-pbrpc、Apache Thrift、gRPC 五个框架的对比结论。读完本文你将掌握一套对真实生产场景有指导意义、可复用的 RPC 性能测试方法论并理解 brpc 在吞吐、延时与长尾隔离上表现优异的底层原因请求级线程跳转、wait-free 收发、bthread 调度等源码实现。关于本文数据的前提说明本文所引用的测试结果来自 brpc 仓库官方文档 docs/cn/benchmark.md。该文档在开头明确注明following tests were done in 2015, which may not reflect latest status of the package以下测试于 2015 年完成可能无法反映软件包的最新状态。因此所有数字、曲线与排名结论都是2015 年底特定版本、特定机器、特定配置下的观测结果各参与框架当时的代码版本分别为UBnova_pbrpcr10500、hulu-pbrpcpbrpc_2-0-15-27959_PD_BL、brpcr31906、sofa-pbrpcsofa-pbrpc_1-0-2_BRANCH、thriftthrift_0-9-1-400_PD_BL、gRPC 对应release-0_11分支时至今日brpc 已历经大量迭代仅测试发起后一年内就又有 1200 多次改动这些框架的现状也已发生巨大变化。本文的价值在于其方法论而不应被当作当下版本的横向性能排名来引用。序言为什么性能测试要谈线程模型在进入具体测试数字之前benchmark 文档花了大量篇幅解释一个根本性问题多核时代性能与线程是紧密绑定的。线程跳转的代价从纳秒到微秒线程间的跳转对高频 IO 操作性能有决定性作用一次跳转至少意味着3–20 微秒的延时。由于每个核心的 L1 cache 独立当时的测试 CPU 上 L2 cache 也是独立的跳转随之带来大量 cache miss——一些变量的读取、写入延时从纳秒级上升几百倍到微秒级因为要等待 CPU 把对应的 cacheline 同步过来。由此产生一个反直觉的结论当每次处理都很简短时多线程程序未必比单线程程序更快。前者可能在每次付出大的切换代价后只做了一点点正事而后者在不停地做正事。但单线程也有代价——它工作良好的前提是正事都很快一旦某次变慢后续所有正事都被延迟。单线程模型适合什么不适合什么在处理时间普遍较短、可预测的程序中多个不相交的单线程能最大化做正事的比例延时表现也很稳定各种 HTTP server 正是这样——这也是 threading_overview.md 中介绍的单线程 reactor模型event-loop 派被 HTTP server 广泛采用的原因大部分 HTTP 请求的处理时间可预测对下游的访问也没有阻塞代码该模型能最大化 CPU 利用率并提供可接受的延时。而 brpc 面对的检索类服务要复杂得多有大量后端服务需要访问广泛存在的长尾请求使每次处理的时间无法确定排序策略等业务逻辑越来越复杂。在这种场景下如果还使用多个不相交的单线程一次难以预计的性能抖动或一个大请求可能导致后续一堆请求被延迟。这正是文档强调的核心多线程付出上下文切换与 cache 同步的代价目的是隔离请求间的影响——一个计算复杂或索性阻塞的过程不会影响到其他请求1% 的长尾最终只影响到 1% 的性能。而多个独立的单线程保证不了这点一个请求进入一个线程就等于定了终生前面的请求慢一下后面的只能跟着慢1% 的长尾会影响远超 1% 的请求。请求级线程跳转是 brpc 的必然选择为避免请求之间相互影响请求级的线程跳转是 brpc 必须付出的代价brpc 团队能做的是使线程跳转最优化。从源码层面看brpc 的收消息路径由 event_dispatcher.h 中的 EventDispatcherEDISP与 input_messenger.h 中的 InputMessenger 协作完成EDISP 收到事件后启动一个 bthread 处理对应 fd 上的数据并把所在 pthread 让给新建的 bthread 以获得更好的 cache localityfd 间和 fd 内的消息都会获得并发发消息 一侧则通过 wait-free MPSC 链表实现多线程同时向一个 fd 写出数据写出总能很快返回调用线程可以更快地处理新任务。这些设计正是 brpc 在长尾场景下仍能隔离请求影响的底层基础。既有性能测试的缺陷与改进方向不过对服务的性能测试还不能很好地体现上述设计价值测试中的处理往往极为简单使线程切换的影响空前巨大。通过控制多线程和单线程处理的比例可以把一个测试服务的 QPS 从 100 万到 500 万操纵自如同机——这损伤了性能测试结果的可信度。真实服务并不是在累加一个数字或 echo 一个字符串一个 QPS 几百万的 echo 程序没有指导意义。鉴于此在发起性能测试一年后2015 年底、brpc 又经历了 1200 多次改动后团队决定 review 所有测试加强其中的线程因素以获得对真实场景有明确意义的结果。具体改进方向有三条请求不应等长要有长尾考察 RPC 能否让请求并发否则一个慢请求会影响大量后续请求要有多级 server 的场景server 内用 client 访问下游 server考察 server 和 client 的综合表现要有一个 client 访问多个 server 的场景考察负载均衡是否足够并发——真实场景中很少一个 client 只访问一个 server。这套测试场景的设计思路对其他服务的性能测试同样具有借鉴意义。测试目标六个参与框架UB以 nova_pbrpc 为代表UB 是百度 2008 年开发的 RPC 框架在百度产品线广泛使用已被 brpc 代替。其特点与局限包括每个请求独占一个连接连接池在大规模服务中每台机器需要保持大量连接限制了使用场景百度的分布式系统没有用 UB只支持 nshead mcpack 协议扩展性差增加新协议和新功能往往要调整大段代码实践中大部分人知难而退缺乏调试和运维接口服务运行状态对用户基本是黑盒只能靠低效地打日志追踪问题排查效率低。UB 有多个变种变种时间序列化方式说明ubrpc2010 年.idl 文件类似 .proto描述 schema有被使用但不广泛nova_pbrpc2012 年protobuf 代替 mcpack百度网盟团队开发协议为 nshead users protobufpublic_pbrpc2013 年初protobuf 代替 mcpack协议与 nova_pbrpc 不同大致为 nshead meta protobuf用户数据需序列化两次性能很差未推广测试以在百度网盟团队广泛使用的 nova_pbrpc 为 UB 的代表代码r10500。早期的 UB 支持 CPOOL 和 XPOOL分别使用 select 和 leader-follower 模型后来提供 EPOLL使用 epoll 处理多路连接鉴于产品线大都是用 EPOLL 模型测试配置使用 EPOLL。UB 只支持连接池这种连接方式结果用ubrpc_mc指代mc 代表 multiple connection在文档语境下默认 ubrpc UB。hulu-pbrpc百度 2013 年基于 saberkylin 变种和 protobuf 实现的 RPC 框架多线程实现上有较多问题已被 brpc 代替。测试时其代码为pbrpc_2-0-15-27959_PD_BL只支持单连接结果用hulu-pbrpc指代。brpcINF 2014 年底开发至今的 RPC 产品支持百度内所有协议不限于 protobuf并第一次统一了百度主要分布式系统和业务线的 RPC 框架。测试时代码为r31906。brpc 既支持单连接也支持连接池前者的结果用baidu-rpc指代后者用baidu-rpc_mc指代。brpc 的连接方式短连接、连接池、单连接在 client.md 中有完整说明其中单连接指一个 client 与一个 server 只建立一个连接供一个 fd 上的所有请求使用是吞吐最高、也最省资源的连接方式连接池则维持多个连接。具体到发送路径socket.cpp 中的 wait-free MPSC 写出实现使单连接在写出时也能高效并发。sofa-pbrpc百度大搜团队 2013 年基于 boost::asio 和 protobuf 实现的 RPC 框架。有多个版本经咨询相关同学确认 ps/opensource 下的和 GitHub 上的较新且会定期同步故测试使用 ps/opensource 下的版本代码为sofa-pbrpc_1-0-2_BRANCH。只支持单连接结果用sofa-pbrpc指代。Apache Thriftthrift 由 Facebook 最早在 2007 年开发是序列化方法和 RPC 框架包含独特的序列化格式和 IDL支持很多编程语言。开源后改名 Apache ThriftFacebook 自己有 fbthrift 分支测试使用的是 apache thrift代码为thrift_0-9-1-400_PD_BL。文档对其缺点总结为代码看似分层清晰client 和 server 选择很多但没有一个足够通用——每个 server 实现只能解决很小一块场景每个 client 都线程不安全实际使用很麻烦。由于 thrift 没有线程安全的 client每个线程都得建立独立 client、使用独立连接。文档特别指出在测试中 thrift 其实是占了其他实现的便宜——它的 client 不需要处理多线程问题。结果用thrift_mc指代。gRPCGoogle 开发的 RPC 框架使用 HTTP/2 和 protobuf 3.0测试时对应其release-0_11分支。文档指出 gRPC 并不是 stubby定位更像是为了推广 HTTP/2 和 protobuf 3.0但鉴于很多人对其表现感兴趣团队也很麻烦地将其加入测试。结果用grpc指代。测试方法RPC 的底线是必须能处理长尾如序言所解释的性能数字有巨大的调整空间。关键在于对 RPC 的底线要求是什么脱离这个底线测试表现就严重偏离真实环境。文档给出的底线是RPC 必须能处理长尾。在百度的环境中每个产品线、每个系统都有长尾作为承载大部分服务的 RPC 框架自然得处理好长尾、减少长尾对正常请求的影响。但在实现层面这个问题对设计的影响太大如果测试中没有长尾RPC 实现就可以假设每个请求都差不多快此时最优方法是用多个线程独立地处理请求。由于没有上下文切换和 cache 一致性同步程序性能会显著高于多个线程协作时。比如简单的 echo 程序处理一个请求只需 200–300 纳秒单个线程可以达到 300–500 万的吞吐但如果多个线程协作即使在极其流畅的系统中也要付出 3–5 微秒的上下文切换代价和 1 微秒的 cache 同步代价还没考虑其他互斥逻辑——一般来说单个线程的吞吐很难超过 10 万即使 24 核全部用满吞吐也只有 240 万不及一个线程。这正是 threading_overview.md 所描述的取舍多线程 reactor 因 cache 一致性的限制无法获得线性于核心数的性能粗糙的多线程 reactor 实现跑在 24 核上甚至没有精致的单线程 reactor 跑在 1 个核上快但多线程模型通过请求级隔离让 1% 的长尾只影响 1% 的性能。乍看多线程慢了在真实应用中反而会获得更好的综合性能。如何度量长尾干扰延时 CDF 而非 QPS延时能精确体现长尾的干扰作用如果普通请求的延时没有被长尾请求干扰就说明 RPC 成功隔离了请求。而 QPS 无法体现这点——只要 CPU 都在忙即使一个正常请求进入了挤满长尾的队列而被严重延迟最终 QPS 也变化不大。为测量长尾的干扰作用所有涉及延时的测试都增加了1% 的长尾请求长尾请求耗时毫秒级且其延时不计入结果因为考察的是普通请求是否被及时处理。延时的统计与查看方式详见 vars.mdx% 分位值percentile指把一段时间内的 N 个统计值排序后第 N*x% 位的值分位值可绘制为 CDF累积分布函数曲线——横轴是数值 ≤ y 的比例纵轴是对应分位值中位数密度高边上长尾很扁所以系统测量普遍选择 CDF 而非 PDF一条缓慢上升且长尾区域面积不大的 CDF 便是不错的曲线。工业级应用的 SLA 一般在 99.97% 以上分位值能帮助分析长尾区域——这正是本文各延时图越左越好、越直越好的评判依据。测试环境与配置机器环境性能测试使用三类机器机器组配置单机1CPU 开超线程 24 核E5-2620 2.00GHz64GB 内存OS linux 2.6.32_1-15-0-0多机115台8台CPU 均未开超线程 12 核其中 15 台为 E5-2420 1.90GHz、64GB 内存、千兆网卡无法开启多队列其余 8 台为 E5-2620 2.0GHz、千兆网卡、绑定多队列到前 8 个核。长期测试机器较杂跨多个机房测试中延时在 1ms 以上的就是这批机器多机230台CPU 未开超线程 12 核E5-2620 v3 2.40GHz96GB 内存OS linux 2.6.32_1-17-0-0万兆网卡绑定多队列到前 8 个核。临时借用的新机器配置非常好都在广州机房延时非常短测试中延时在几百微秒的就是这批机器下面所有的曲线图均使用 brpc 开发的 dashboard 程序绘制去掉路径后可以看到和所有 brpc server 一样的内置服务——即 /status、/vars、/connections、/flags、/rpcz、cpu profiler、heap profiler、contention profiler 等这也是观测 rpc_press 压力状态的标准入口见后文如何复现与观测。统一配置如无特殊说明所有测试中的配置只是数量差异线程数、请求大小、client 个数等而不是模型差异确保用户看到的 QPS 和延时是同一个场景的不同维度而非无法统一的两个场景。所有 RPC server 都配置了24 个工作线程一般运行用户的处理逻辑。关于每种 RPC 的特殊说明UB配置 12 个 reactor 线程使用 EPOLL 模型连接池限制数配置为线程个数24。hulu-pbrpc额外配置 12 个 IO 线程处理 fd 读取、请求解析等任务。hulu 有个共享队列配置项默认不打开作用是把 fd 静态散列到多个线程由于线程间不再争抢QPS 会显著提高但会明显被长尾影响原因见上文测试方法。考虑到大部分使用者不会去改配置测试也选择不打开。thrift额外配置 12 个 IO 线程处理 fd 读取、请求解析client 不支持多线程每个线程使用独立 client、独立连接。sofa-pbrpc按 sofa 团队要求io_service_pool_size配置为 24、work_thread_num配置为 1——即使用独立的 24 组线程池每组 1 个 worker thread。和 hulu 不打开共享队列时类似这个配置显著提高 QPS但使其失去处理长尾的能力。文档明确建议真实产品中不要用这个配置而应该用io_service_pool_size1, work_thread_num24。brpc尽管 brpc 的 client 运行在 bthread 中时会获得 10%~20% 的 QPS 提升和更低的延时但测试中的 client 都运行在统一的 pthread 中——这是为了公平对比也说明 brpc 在未启用 bthread 调度时仍有出色表现。bthread 是 brpc 使用的 M:N 线程库关键技术在 bthread.md 中有介绍work stealing 调度让 bthread 更快地被调度到更多核心上butex 让 bthread 和 pthread 可以相互等待和唤醒。压测客户端的发送方式所有的 RPC client 都以多个线程同步发送方式压测这最接近真实系统情况在考察 QPS 时也兼顾了延时因素。文档同时批判了一种流行方案client 不停地往连接中写数据看 server 表现。其弊端在于server 一下子能读出大量请求不同 RPC 的比拼变成了for 循环执行用户代码的比拼而不是分发请求的效率——真实系统中 server 很少能同时读到超过 4 个请求而且该方法完全放弃延时client 实际上是让 server 陷入雪崩时才会进入的状态所有请求都因大量排队而超时。六组测试场景与结果分析场景一同机单 client → 单 server不同请求大小下的 QPS越高越好运行在单机1 上。图中的数值均为用户数据的字节数实际请求尺寸还要包括协议头一般增加约 40 字节。以_mc结尾的曲线代表 client 和 server 保持多个连接线程数个。分析brpc请求包小于 16KB 时单连接下的吞吐超过了多连接的 ubrp_mc 和 thrift_mc随着请求包变大内核对单个连接的写入速度成为瓶颈而多连接下的 brpc 达到测试中最高的2.3GB/s。注意使用连接池的 brpc 发送大包时吞吐更高但也会耗费更多 CPUUB 和 thrift 同样如此。图中的单连接 brpc 已能提供 800 多兆吞吐足以打满万兆网卡而使用的 CPU 可能只有多连接下的 1/2写出过程是 wait-free 的真实系统中请优先使用单连接。thrift初期明显低于 brpc随包变大超过了单连接的 brpc。UB与 thrift 曲线类似但平均低 4–5 万 QPS在 32K 包时超过单连接 brpc整个过程中 QPS 几乎没变。gRPC初期几乎与 UB 平行但低约 1 万超过 8K 开始下降。hulu-pbrpc 和 sofa-pbrpc512 字节前高于 UB 和 gRPC之后急转直下、相继垫底——这个趋势是写不够并发的迹象。场景二同机单 client → 单 server不同线程数下的 QPS越高越好运行在单机1 上。分析brpc随着发送线程增加QPS 快速增加多线程扩展性很好。UB 和 thrift8 个线程下高于 brpc但超过 8 个线程后被 brpc 迅速超过thrift 继续平移UB 出现明显下降。gRPC、hulu-pbrpc、sofa-pbrpc几乎重合256 个线程时相比 1 个线程只有 1 倍提升多线程扩展性不佳。场景三同机单 client → 单 server固定 QPS 下的延时 CDF越左越好、越直越好运行在单机1 上。考虑到不同 RPC 的处理能力选择了一个较低、在不少系统中会达到的 QPS1 万。测试中有 1% 的长尾请求耗时 5 毫秒长尾请求的延时不计入结果。分析brpc平均延时短几乎没有被长尾影响。UB 和 thrift平均延时比 brpc 高 1 毫秒受长尾影响不大。hulu-pbrpc走向与 UB、thrift 类似但平均延时进一步增加 1 毫秒。gRPC初期不错到长尾区域后表现糟糕直接有一部分请求超时反复测试都是这样像是有 bug。sofa-pbrpc30% 的普通请求上图未显示被长尾严重干扰。场景四跨机多 client → 单 server 的 QPS越高越好运行在多机1 上。分析brpc随着 client 增加server 的 QPS 快速增加client 扩展性不错。sofa-pbrpc随着 client 增加 QPS 也快速增加但幅度不如 brpc从 16 个 client 到 32 个 client 时提升较小。hulu-pbrpcQPS 在增加但幅度进一步小于 sofa-pbrpc。UB增加 client 几乎不能增加 server 的 QPS。thrift平均 QPS 低于 UB增加 client 几乎不能增加 server 的 QPS。gRPC垫底增加 client 几乎不能增加 server 的 QPS。场景五跨机多 client → 单 server固定 QPS 下的延时 CDF越左越好、越直越好运行在多机1 上。负载均衡算法为 round-robin 或 RPC 默认提供的。由于有 32 个 client 且一些 RPC 的单 client 能力不佳为每个 client 仅设定2500 QPS——一个真实业务系统能达到的数字。测试中有 1% 的长尾请求耗时 15 毫秒长尾请求的延时不计入结果。分析brpc平均延时短几乎没有被长尾影响。UB 和 thrift平均延时短受长尾影响小但平均延时高于 brpc。sofa-pbrpc14% 的普通请求被长尾严重干扰。hulu-pbrpc15% 的普通请求被长尾严重干扰。gRPC已经完全失控非常糟糕。场景六跨机多 client → 多 server → 多 server固定 QPS 下的延时 CDF越左越好、越直越好本场景实为两级 server 的级联访问。运行在多机2 上20 台每台运行 4 个 client多线程同步访问 10 台 server。负载均衡算法为 round-robin 或 RPC 默认提供的。由于 gRPC 访问多 server 较麻烦且很大概率仍表现不佳此测试不含 gRPC。分析brpc 和 UB平均延时短几乎没有被长尾影响。thrift平均延时显著高于 brpc 和 UB。sofa-pbrpc2.5% 的普通请求被长尾严重干扰。hulu-pbrpc22% 的普通请求被长尾严重干扰。紧接着的三级级联场景多 client → 多 server → 多 server运行在多机2 上14 台每台运行 4 个 client多线程同步访问 8 台 server这些 server 还会同步访问另外 8 台 server此场景同样不含 gRPC。分析brpc平均延时短几乎没有被长尾影响。UB平均延时短长尾区域略差于 brpc。thrift平均延时显著高于 brpc 和 UB。sofa-pbrpc17% 的普通请求被长尾严重干扰其中 2% 的请求延时极长。hulu-pbrpc基本消失在视野中已无法正常工作。结论汇总框架吞吐平均延时长尾处理扩展性brpc优秀多连接下最高 2.3GB/s优秀优秀几乎不受长尾影响线程数与 client 数扩展性均好UB扩展性较差提高线程数和 client 数几乎不能提升吞吐不错不错差thrift单机尚可多机一般单机尚可多机明显高于 brpc 和 UB一般差sofa-pbrpc小包尚可大包显著低于其他受长尾影响很大差14%~30% 请求被干扰尚可hulu-pbrpc单机与 sofa-pbrpc 类似多机表现极差差15%~22% 请求被干扰一般gRPC几乎在所有参与的测试中垫底—差甚至超时、失控差文档对 gRPC 的结论是几乎在所有参与的测试中垫底其定位可能是给 Google Cloud Platform 的用户提供一个多语言、对网络友好的实现性能还不是要务。注意以上均为 2015 年测试结论且部分框架已停止维护UB、hulu-pbrpc、sofa-pbrpc 已被 brpc 代替gRPC 与 thrift 后续版本亦变化巨大切勿将上表作为当下跨框架性能排名引用其真正可复用的是长尾优先 多级拓扑 CDF 度量的测试方法论。如何复现与观测rpc_press 实战benchmark 文档给出了测试方法论的框架若要在自己的服务上复现同类测试可借助仓库自带的压测工具rpc_press位于 tools/rpc_press其完整用法见 docs/cn/rpc_press.md。要点如下获取工具先按 Getting Started 编译好 brpc再编译 tools/rpc_press。rpc_press 会动态加载 proto 文件无需把 proto 编译为 C 源文件它会加载 json 格式的输入文件、转为 pb 请求发向 server收到 pb 回复后按需转为 json 写入指定文件。所有选项均来自命令行参数而非配置文件。必需参数-proto指定相关的 proto 文件名-method指定方法名形式必须是package.service.method-server当-lb_policy为空时是服务器的ip:port当-lb_policy不为空时是集群地址如bns://node-name、file://server_list等具体见命名服务-input指定 json 请求或包含 json 请求的文件。可选参数-inc包含被 import 的 proto 文件的路径多个路径用分号;分隔-lb_policy负载均衡算法默认为空可选项为rr random la c_murmurhash c_md5具体见负载均衡-timeout_ms超时毫秒默认 1000-max_retry最大重试次数默认 3一般无需修改重试行为见这里-protocol连接 server 使用的协议默认为 baidu_std可选项见协议-connection_type连接方式可选项为single pooled short见连接方式默认根据协议自动选择-output非空时 response 转为 json 写入该文件默认空-duration大于 0 表示发送这么多秒压力后退出否则一直发直到 Ctrl-C默认 0-qps大于 0 表示以此压力发送否则以最大速度自适应发送默认 100-dummy_port修改 dummy_server 端口默认 8888。常用命令示例对应本文多 client 多线程同步发送的压测形态# 向 0.0.0.0:8002 用 baidu_std 以固定 100 QPS 持续发送 ./input.json 中的请求 ./rpc_press -protoecho.proto -methodexample.EchoService.Echo \ -server0.0.0.0:8002 -input./input.json -qps100 # 以 round-robin 分流向 bns://node-name 代表的所有下游发送固定 100 QPS ./rpc_press -protoecho.proto -methodexample.EchoService.Echo \ -serverbns://node-name -lb_policyrr \ -input{message:hello} {message:world} -qps100 # 以最大压力持续发送 10 秒 ./rpc_press -protoecho.proto -methodexample.EchoService.Echo \ -server0.0.0.0:8002 -input{message:hello} {message:world} \ -qps0 -duration10观测方法rpc_press 启动后默认在 8888 端口启动一个 dummy server浏览器打开即可看到和所有 brpc server 一致的内置服务页面切换到 vars 页面并在 Search 框中输入rpc_press可以看到当前压力的延时分布情况。若无法打开浏览器命令行也会定期打印sent / success / error信息以及[Latency]分位值列表avg、50%、70%、90%、95%、97%、99%、99.9%、99.99%、max单位微秒——一般性能测试需要关注 99% 之后的长尾区域这与本文所有延时 CDF 测试考察普通请求是否被长尾影响的视角完全一致。延伸阅读docs/cn/threading_overview.md常见线程模型连接独占线程、单线程 reactor、N:1 线程库、多线程 reactor、M:N 线程库及其多核扩展性与异步编程问题——本文序言部分的理论基础docs/cn/io.mdbrpc 收消息、发消息与 Socket 的完整实现The full picture 给出全链路图发消息 讲解 wait-free 写出——本文单连接也能高吞吐的源码依据docs/cn/bthread.mdbrpc 的 M:N 线程库work stealing 调度与 butex——理解 brpc 请求级调度与长尾隔离的关键docs/cn/client.md命名服务、负载均衡rr、random、la、c_murmurhash、c_md5 等与连接方式docs/cn/vars.md分位值percentile与 CDF 的统计、查看方法——解读本文所有延时曲线的方法依据docs/cn/rpc_press.mdrpc_press 压测工具完整参数与使用示例docs/cn/builtin_service.mddashboard 曲线的来源即每个 brpc server 自带的 /status、/vars、/rpcz 等内置服务核心实现源码src/brpc/event_dispatcher.h、src/brpc/input_messenger.h、src/brpc/socket.h、src/brpc/socket.cpp。赞分享【免费下载链接】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/gh_mirrors/brpc3/brpc点击查看免费下载相关推荐brpc 性能基准测试深度解读基于长尾场景的多框架对比与测试方法论brpc 性能基准测试深度解读基于长尾场景的多框架对比与测试方法论 本文以 brpc 仓库中的 docs/cn/benchmark.md https://liAI Agent人工智能大模型AI 应用工具调用本地部署MCP ClientsAgent 记忆GUI 自动化ComfyUI 视频生成实战用 WanVideo 工作流把一张照片变成 81 帧视频ComfyUI 视频生成实战用 WanVideo 工作流把一张照片变成 81 帧视频 在消费级显卡上跑通 ComfyUI WanVideoWrapper 的图人工智能大模型媒体生成终极指南gRPC性能基准测试与主流RPC框架全面对比分析终极指南gRPC性能基准测试与主流RPC框架全面对比分析 gRPC作为现代云原生应用的远程过程调用RPC框架以其跨语言支持、高效二进制协议和强大的生态系后端RPC框架微服务通信上一篇Scroll ReversermacOS上为每个设备定制专属滚动方向的终极指南下一篇BlockNote 高级表格功能实战splitCells、单元格着色与表头行/列配置详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考