「常见负载均衡算法」
❝
轮询法
❞
轮询法是最为简单的负载均衡算法，当接收到来自网络中的客户端请求后，负载均衡服务器会按顺序逐个分配给后端服务。
比如集群中有 3 台服务器，分别是 server1、server2、server3，轮询法会按照 sever1、server2、server3 这个顺序依次分发会话请求给每个服务器。当第一次轮询结束后，会重新开始下一轮的循环。
❝
随机法
❞
随机算法是指负载均衡服务器在接收到来自客户端的请求后，会根据一定的随机算法选中后台集群中的一台服务器来处理这次会话请求。
不过，当集群中备选机器变的越来越多时，通过统计学我们可以知道每台机器被抽中的概率基本相等，因此随机算法的实际效果越来越趋近轮询算法。
❝
原地址哈希法
❞
原地址哈希算法的核心思想是根据客户端的 IP 地址进行哈希计算，用计算结果进行取模后，根据最终结果选择服务器地址列表中的一台机器，处理该条会话请求。
采用这种算法后，当同一 IP 的客户端再次访问服务端后，负载均衡服务器最终选举的还是上次处理该台机器会话请求的服务器，也就是每次都会分配同一台服务器给客户端。
❝
加权轮询法
❞
加权轮询的方式与轮询算法的方式很相似，唯一的不同在于选择机器的时候，不只是单纯按照顺序的方式选择，还根据机器的配置和性能高低有所侧重，配置性能好的机器往往首先分配。
❝
加权随机法
❞
加权随机法和我们上面提到的随机算法一样，在采用随机算法选举服务器的时候，会考虑系统性能作为权值条件。
❝
最小连接数法
❞
最小连接数算法是指，根据后台处理客户端的连接会话条数，计算应该把新会话分配给哪一台服务器。
一般认为，连接数越少的机器，在网络带宽和计算性能上都有很大优势，会作为最优先分配的对象。
「利用 ZooKeeper 实现 负载均衡 算法」
❝
这里我们通过采用最小连接数算法，来确定究竟如何均衡地分配网络会话请求给后台客户端。
❞
如下图所示，建立的 ZooKeeper 数据模型中 Severs 节点可以作为存储服务器列表的父节点。
在它下面创建 servers_host1、servers_host2、servers_host3等临时节点来存储集群中的服务器运行状态信息。
整个实现的过程如下图所示。
-
首先，在接收到客户端的请求后，通过 getData 方法获取服务端 Severs 节点下的服务器列表，其中每个节点信息都存储有当前服务器的连接数。
-
通过判断选择最少的连接数作为当前会话的处理服务器，并通过 setData 方法将该节点连接数加 1。
-
最后，当客户端执行完毕，再调用 setData 方法将该节点信息减 1。
-
我们定义当服务器接收到会话请求后。在 ZooKeeper 服务端增加连接数的 addBlance 方法。
-
我们通过 readData 方法获取服务器最新的连接数，之后将该连接数加 1，再通过 writeData 方法将新的连接数信息写入到服务端对应节点信息中。
-
当服务器处理完该会话请求后，需要更新服务端相关节点的连接数。
-
具体的操作与 addBlance 方法基本一样，只是对获取的连接信息进行减一操作。
「这里注意：」
我们日常用到的负载均衡器主要是选择后台处理的服务器，并给其分发请求。
❝
而通过 ZooKeeper 实现的服务器，只提供了服务器的筛选工作。
❞
在请求分发的过程中，还是通过负载算法计算出要访问的服务器，之后客户端自己连接该服务器，完成请求操作。