深入分析流媒体服务器负载均衡的两种机制

前面我们对流媒体服务器的负载均衡内容作了一个概述，相信大家已经对这个知识有了一定的认识。那么现在我们来仔细分析一下它的系统设计和机制问题。从原理上面看看流媒体服务器的负载平衡时如何做到，那么具体的内容还请大家从文章中了解吧。

流媒体服务器中的负载均衡系统设计

流媒体服务器中的负载均衡系统是在基于LAN的分布式体系结构下实现的负载均衡,所有来自客户端的请求被透明地分配到若干服务器上｡对用户而言,整个分布式系统仿佛是台单一的逻辑服务器｡这样的集群系统能够提供较强的可扩展性和较好的吞吐性能｡从商业角度而言,不仅可以保护原来的投资,而且也可以通过廉价的集群系统获得高性能计算机所能达到的处理能力｡

然而要使这样的集群系统保持较高的资源利用率面临一定挑战｡例如,现有的负载均衡方法都不能很好地解决本系统中涉及的问题,最早的负载均衡技术是通过 DNS来实现的,在DNS中为多个地址配置同一个域名,从而查询该域名的客户机将访问不同的服务器,达到负载均衡的目的｡ DNS负载均衡虽然简单而有效,但它不能区分服务器的差异,也不能反映服务器的当前运行状态｡

有人采用反向代理服务器进行请求转发的方法,该方法虽然能够应用优化的负载均衡策略,使每次服务均由最空闲的内部服务器来提供,以达到负载均衡的目的｡但随着并发连接数量的增加,代理服务器本身的负载也变得非常大,反向代理服务器本身反而会成为服务的瓶颈｡还有人采用支持负载均衡的地址转换网关的方法,可以将一个外部IP地址映射为多个内部IP地址,对每次请求动态使用其中一个内部地址,达到负载均衡的目的｡

很多硬件厂商将此技术集成在设备中,采用随机选择､根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载,然而硬件实现的负载控制器灵活性不强,不能支持更优化的负载均衡策略和更复杂的应用协议｡还有负载均衡方法是在某些协议内部实现的,例如HTTP协议中的重定向功能等,但它依赖于特定协议,因此使用范围有限｡

流媒体服务器中采用的基于分配器的负载均衡机制

基于分配器的负载均衡机制是IP/TCP/HTTP的重定向分配｡一般需要一个特殊的前端节点,称为分配器(dispatcher)｡所有的客户端请求都经过分配器并由它分配到后端服务器处理｡这种基于分配器的请求分配机制通常对客户端是透明的,采用的机制有两种:

一种称为中继机制(relaying),如图1所示,客户端请求到达分配器后,由分配器按定的负载分配算法,将请求传递给被选中的服务器｡服务器处理后的结果传回至分配器,再由分配器转发给客户端｡分配器的工作通常在操作系统的应用层完成,也有修改操作系统核心直接支持中继机制的系统,其性能会有所改善,这种优化的方法称为TCP衔接(TCP splicing);

图1. 中继机制示意图

另外一种机制称为TCP传递(TCP handoff),如图2所示,客户端的请求经过分配器分配到达服务器,服务器将处理后的结果不经过分配器而直接发送给客户端｡中继或TCP衔接机制要求所有的通信均要经过分配器(特别是处理结果信息量很大的情况下),因此容易在分配器形成通信瓶颈,TCP传递机制避免了这一问题,因此性能更好,但是需要对前端和后端节点进行修改,以支持TCP handoff ｡

图2. TCP传递机制示意图