【免费下载链接】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 同时提供异步访问接口和基于 M:N 线程模型的 bthread这让很多开发者面临一个经典困惑同一个场景到底该用同步接口、异步接口还是 bthread本文以官方决策指南为核心完整讲解延时不高用同步、不行用异步、只有多核并行计算才用 bthread的选型原则给出可直接套用的qps × latency判断公式与逐步示例并结合仓库源码bthread.h、bthread.cpp剖析 bthread 的调度代价与适用边界帮助你写出既简单易懂又不失性能的并发代码。一、问题背景brpc 提供的三种并发手段brpc 是工业级的 C RPC 框架一个服务在处理请求时往往面临三类选择手段本质适用场景同步接口阻塞等待 RPC 返回代码线性、简单延时低、QPS 不高时异步接口以回调代替阻塞可获得多核扩展性高并发、大量阻塞等待时bthreadM:N 线程库M 个 bthread 映射到 N 个 pthread单次请求内的多核并行计算bthread 是 brpc 使用的 M:N 线程库其目标是在提高程序并发度的同时降低编码难度并在核数日益增多的 CPU 上提供更好的 scalability 和 cache locality。与常见的 N:1 协程coroutine不同bthread 中一个 bthread 被卡住不会影响其他 bthread其关键技术是 work stealing 调度和 butex让 bthread 与 pthread 可以相互等待和唤醒。二、同步 or 异步用一句话给出结论文档给出的短回答非常明确延时不高时你应该先用简单易懂的同步接口不行的话用异步接口只有在需要多核并行计算时才用 bthread。2.1 为什么异步并不总是更好异步的本质是用回调代替阻塞——有阻塞的地方就有回调。虽然 JavaScript 等单线程语言中回调接受度很高、工作得很好但它和我们在多线程 RPC 服务中需要的回调完全是两码事。区别不在于 lambda 或 future而在于 JavaScript 是单线程的它的回调放到多线程下可能没有一个能跑过竞争太多。单线程的同步方法和多线程的同步方法是完全不同的。有人会设想能不能让服务像多个独立 eventloop 那样跑brpc 生态中确实有过类似尝试ubaserver注意带 a但实际效果糟糕因为阻塞改回调并不简单当阻塞发生在循环、条件分支、深层子函数中时改造特别困难大量老代码、第三方代码根本不可能改造结果代码中会出现不可避免的阻塞导致该线程中其他回调被延迟流量超时server 性能不符合预期。如果你打算把现在的同步代码改造为大量回调结果往往是除了我其他人都看不太懂并且性能可能更差了。文档明确提醒别被鼓吹异步的人迷惑他们写的是从头到尾从下到上全异步且不考虑多线程的代码和你要写的完全是两码事。2.2 brpc 中的异步与单线程异步的本质区别brpc 中的异步和单线程的异步完全不同异步回调会运行在与调用处不同的线程中你会获得多核扩展性但代价是你必须意识到多线程问题。好消息是你可以在回调中阻塞只要线程够用对 server 整体的性能并不会有什么影响。异步代码依然很难写为此 brpc 提供了组合访问combo_channel来简化问题。通过组合不同的 channel如 ParallelChannel你可以声明式地执行复杂的多路访问而不用关心其中的回调细节。从 combo_channel.md 的源码文档看ParallelChannel 支持同步和异步访问、可取消、可超时还能通过CallMapper修改请求、ResponseMerger合并结果这就是组合优于自行维护回调计数器的官方推荐做法。2.3 判断使用同步或异步qps × latency 公式延时不长、qps 不高时官方更建议使用同步接口——这其实也正是创建 bthread 的动机维持同步代码的同时也能提升交互性能。判断公式如下计算 qps × latencylatency 以秒为单位如果结果和 cpu 核数是同一数量级就用同步否则用异步。三个典型示例场景计算过程结论qps 2000latency 10ms2000 × 0.01s 20与常见的 32 核同一数量级用同步qps 100latency 5s100 × 5s 500与核数不在同一数量级用异步qps 500latency 100ms500 × 0.1s 50基本同一数量级可用同步若未来延时继续增长考虑异步公式的物理含义这个公式计算的正是同时进行的平均请求数你可以尝试用 Littles Law 的思路证明它它和线程数、cpu 核数是可比的。解读如下当这个值远大于 cpu 核数时说明大部分操作并不耗费 CPU而是让大量线程阻塞等待中——此时使用异步可以明显节省线程资源主要是线程栈占用的内存当这个值小于或与 cpu 核数差不多时异步能节省的线程资源就很有限了此时简单易懂的同步代码更重要。三、异步 or bthread并发 RPC 与并行计算是两回事有了 bthread 这个工具用户甚至可以自己实现异步。以半同步发起多个操作后统一等待为例brpc 中用户有多种选择发起多个异步 RPC 后挨个 Join阻塞直到 RPC 结束——注意这仅用于和 bthread 对比实现中官方建议使用 ParallelChannel而不是自己 Join启动多个 bthread 各自执行同步 RPC然后挨个 join bthreads。3.1 并发 RPC 场景前者效率更高哪种效率更高显然是前者异步 Join。后者不仅要付出创建 bthread 的代价而且在 RPC 阻塞等待期间bthread 还被白白占用着不能用于其他用途。如果仅仅是为了并发 RPC别用 bthread。3.2 并行计算场景bthread 的用武之地不过当你需要并行计算时问题就不同了。使用 bthread 可以简单地构建树形的并行计算充分利用多核资源。比如检索过程中有三个环节可以并行处理你可以建立两个 bthread 运行两个环节在原地运行剩下的环节最后 join 那两个 bthread。过程大致如下bool search() { ... bthread th1, th2; if (bthread_start_background(th1, NULL, part1, part1_args) ! 0) { LOG(ERROR) Fail to create bthread for part1; return false; } if (bthread_start_background(th2, NULL, part2, part2_args) ! 0) { LOG(ERROR) Fail to create bthread for part2; return false; } part3(part3_args); bthread_join(th1); bthread_join(th2); return true; }对照 bthread.h 中的接口声明可以印证这段代码的两个关键 APIbthread_start_background(tid, attr, fn, args)创建 bthreadfn(args)并把标识符写入tid行为更接近pthread_create——调度新线程运行后立即返回注释明确指出新线程可能比bthread_start_urgent()更晚运行bthread_join(bt, bthread_return)使调用线程等待 bthreadbt终止若bt已终止则立即返回注释Return immediately ifbtis already terminated且bthread_join()不受bthread_interrupt()影响。在 bthread.cpp 的实现中bthread_start_background会优先尝试把新任务放入当前 pthread worker 的本地 TaskGroupg-start_backgroundfalse若调用者不在 worker 线程上则走start_from_non_worker——这就是它创建开销小、调度快的底层来源。这个两线程并行 原地运行实现的两个要点原文 point线程资源更省你当然可以建立三个 bthread 分别执行三个部分再统一 join但相比上面这个方法要多耗费一个 bthread 资源调度延时需要心里有数bthread 从建立到执行是有延时的调度延时。在不是很忙的机器上这个延时的中位数在 3 微秒左右90% 在 10 微秒内99.99% 在 30 微秒内。这带来两个推论计算时间超过 1ms 时收益才比较明显。如果计算非常简单、几微秒就结束了用 bthread 是没有意义的尽量让原地运行的部分最慢。这样 bthread 中的部分即使被延迟了几微秒最后可能还是会先结束从而消除掉调度延迟的影响并且join 一个已结束的 bthread 会立刻返回不会有上下文切换开销。3.3 线程池需求用 bthread 或 ExecutionQueue当你有类似线程池的需求——比如要执行某一类 job 的线程池——也可以用 bthread 代替。如果对 job 的执行顺序有要求可以使用基于 bthread 的 ExecutionQueue。从 execution_queue.md 可以看到ExecutionQueue 提供异步有序执行任务在单独线程中执行执行顺序严格与提交顺序一致、多生产者并发提交、取消已提交任务、stop 以及高优任务插队等能力其任务提交接口是 wait-free 的并且运行线程本身就是 bthread可以在执行函数中随意使用 bthread 同步原语而不必担心阻塞 pthread 的执行——这正是它替代自定义 job 线程池 队列的底气。四、选型决策树与最佳实践总结综合全篇brpc 并发代码的选型可以浓缩为下面的决策路径需要并发处理吗 ├─ 否 → 直接用同步接口最简单、最易维护 └─ 是 ├─ 仅是为了并发 RPC多个下游访问→ 用 ParallelChannel / 异步接口 │ 不要用 bthreadqps × latency 远大于核数时异步收益明显 └─ 需要多核并行计算CPU 密集、可拆分环节 ├─ 子任务耗时 1ms → bthread 树形并行原地跑最慢的一路 ├─ 子任务耗时仅几微秒 → 不值得用 bthread └─ 需要有序执行的一类 job → ExecutionQueue几个被反复强调的关键结论值得作为团队编码规范默认同步按需异步延时不高、QPS 不高时同步接口永远是第一选择它简单、可读、可维护用公式而不是感觉做决策qps × latency(秒)与 cpu 核数对比同一数量级用同步否则用异步并发 RPC 别用 bthread并行 RPC 场景下 bthread 只会徒增创建开销且 RPC 阻塞期间 bthread 被闲置bthread 只服务于并行计算且子任务要足够重 1ms才划算调度延时的中位数在 3 微秒左右复杂组合访问优先用 ParallelChannel有顺序执行需求的 job 队列用 ExecutionQueue。关于 bthread 的更多底层机制work stealing、butex、与 pthread worker 的对应关系、阻塞时的行为可进一步阅读 bthread.md 和 threading_overview.md关于同步/异步接口的完整用法见 client.md 与 combo_channel.md。需要说明的是上述决策框架面向的是以阻塞式业务逻辑为主的通用在线服务如果你的场景运行时间确定、代码严格非阻塞那么 N:1 协程或 eventloop 风格也有其用武之地但那是另一套选型逻辑了。赞分享【免费下载链接】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 并发模型选型指南同步、异步还是 bthreadbrpc 并发模型选型指南同步、异步还是 bthread 这篇技术指南围绕 brpc 中最常见的架构选择题展开当服务需要并发时到底该用同步接口、异步接口后端RPC框架通信网络LanceDB Python API 完整指南同步与异步双接口实战LanceDB Python API 完整指南同步与异步双接口实战 LanceDB 是一个面向多模态 AI 的开发者友好型开源嵌入式向量检索库。本文基于仓库中数据库向量数据库全文检索人工智能PyPTO 核间同步之 wait_cross_core接口语义、同步模式与实战示例PyPTO 核间同步之 wait_cross_core接口语义、同步模式与实战示例 pypto_pro.language.system.wait_cross_人工智能编译器模型编译深度学习高性能计算CANNAscend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考