在某些成员节点失效时，负载均衡器会如何处理已有TCP连接？

    作为负载均衡设备的系统管理员，经常遇到的问题是pool中配置的member或者说service的监控状态为失败(down)了。我们知道，负载均衡器会禁用这个失效的节点，把新的流量发送给pool中其他可用节点。但是，已经跟这个失效节点发起的连接请求，会如何处理呢？

    从提高用户体验的角度来看，也许让已有连接继续进行，直至正常结束（或者被动结束）会比较合适。F5的bigip正是这么处理的。bigip的pool对象有一个高级属性，叫Action on Service Down。其有4个可选值，分别是Reject, Drop, Reselect，与None。默认值为None，即不做处理，让已有连接继续，直至自然结束。

    优点：某些情况下，一个节点本身正常运行，但lb上的monitor因为各种因素，导致误报down。这种情况下，用户连接得以保留，等已有连接处理完毕后，新的请求又发至pool中其他良好节点，用户体验不受影响。

    另外一种更常见的情况是，代码发布人员在发布新版本前需要将这个节点的ECV check人为设置成disabled，让其在LB上失效，进而开始更新代码。实际上monitor失败后，这些节点依旧是可以正常处理客户请求的。这种情况下，保留已有连接的理由更加充足。这种情形，估计占到service down情况总量的80%以上。

    缺点：若即非代码更新维护，该节点也确实无法正常响应，则已有连接会继续进行一段时间直至TCP超时，无法像即时结束已有连接那样干脆利落的将用户引导至新的可用节点。

    另外说一下netscaler。与bigip不同，ns的默认设置是即时中断已有连接。配置属性名称是DownStateFlush，在配置service时可选。默认值为Enabled。若需要像bigip那样保持已有连接，则可以设置DownStateFlush为disabled。

    更好的用户体验，就是网络工程师最大的价值所在！