公司去年上了F5,好用是好用，但是费用太高昂了，所以最近一直在研究软负载均衡这一块儿，恰巧今年年初谷歌开源了seesaw，让自己可以绕过很多弯路。特此总结下之前了解的负载均衡策略。 －Sunface
在分布式系统中，负载均衡是非常重要的环节，通过负载均衡将请求派发到网络中的一个或多个节点上进行处理。通常来说，负载均衡分为硬件负载均衡及软件负载均衡。硬件负载均衡，顾名思义，在服务器节点之间安装专门的硬件进行负载均衡的工作，F5便为其中的佼佼者。软件负载均衡则是通过在服务器上安装的特定的负载均衡软件或是自带负载均衡模块完成对请求的分配派发。
一般而言，有以下几种常见的负载均衡策略：
一.轮询。作为非常经典的负载均衡策略，早期该策略应用地非常广泛。其原理很简单，给每个请求标记一个序号，然后将请求依次派发到服务器节点中，适用于集群中各个节点提供服务能力等同且无状态的场景。其缺点也非常明显，该策略将节点视为等同，与实际中复杂的环境不符。加权轮询为轮询的一个改进策略，每个节点会有权重属性，但是因为权重的设置难以做到随实际情况变化，仍有一定的不足。
二.随机。与轮询相似，只是不需要对每个请求进行编号，每次随机取一个。同样地，该策略也将后端的每个节点是为等同的。另外同样也有改进的加权随机的算法，不再赘述。
三.最小响应时间。通过记录每次请求所需的时间，得出平均的响应时间，然后根据响应时间选择最小的响应时间。该策略能较好地反应服务器的状态，但是由于是平均响应时间的关系，时间上有些滞后，无法满足快速响应的要求。因此在此基础之上，会有一些改进版本的策略，如只计算最近若干次的平均时间的策略等。
四. 最小并发数。客户端的每一次请求服务在服务器停留的时间可能会有较大的差异,随着工作时间加长,如果采用简单的轮循或随机均衡算法,每一台服务器上的连接进程可能会产生较大的不同,并没有达到真正的负载均衡?最小并发数的策略则是记录了当前时刻，每个备选节点正在处理的事务数，然后选择并发数最小的节点。该策略能够快速地反应服务器的当前状况，较为合理地将负责分配均匀，适用于对当前系统负载较为敏感的场景。
五.哈希。在后端节点有状态的情况下，需要使用哈希的方法进行负载均衡，此种情况下情况比较复杂，本文对此不做探讨。
另外还有其他的负载均衡策略不再一一列举，有兴趣的同学可以自己去查阅相关资料。
分布式系统面临着远比单机系统更加复杂的环境，包括不同的网络环境、运行平台、机器配置等等。在如此复杂的环境中，发生错误是不可避免的，然后如何能够做到容错性，将发生错误的代价降低到最低是在分布式系统中必须要考虑的问题。选择不同的负载均衡策略将会有非常大的不同。
考虑下列的情况。完成请求需要如下四个集群，A,B,C,D，其中，假定完成调用需要调用集群B3次，B集群共有5台服务器。
当集群B中的某台服务器出现故障而导致无法提供服务，若集群中其他容错手段尚未生效，那么理想情况下，4/5的请求不受影响。
若采用轮询或随机的负载均衡策略时，单次请求派发到正常节点的概率为4/5,那么该请求成功的几率为1 (4/5) (4/5)*(4/5) = 64/125 约为 二之一，低于4/5的理想状态。
在因此，在此种情况下，若仅仅采用此种策略，会使故障的影响范围扩散，不符合预期。
若采用最小并发数的复杂均衡策略，假定正常一个请求需耗时10ms，超时时间设置为1s，那么，按照最小并发数的策略，异常节点的提供服务的能力为1，正常节点提供服务能力为100，则派发到异常节点的概率为1/(100 4+1)=1/401,该请求成功的几率为1(400/401)^3≈99.25%，高于4/5。
更加一般地，设集群中发生故障的故障机器的比例p，那么调用成功的预期概率为
整个请求需要调用k次，若采用轮询或随机的负载均衡策略，那么单次派发到正常节点的概率为
请求的成功率便会下降到
当k为3的时候，得到成功率f(p)与p的关系：
从上图可知，在p在增大的时候，请求的成功率f(p)便会有明显的下降，故而在对可靠性要求比较高的分布式系统中，不能简单地采用此种策略。 若采用最小并发数的策略，集群服务器的总数为m，假定异常情况下服务能力下降到正常的1/q，那么单位时间内，集群能提供服务的总数为
那么单次派发到正常节点的概率为:
请求的成功率则是上述值的k次方，即
当q=10，k=3时，可以得到请求成功率f(p)的图像:
从上图可知，当p在较小的区间内变化时(如(0,0.4])，随着p的增大,成功率f(p)并未有明显的下降，在每个节点可以承受服务压力的情况下，可以良好地处理多个节点故障的异常状况。
换个角度思考，再挖掘一下上述等式，若p为恒定，即集群中若已有一定数量的机器发生了故障。
当p=0.1,k=3时，可以得到成功率f(q)的图像:
从上图可知，服务的超时时间无须设置地过大，一般来说，设置为10倍的正常提供服务器时间即可。
另外，若是在异常情况非常快地被客户端感知到并反馈的时候(如客户端检查到后端某个节点配置错误等)，即q<1的时候，假定q=0.1,k=3的时候，可以得到如下关系：
在此种情况下，会导致失败大大提升，即使只有较小比例的集群出现异常，也会使得请求大量失败，故而还需要其他手段检测到此类型的异常。
针对这种情况，再考虑到网络波动及其他异常的状态，添加了移除异常节点的保护机制，当后端的某一个节点连续失败超过一定次数时，则就会移除该节点。但是该种策略亦存在因为用户输入错误或其他偶然因素导致返回失败而使得正常节点被移除的情况。考虑一下这种情况，假定这种返回异常的概率为1%，移除节点的失败次数的阀值为9，q=0.1，可用节点数为5，根据上述最小并发数的计算公式，可以得到派发到这一节点的概率为2/7，那么连续派发到该节点的概率为(2/7)^9≈0.001%，可以忽略掉这种异常情况。
在实际应用中，客户端的并发数可能存在一直维持在一个较低的水平上，由于客户端的并发数并不能代表服务端的并发情况，会造成在客户端并发数较小的情况下，服务端实际负载不均衡的状况。
故而，最小并发数的负载均衡策略不适用于在客户端做负载均衡，且客户端负载较小的情况。这种情况下，目前采用随机的方法解决负载不均衡的问题。 当然，在实际的分布式系统中，因为一个节点异常而导致其他节点的压力增大，可能会使其他节点的性能下降，他们之间的关系难以用上述的等式简单地描述。