jamesge
jamesge
而不是sleep-spin（可能死锁）。 Update: bthread中的ready_to_run等一系列函数接口需要重新设计，主要是要传入TaskGroup** pg，也就是说这些函数可能导致调用的bthread做上下文切换。如果这么实现的话，一方面规避了可能的死锁，另一方面对创建bthread的频率做了throttle，wsq的capacity可以进一步调小。
可以理解为“由多个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数也不会减少，从而让框架选择其他连接。
C++可以原生用。再用brpc写一个原始redis协议到cluster协议的proxy，供其他语言的server同机或同容器部署。 优点： * 官方方案会持续更新。 * 没有走网络流量的proxy层，省延时、带宽。C++实现开销最小化。 * proxy比较轻，侵入性不大，开发和部署都相对简单，可控。 缺点: * Redis cluster的运维、扩容、debugging复杂度较高。 * redis cluster的集群扩展性有限。
h2c/grpc遗留问题
- [ ] 明确一些边缘header的设置规则，比如[grpc-]accept-encoding, grpc-timeout - [ ] 改进server端判定client端是否支持gzip的方法，client端不一定要设置accept-encoding - [x] grpc不支持application/grpc+json - [ ] 考虑移除x-bd-error-code x-bd-log-id等字段的可行性。 - [ ] http/h2c支持snappy压缩。(deflate就没必要支持了） - [x] http_verbose排版不对，且不是原子写出，多线程下可能交叉 - [x] protocol支持传递协议参数 - [ ]...