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...
问题： 当请求量过大时，所有的local queue 都是 full 的状态，就会执行pthread 的 usleep，这样会导致死锁(这个问题以前有人提过). ====task_group_inl.h 代码如下===== while (!_rq.push(tid)) { flush_nosignal_tasks(); ::usleep(1000); } 方案 如果local queue 是full 的状态，当前线程直接执行,不尝试再次放到队列中（不进行 usleep) 伪代码如下： while (!_rq.push(tid)) { // 替换 usleep, push...
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** 存储领域，大块 IO，如果能使用 RDMA_READ/RDMA_WRITE 这种单边操作，会节省 cpu，用更少的核达到更高的吞吐。 目前看代码 send/recv 已经是 zero copy，不确定单边操作是否可获得实质性的收益。 **Describe the solution you'd like (描述你期望的解决方法)** 可能可以借鉴 [NVMe/RDMA Transport spec](https://nvmexpress.org/wp-content/uploads/NVM-Express-RDMA-Transport-Specification-1.0d-2024.07.01-Ratified.pdf) 中描述的架构。
**Describe the bug (描述bug)** 1、父进程启动bthread 2、fork出子进程 3、子进程的Sampler踩了内存 **To Reproduce (复现方法)** 编译执行 使用valgrind可见 ```C++ #include #include #include #include #include #include #include using namespace std; void child_proc(); void parent_proc(); void *empty_th(void *)...
C++可以原生用。再用brpc写一个原始redis协议到cluster协议的proxy，供其他语言的server同机或同容器部署。 优点： * 官方方案会持续更新。 * 没有走网络流量的proxy层，省延时、带宽。C++实现开销最小化。 * proxy比较轻，侵入性不大，开发和部署都相对简单，可控。 缺点: * Redis cluster的运维、扩容、debugging复杂度较高。 * redis cluster的集群扩展性有限。
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** redis cluster 是现在 redis 官方推荐的集群方案，使用的地方也比较多。建议 brpc 在现在的 redis 协议的基础上增加 redis cluster 支持。 具体支持方式不难: 1. RedisClusterNamingService 初始化 redis cluster 地址列表 作为种子节点。 2....
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** no **Describe the solution you'd like (描述你期望的解决方法)** 希望 redis的客户端可以支持 cluster 和 sentinel 的连接方式 **Describe alternatives you've considered (描述你想到的折衷方案)** 或者内置 redis-plus-plus 库...
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** 从当前brpc代码支持ssl功能的实现上看，brpc框架本身承担了创建SSL_CTX对象的职责。 然而基于SSL本身的options非常的多，各个用户对于SSL的options要求也不一样以及同时SSL的版本也在不断更新等理由， 导致brpc支持ssl功能代码难以具备普遍性，无法适应新的变化 这个issue https://github.com/apache/brpc/pull/2251 就是一个直接的例子。 **Describe the solution you'd like (描述你期望的解决方法)** 我认为SSL_CTX对象的创建职责应该交给用户，rpc框架只负责SSL_CTX enable的情况下 做正确的handshake 和 TLS 读写功能即可： client: ``` SSL_CTX*...
堆栈如下，环境运行正常，网络良好，感觉是个老问题，和bug#1188有点相似，bug#1188这种问题，做网络延时就会频繁发生 gdb看，是id错误，得到block grop的为NULL，流程上是否在task thread中释放该资源时的id不对？？？释放资源时的id没有校验 #0 0x00007fb1e176d6fa in bthread::TimerThread::Bucket::schedule(void (*)(void*), void*, timespec const&) (__m=std::memory_order_consume, this=0x14008) at /usr/include/c++/4.8.2/bits/atomic_base.h:805 #1 0x00007fb1e176d6fa in bthread::TimerThread::Bucket::schedule(void (*)(void*), void*, timespec const&) (__m=std::memory_order_consume, this=0x14008) at /usr/include/c++/4.8.2/atomic:386 #2 0x00007fb1e176d6fa...
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** **Describe the solution you'd like (描述你期望的解决方法)** **Describe alternatives you've considered (描述你想到的折衷方案)** **Additional context/screenshots (更多上下文/截图)**
