multi连接方式

可以理解为“由多个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数也不会减少，从而让框架选择其他连接。