nginx负载均衡的策略:
1.轮询(默认方式)
对于一级后端服务器群,形成一个环队列的形式,对于每个到达的请求按时间顺序顺次分配给这些后端服务器。在前端调度器与后端服务器之间采用“心跳”方式进行状态检查,如果发现后端服务器宕机,则将其删除。
这种方式为默认配置,优点是简洁,但缺点是无法进行最优化调度,有可能有的请求需要耗时较久,这样会带来一定的不平衡。
它的例子:在http区域里添加:
upstream lb {
server 10.10.57.122:80;
server 10.10.57.123:80;
}
在你的某个server里增加:
location / {
proxy_pass http://lb;
}
2. 加权轮询
这是一种对上述方式的改进,引入权值的概念,能够解决后端服务器性能不均的情况。
例如这样一个配置:
upstream lb {
server 10.10.57.122:80 weight=5;
server 10.10.57.123:80 weight=10;
}
ps:以上轮询负载均衡策略,我个人认为对于动态网站应用,这几乎就是形同摆设,没有人会采用。但一种情况例外:服务器端的session采用共享机制,如存储在数据库或者memcached内存里等。
3. ip_hash(基于ip的hash分配策略)
这是一种非轮询式方式,对于每个到达的请求,直接通过其请求IP进行哈希的映射,通过映射结果获得那一台后端服务器要处理这个请求,这种方式有一个明显的好处是能够保证session的唯一性。
它的配置例子:
upstream lb {
ip_hash;
server 10.10.57.122:80;
server 10.10.57.123:80;
}
在你的某个server里增加:
location / {
proxy_pass http://lb;
}
4. url_hash(基于URL的哈希方式)
这种方式与IP的哈希方式类似,是对客户机请求的URL进行哈希操作,这样的方式有一个明显的好处是,能够便于内容缓存的实现,对于经常性的资源访问,采用这样的方式会获得非常好的质量。它目前不是nginx自带的功能,需要安装补丁方可使用。本指令的详细说明和安装见:(文章后面有附带详细安装实例)
http://wiki.nginx.org/HttpUpstreamRequestHashM odule
它的配置方式为:
upstream lb {
server 10.10.57.122:80;
server 10.10.57.123:80;
hash $request_uri;
}
如果将这里的$request_uri换成$remote_addr便可实现上面我所说的真正基于ip地址的策略。
5. 基于服务响应式
这种方式是根据服务器端的动态响应,对每一个请求进行分配。 这种方式能够自动根据当前的后端实际负载来优化。
它的配置方式:
upstream lb {
server 10.10.57.122:80;
server 10.10.57.123:80;
fair;
}
这个没怎么测试,只是配起来用了下,机器差不多的话感觉就是轮询。
===============================
cd nginx-0.7.67;
patch -p0 < ../nginx_upstream_hash-0.3.1/nginx.patch
configure时:
./configure --prefix=/app/nginx -user=nobody -group=nobody \
--add-module=../nginx_upstream_hash-0.3.1/ \
--add-module=../gnosek-nginx-upstream-fair-2131c73/
1.轮询(默认方式)
对于一级后端服务器群,形成一个环队列的形式,对于每个到达的请求按时间顺序顺次分配给这些后端服务器。在前端调度器与后端服务器之间采用“心跳”方式进行状态检查,如果发现后端服务器宕机,则将其删除。
upstream lb {
}
在你的某个server里增加:
location / {
2. 加权轮询
ps:以上轮询负载均衡策略,我个人认为对于动态网站应用,这几乎就是形同摆设,没有人会采用。但一种情况例外:服务器端的session采用共享机制,如存储在数据库或者memcached内存里等。
3. ip_hash(基于ip的hash分配策略)
upstream lb {
}
在你的某个server里增加:
location / {
4. url_hash(基于URL的哈希方式)
http://wiki.nginx.org/HttpUpstreamRequestHashM
upstream lb {
如果将这里的$request_uri换成$remote_addr便可实现上面我所说的真正基于ip地址的策略。
5. 基于服务响应式
upstream lb {
这个没怎么测试,只是配起来用了下,机器差不多的话感觉就是轮询。
===============================
cd nginx-0.7.67;
patch -p0 < ../nginx_upstream_hash-0.3.1/nginx.patch
configure时:
./configure --prefix=/app/nginx -user=nobody -group=nobody \
--add-module=../nginx_upstream_hash-0.3.1/ \
--add-module=../gnosek-nginx-upstream-fair-2131c73/