brpc介绍
https://blog.csdn.net/breaksoftware/article/details/81564405?utm_source=copy
更好的延迟和吞吐量
虽然几乎所有的RPC实现都声称它们是“高性能”的，但数字可能只是数字。在不同场景中真正的高绩效是困难的。为了统一百度之内的通信，brpc在性能上比其他实现更深入。
读取和解析来自不同客户端的请求完全并行化，用户不需要区分“IO线程”和“处理线程”。其他实现可能具有“IO线程”和“处理线程”以及散列文件描述符（fd）到IO线程中。当IO线程处理其中一个fds时，线程中的其他fds将无法处理。如果一个消息很大，其他fds会显着延迟。虽然不同的IO线程并行运行，但是你不会有许多IO线程，因为除了从fds读取/解析之外，它们不需要太多的操作。如果有10个IO线程，则fd可能会影响所有fds的10％，这对于工业在线服务是不可接受的（需要99.99％的可用性）。当fds不均匀地分布在IO线程（不幸的是常见的），或者服务是多租户（在云服务中常见）时，问题会更糟。在brpc中，从不同的fds读取并行化，甚至处理来自一个fd的不同消息也被并行化。解析大的消息不会阻止来自同一个fd的其他消息，更不用说其他fds。
写入一个fd和多个fds是高并发的。当多个线程写入相同的fd（通用于多路复用连接）时，第一个线程直接写入就绪，其他线程以等待方式提交写请求。一对fd可以通过几个高度对抗的线程每秒写入5000000个16字节的消息。
最小的锁。高QPS服务可以利用机器上的所有CPU电源。例如，创建用于处理请求的bthread，设置超时，根据响应查找RPC上下文，记录性能计数器都是高并发的。即使服务运行在五十万以上QPS，用户也看到RPC框架引起的contentions（通过contention profiler）。
服务器根据负载调整线程号。传统实现根据延迟设置线程数以避免限制吞吐量。brpc为每个请求创建一个新的bthread，并在请求完成时结束bthread，根据加载自动调整线程号。