简单记录下Load Balance的基础知识。

1. Load Balance方法

HTTP反向代理负载均衡

这是我们最常见的一种,就是使用Nginx类的服务器在HTTP层面对后台应用服务器进行反向代理。

优点:重点是简单,而且足以满足一般应用,所以实际上我们接触的比较多。

缺点:主要是性能上会有压力,反向代理服务器本身的并发和吞吐能力都是有限的。

HTTP重定向负载均衡

请求服务器,由服务器计算合适的新的服务器用302重定向返回。

这种代理方式缺点有很多,一次请求变成两次,而且用来重定向的服务器也需要来计算返回,并且不利于SEO的收集。

DNS负载均衡

这个一般在大型网站或者CDN服务提供商那里比较常见,主要是根据用户的IP就近指向的最近的机房IP。

优点:解决由机房物理距离过远带来的延迟。

缺点:成本高,DNS有缓存,IP变化很危险。

TCP负载均衡

反向代理主要是发生在HTTP层的中间代理,可以把这个转发过程下降到TCP,这一层的典型代表应该是HAProxy了。

优点:除了由应用层下降到TCP层带来的性能优势之外,对IP数据包进行转发还有一个优势是除了HTTP协议还可以对其他协议进行负载均衡,例如数据库连接,redis连接这种。

缺点:实际上本质问题和HTTP反向代理是一样的,那就是说所有的流量都会经过代理服务器,对代理服务器还是有一定的要求的。

链路层负载均衡

这个是又下降了,按OSI模型来说应该是第二层的协议,主流代表是LVS。这个的模型跟其他的模型有些不一样,其他的请求和返回的流量都要经过中间的代理服务器。而这个只有请求的流量会经过代理服务器,返回的流量可以直接返回到客户端。

优点:性能基本是几种方案里面最好的。

缺点:过于底层实际上对使用人员有一定的要求的,例如Nginx的反向代理基本上不需要掌握太多的网络知识,如果想使用LVS可能要多了解一些相关内容。

2. Load Balance算法

轮询

轮询就是从上到下依次派发请求,而且由基本的轮询还衍生出一种加权轮询。以nginx为例:

例如IP为101的机器性能比较好,可以把更多的请求分配到101上。

# 轮询

upstream app {
    server 192.168.1.101;
    server 192.168.1.102;
    server 192.168.1.103;
}

# 加权轮询
upstream app {
    server 192.168.1.101 weight=3;
    server 192.168.1.102;
    server 192.168.1.103;
}

在上面的加权轮询过程中 如果有6个请求会依照101,101,101,102,103的顺序派发。

最少连接

根据后端服务器连接数最少进行选择,还是以nginx为例:

upstream app {
    least_conn;
    server 192.168.1.101;
    server 192.168.1.102;
    server 192.168.1.103;
}

hash

根据请求的某些特征值进行hash运算来达到把一个人的请求分配到同一台服务器上的算法,例如在app内保存session这种应用是很有必要的。

(当然在app内保存session并不好,这样就让app有了状态,无状态的app会有更好的伸缩性。)

nginx本身默认只支持对请求的ip进行hash运算,淘宝的tengine支持包括对更多参数的hash算法。

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

其他几种常见的负载均衡技术包括HAProxy,LVS和keepalived都值得看一下,额外的说一句,nginx plus也是支持TCP层的负载均衡的,不过是收费服务了。