过程描述
当用户向服务器发起请求时, 请求首先被集群调度者截获; 调度者根据某种分配策略, 选择一台服务器, 并将选中的服务器的 IP 地址封装在 HTTP 响应消息头部的 Location 字段中, 并将响应消息的状态码设为 302, 最后将这个响应消息返回给浏览器.
当浏览器收到响应消息后, 解析 Location 字段, 并向该 URL 发起请求, 然后指定的服务器处理该用户的请求, 最后将结果返回给用户.
在使用 HTTP 重定向来实现服务器集群负载均衡的过程中, 需要一台服务器作为请求调度者. 用户的一项操作需要发起两次 HTTP 请求, 一次向调度服务器发送请求, 获取后端服务器的 IP, 第二次向后端服务器发送请求, 获取处理结果.
调度策略
调度服务器收到用户的请求后, 究竟选择哪台后端服务器处理请求, 这由调度服务器所使用的调度策略决定.
随机分配策略
当调度服务器收到用户请求后, 可以随机决定使用哪台后端服务器, 然后将该服务器的 IP 封装在 HTTP 响应消息的 Location 属性中, 返回给浏览器即可.
轮询策略 (RR)
调度服务器需要维护一个值, 用于记录上次分配的后端服务器的 IP. 那么当新的请求到来时, 调度者将请求依次分配给下一台服务器.
由于轮询策略需要调度者维护一个值用于记录上次分配的服务器 IP, 因此需要额外的开销; 此外, 由于这个值属于互斥资源, 那么当多个请求同时到来时, 为了避免线程的安全问题, 因此需要锁定互斥资源, 从而降低了性能. 而随机分配策略不需要维护额外的值, 也就不存在线程安全问题, 因此性能比轮询要高.
优缺点分析
采用 HTTP 重定向来实现服务器集群的负载均衡实现起来较为容易, 逻辑比较简单, 但缺点也较为明显.
在 HTTP 重定向方法中, 调度服务器只在客户端第一次向网站发起请求的时候起作用. 当调度服务器向浏览器返回响应信息后, 客户端此后的操作都基于新的 URL 进行的 (也就是后端服务器), 此后浏览器就不会与调度服务器产生关系, 进而会产生如下几个问题:
由于不同用户的访问时间, 访问页面深度有所不同, 从而每个用户对各自的后端服务器所造成的压力也不同. 而调度服务器在调度时, 无法知道当前用户将会对服务器造成多大的压力, 因此这种方式无法实现真正意义上的负载均衡, 只不过是把请求次数平均分配给每台服务器罢了.
若分配给该用户的后端服务器出现故障, 并且如果页面被浏览器缓存, 那么当用户再次访问网站时, 请求都会发给出现故障的服务器, 从而导致访问失败.
来源: http://www.jianshu.com/p/d012e370d222