负载均衡方式

1. 随机（Random）选择

从地址列表中随机选择一台，这种方法实现起来最为简单，性能也最高，在实际运行中，如业务处理机器在处理各种请求时所需消耗的各种资源相差不是特别大，那么采用随机方式能保持后端的机器的负载基本上是均衡的。

2. Hash选择

即对应用层的请求信息做hash，从而分派到相应的机器上，典型的应用场景是静态图片的加载。对请求的图片的url串做hash,这样基本可以保证每次请求的是同一台机器，命中缓存，提升性能，这种方式多用于以上类型的应用场景。值得注意的是，由于他要读网络协议第七层（即应用层）的信息，又要做hash，因此要消耗更多的CPU资源并导致些许的性能下降。

3. Round-Robin选择

根据地址列表按顺序选择。由于要保持顺序，这种方式在选择时比随机多了一个同步操作，由于这个同步操作时间非常短，性能上损失很小，和随机方式一样，如业务处理机器在处理各种请求时所需消耗的各种资源相差不大，那么采用顺序方式也是基本上可以保持后端实际业务处理机器负载时均衡的，这种方式目前的硬件负载和软件负载都支持，实际使用较多。

4. 按权重（Weight）选择

根据每个地址的权重进行选择权重有静态权重和动态权重两种。
静态权重是指配置好集群中各机器的权重，在运行时会根据这个配置选址。当集群中机器档次不同时，可以给配置高的机器分配更高的权重，更好地利用机器性能。对于权重相同的多台机器，通常又支持按随机或顺序的方式选择，静态权重适用于仅按机器配置来分配机器承担的请求比例的业务场景。
动态权重是指负载均衡设备或软件根据业务处理机器的load、连接数等动态权重来分配任务，以更加合理地发挥业务处理机器的性能，动态权重适用于根据运行状况分配承担请求比例的业务场景。

5. 按负载（load）选择

根据实际业务处理机器的负载来选择。选择负载相对较低的机器来进行处理，尽可能地保证所有业务处理机器的负载是均衡的。此方法适合于业务处理机器在处理多种请求时所需资源相差较大的情况。它可以避免将资源消耗多的请求都分配到同一台机器上，出现虽请求分配均衡，但负载严重不均衡的情形，这就要求负载均衡机器每隔一段时间就向实际的业务处理机器收集其负载的情况，这种方式会给负载均衡机器增加一些负担，并且一旦收集负载均衡状况过程中出现较大延时或搜集不到时，很可能造成更严重的负载不均衡，因此在实际的应用中使用较少。

6. 按连接（connection）选择

根据实际业务处理机器连接数的多少来选择，选择连接数相对较少的机器来处理业务，此方法适用于连接数不均衡的场景中。实现这个方法只是增加了连接数对可用地址列表做排序的负担，其他方面不会有太多影响。如使用这种方式，要特别注意类似下面的场景：假设后端业务处理的机器是10台，现在每台机器上的连接数大概是1000，这时若重启一台，采用按连接数这种负载均衡算法，且瞬间请求量大，那么1000个请求会同时发到新启动的这台机器上，这很有可能造成这台机器宕掉，因此这种方式在实际应用中使用较少。

7. 按cookie信息绑定访问相同机器

只需要把相关用户信息缓存到各自机器上，避免需要引入分布式缓存等复杂技术。但会带来的问题是，一旦机器出现故障，在该机器上登录过的用户就需要重新登录。