前言
负载均衡算法分类
- 任务平均类：负载均衡系统将任务平均分配给服务器进行处理，这里的平均可以是绝对的平均，也可以是加权的平均。
- 负载均衡类：负载均衡系统根据服务器的负载进行分配，这里的负载是指系统当前的压力，可以用CPU负载衡量，也可以用连接数、I/O使用率、网卡吞吐量来衡量。
- 性能最优类：负载均衡秕根据服务器的响应进行分配，优先分配给响应最快的服务。
- Hash类：负载均衡系统根据任务的的某些信息进行Hash运算，将相同的hash结果分配到同一台机器。常见的有源地址Hash、目标地址Hash、session id Hash、用户ID Hash。
轮询
负载均衡收到请求后，按照顺序轮流分配到服务器上。
轮询是最简单一个负载均衡策略，无须关注服务器本身的状态，也就是说只要服务器在运行，运行状态是不关注的。但是如果服务器挂掉了，或者服务器与负载均衡系统的连接断掉了，这时候负载均衡系统肯定要是能够感知到的，并且做出相应的处理，例如，将服务器从可分配服务器列表删除。
轮询的优点是简单，也是它的缺点。
加权轮询
负载均衡系统根据服务器权重进行任务分配，这里的权重一般根据服务器的硬件配置进行静态配置，也可以进行动态的方式计算会更加契合业务，但是也会更复杂。
加权轮询是轮询的一种特殊方式，主要是解决服务器配置差异的问题。
加权轮询解决了轮询算法中无法根据服务器配置进行任务分配的问题，但是仍然存在无法感知服务器状态的问题。
负载最低优先
负载均衡系统将任务分配给当前负载最低的服务器。这里的负载根据不同的任务类型和业务场景，可以用不同的指标来衡量。
- LVS这种4层网络负载均衡设备，可以用连接数来判断服务器状态，服务器连接数越大，表示服务器压力越大。
- Nginx这种7层网张负载均衡系统，可以用HTTP请求数来判断服务器状态(nginx默认的配置不支持这种算法)
- 如果自研的负载均衡系统，可以根据业务特点来选择衡量系统压力。如果是CPU密集型的，可以用CPU负载来衡量压力。如果是I/O密集型的，可以用I/O负载来衡量压力。
负载最低优先解决了轮询算法中无法感知服务器状态的问题，但同时也带来了复杂度问题。
最少连接数优先算法要求负载均衡系统统计每个服务器当前的连接，其应用场景仅限于负载均衡接收到的任何请求都会转给服务器处理，否则如果负载均衡系统与服务器进行固定连接的场景就不适用。例如：LVS可以采用这种算法，Mysql连接池就不可以采用这种算法。
CPU负载最低优先算法要求负载均衡系统收集每个服务器的CPU负载、而且要确定是以一分钟的负载为标准，还是以15分钟的负载为标准。注意，不存在一分钟比15分钟更好的问题。不同业务的最优时间间隔不一样。时间太短，容易产生波动，时间太长，又可以造成峰值来临感应慢的问题。
负载最低优先基本解决了无法感知服务器状态的问题，但是带来了复杂度上升的问题。负载最低优先虽然看起来美好，但是使用一般没有轮询使用的多。
性能最优类
负载最低优先是站在服务器的角度来分配的，而性能最优类是站在客户端的角度来分配的。优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的。
性能最优类也是感知服务器的状态，只是通过响应时间这个标准来衡量服务器状态而已。性能最优算法的复杂度体现在：
负载均衡系统要收统计每个服务器每个任务的响应时间，在大量任务的情况下，会消耗较多的性能。
为了减小这种统计上的消耗，可以采用采样的方式进行统计。即不统计所有的响应时间，而是抽样统计部分的响应时间，来估算整体的响应时间。采样统计减少了性能消耗，但是需要确认采样率，采样率低了无法估算，采用率高了会消耗将多性能。
无论是全部统计还是采样统计，都需要确认合适的周期。这个周期需要根据业务不断的调整，可能是10秒、5分钟等，没有一定的标准。
Hash类
负载均衡系统根据任务中的某些关键信息进行Hash,将相同的Hash值的请求分配到同一台服务器上，这样做主要是满足业务的需要。
- 源地址Hash
将同源于同一个源IP地址的任务分配到同一台服务器上处理，适合于事务和会话的业务。
- ID Hash
将某个ID标识的业务分配到同一台服务器上处理，这里的ID一般是临时性数据的ID(如Session ID)。
