brpc
brpc copied to clipboard
apache
brpc 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...
Add cassandra query language(cql) protocol. protocol version: https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v3.spec Supported: 1. authentication 2. query 3. batch Unsupported: 1. register, event TODO: 1. prepare/execute 2. naming service 3. token-aware load balancer
当server负载较大时(32核，cpu 负载 300%~ 700% )， client会报 "[R1][E112]Fail to select server from list://127.0.0.1:10002 lb=la", 有时候client只是偶尔报几下。有时候一旦开始报了，后面就一直失败了，所有消息都发送失败，但如果此时再开一个新client，新client是可以正常收发消息的
**Describe the bug (描述bug)** 使用 bazel 4.2 版本编译的时候会报错。 **To Reproduce (复现方法)** 直接编译的时候会有下面的 error：  在注释掉对应的 flag 之后，会有下面的 error：  **Expected behavior (期望行为)** **Versions (各种版本)** OS: Compiler: brpc: protobuf: **Additional context/screenshots...
**Describe the bug (描述bug)** 使用h2:grpc时，server端服务（grpc）持续不可用，client端（brpc）陷入死循环。grpc服务不可用时，client端出错日志如下： `E0108 07:08:32.286566 111758 xxx_client.cc:166] call xxx server failed, Request to x.x.x.x:52618 failed: [E2001][11.18.42.196:52618][E112]xxx_server response :[E112]Not connected to x.x.x.x:8000 yet, server_id=xxxx [R1][E112]Not connected to x.x.x.x:8000 yet,...
可以理解为“由多个single连接组成”的连接方式。相比single可以更好地应对网络抖动，相比pooled可以节省连接数和读写开销。支持single方式的协议都支持multi方式。 single总与一个对端保持一个连接，一个连接上可以同时做多个rpc，所以回复中一定要有id机制以和请求对上，对协议设计有要求。 * pros：节省连接数是显而易见的，这对于有几千台机器的分布式集群很重要。一个连接上同时发送的多个请求可以被合并，从而减低读写开销，在小包高qps场景中，对cpu的节省效果很明显。 * cons ：把“很多鸡蛋放在了一个篮子里”，当tcp连接抖动时并触发RTO退避策略时，一大批请求都会受影响，在广域网中的SLA会比较糟糕。 pooled则是与一个对端保持一个连接池，每次发送前从池中取一个连接，一个连接上同时只能做一个rpc，直到回复回来，才能放回对应的连接池。如果rpc超时，对应的连接会被关闭（以防止老回复回来，打破了一个连接上只有一个rpc的假设）。协议不需要传递id字段，几乎所有协议都支持。 * pros：天然自带负载均衡，是“最小连接数”策略的特殊形式，延时往往是最优的，并且很健壮。因为某个连接抖动也意味着对应的rpc没有结束，那个连接就不会还回连接池，也不会被其他rpc选到，最后一般只影响一个请求，在广域网中的效果很好。 * cons：连接数很多，基本不能用在大型分布式系统内。一个连接每次最多写一个请求，在小包高qps场景中，sys-read/write的占比会非常显著。 multi方式可视作对single和pooled的折衷，相比single连接数扩大了常数倍（比如2-3倍），但是同时又能像pooled那样在某个连接抖动时通过走其他连接，控制影响面。所以从这点来说，multi方式并不是简单地建立多个single连接，随机分发，那样是没有反馈的，multi方式是让每个连接上进行的rpc数尽量相当，当某一路抖动时，其上的rpc数也不会减少，从而让框架选择其他连接。
这是brpc输出  这是一般的promethus client的输出  brpc的输出缺少label维度的信息，不便于promQL快速查询 并且产出都是gauge类型，缺少counter，summary这些类型 请问： 1.后续会支持label维度的产出吗 2.后续会支持除了gauge类型以外的产出吗？ @zyearn @jamesge @wanglun
Automatic translated missing Chinese documents and added them to the english version.
https://github.com/apache/incubator-brpc/blob/master/community/cases.md 针对这个文件，提交PR，然后找我review即可。 更新过程： 1. 开一个issue，名字不妨为“xxx公司的brpc落地场景“ 2. 修改这个文件（cases.md) 3. 提交PR
