Question

基于重定向的负载均衡，是指客户端首先请求负载均衡器，由负载均衡器根据算法向客户端返回需要实际处理业务的服务器信息，如 IP 地址、端口号或者更高层的应用层信息（在 HTTP 协议中表现为 URL 等），客户端直接根据该信息向后端服务器发起请求。该方案的一般网络时序图如图 3-8 所示。

图 3-8　基于重定向的负载均衡的一般网络时序图

对比图 3-6 和图 3-8 可以看出，基于 DNS 的负载均衡和基于重定向的负载均衡方案十分类似，都是通过第一次请求来获取实际负责处理的后端服务器的信息；不同之处在于，前者一般仅仅返回网络层 IP 信息或者 CNAME 等，后者可以提供更高层信息，同时后者的算法更趋于灵活，对业务适配性更优。

基于重定向的负载均衡方案具有和基于 DNS 的负载均衡方案基本相同的特点和使用场景，可以参照前述章节。

下载系统 HTTP 302 重定向

HTTP 302 重定向，是这种负载均衡方案的一个比较常见的使用方式。

图 3-9 所示为下载某个游戏客户端时的情形。

图 3-9　通过 HTTP 302 进行负载均衡的实例

通过 302 方法，不同用户访问该链接时，按照预先配置的比重（Weight），概率地引导到或者所示的实际下载地址，从而达到分流的目的。

以上演示了下载大型游戏客户端中使用重定向进行负载均衡的方法。

上传系统的重定向方法

在以上传为主的业务上，同样可以使用重定向进行负载分担、流量切分。

盛大游戏的备份系统采用了基于重定向的上传流量负载均衡调度方案。

业务需求是：游戏运营的服务器遍布全国多达数十个机房，每日的数据备份达到 TB 以上，该备份数据需要及时传输到备份中心。

在架构过程中需要思考的问题有以下几方面。

- 跨机房的网络通信问题，特别是跨不同运营商的互联互通问题。

- 上传接收节点的问题，单台服务器无法满足写入要求，多个接收服务器负载均衡的问题。

- 数据保留周期对集群容量的要求。

最终采用的方案如图 3-10 所示。

图 3-10　备份系统重定向负载均衡架构图

大致的工作流程如下。

1）客户端上传前，先请求负载均衡器（Load Balancer），获取接收机（Cell Server）的 IP。

2）客户端连接接收机进行数据上传。

3）Cell 把传输完成并经过完整性校验的备份文件中转到 Hadoop HDFS 集群中。

4）定时写入磁带。

负载均衡器的调度算法使用的是最小连接数方案，根据每台接收机当前的活跃连接数选择最小的一台进行分配。