基于nginx的负载均衡概述与实现

前言:

前面我们提到了lvs和keepalived结合起来的高可用负载均衡,lvs根据原目ip地址及端口将其调度转发至后端 的某个主机,是一种四层的实现,因为lvs是四层的,所以不会受限于套接字或打开的文件数量。不过,如果我们想实现一些更高阶的功能,lvs就显得力不从心了,比如基于uri,cookie,header头部信息的负载均衡,此时我们就可以选择一些7层的负载均衡实现,比如nginx或haproxy等。本次我们就先来讲讲nginx的负载均衡把~

正文:

其实,如果对lvs的各种类型和调度有清晰的认识,那么理解nginx的负载均衡并没有什么难度,无非就是监听前端server的ip和端口,并指定后端可调用的服务器地址就好~虽然nginx也有健康检测机制,但是只有在nginx plus中才能能使用。不过如果后端服务的端口不存在nginx倒也不会向其调用请求啦~那我们来具体说说把~

uostream

ngin的负载均衡得用到upstream模块,它用来定义一个后端服务器组,即把所有后端的服务器整合在一起,然后通过proxy代理到这个服务器组。就能实现简单的http负载均衡了,upstream默认的调度方式是wrr(具体内容可参考lvs中的介绍),所以我们只用指定服务器的ip,如果端口不是默认80端口也可以单独指定,还有一些调度用到的参数,比如权重。如果只是干巴巴的介绍也很抽象,我们就根据配置来介绍把~

http{
    ...
    upstream backserver {                   #backserver是一个自定义的名字,后面会调用
            server 172.16.53.101;           #第一个后端server
            server 172.16.53.102 ;          #第二个后端server
        }
    ...
    server {                                
        listen 80;
        server_name xiaofengfeng.cn;
        location / {
                proxy_pass      #代理到服务器组,此处只支持http/https 
                index index.html;
        }
}
}

上面就是一个最简单的基于nginx的服务均衡配置了。upstream 的server后面还可以加许多参数,比如设置不同的权值weight=number,权值越大调用的次数越多。backup参数可以设置backup server,比如我们可以设置本机为backup server,当后端服务器都不能访问的时候,我们本机可以提供一个sorry 页面。

 http{
     ...
    upstream backserver {
            server 172.16.53.101;
            server 172.16.53.102 ;
            server 127.0.0.1 backup; 
               #指定本机回环地址为备用server,此处我们提供一个sorry server
        }
    server {
            listen 192.168.157.128:80;   #代理服务只监听前端服务的ip和端口
            server_name xiaofengfeng.cn;
            location / {
                    proxy_pass  http://backserver;
                    index index.html;
            }
    }
    server {
            listen 127.0.0.1:80;          #回环地址用来做sorry server
            server_name xiaofengfeng2.cn;
            location / {
                    root /var/nginx;
                    index index.html;
            }
    }
}

注:因为我们改变了监听的ip所以得重启nginx服务,而不是用nginx -s reload。

除了server配置选项还有其他一些常用的,比如我们可以改变其调用算法为wlc,即least_conn,就会根据后端服务器的连接数来调用。如果我们的一些用户信息,比如说session,cookie等保存在后端服务器本地,为了放置用户信息丢失,我们可以让一个用户的请求都发送到同一个后端服务器。ip_hash就可以实现这样的功能。来自同一个源IP地址的请求始终发往同一个upstream
server。除了根据源地址hash,我们还可以指定特定的参数来作为hash的条件,比如,如果我们用uri作为hash条件,那么同一个uri的请求会发往同一台后端服务器。此时我们就要用到hash选项,比如:

hash $request_uri consistent

$request_uri是内置提供的变量,就是请求的uri咯,consistent是一致性哈希算法,这个倒是可以说道说道。我们知道哈希就是无论输入什么值,都会得到一个固定长度的散列值,我们对不同的uri求散列值,如果后端服务器有6台服务器,然后给他们进行编号0-6,然后用求的散列值对6做取余运算,就一定会得到0-6中的一个值,然后把这个分配给对应编号的服务器。不过,这个算法有个问题,如果某个服务器挂掉,我们就得重新以5来做取余运算,然后重新把所有过程从来一遍。所以就出现了上面的一致性哈希算法,我们现在先不关注后端有几台服务器,我们把0到2的32次方减一这个多个数字分布在一个圆环上,就上钟表上的0-12一样,0的地方就是12.然后我们对后端每个服务器的ip地址做哈希计算,得到的值在和2的32次方做取余运算,那么后端的这些服务器一定会分布在这个圆环上的某个点处,然后我们在对hash选项指定的内容,此处是uri做hash计算,得到的值在和2的32次方取余,所以这些uri也会分布在这个圆环上。然后我们规定,在这个圆环上分布的服务器,负责响应它到它下一个服务器的区间上分布的请求。此时当后端的某台服务器挂掉时,只会影响这台服务器后面的URI请求,而不会影响其他服务器,只用把属于这台服务器的请求,给它上一台就好,我们画个图说明下。

我们用方块表示后端服务器经过哈希计算的分布情况,用红色的线表示不同uri请求的分布情况,服务器1只用负责1到2之间的uri请求,以此类推,5只用负责5到1之间的uri请求,如右图所示,假如2号服务器挂掉了,我们就把所有属于2号服务器的请求分配给1号服务器~好啦~这就是一致性哈希算法~~~很重要哟,许多地方都有用到。

除了支持web服务的负载均衡,nginx还支持其他服务的负载均衡,此时我们就得用到另外d的模块stream和stream_proxy_module。不过这两个模块必须得是1.9.13以上的版本~并且默认stream并没有加载。得在编译时加入--with-stream选项,不过如果我们用的是预编译的rpm包安装的话,默认是有这个的~以下是/etc/nginx/nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}
stream {
        upstream sshsrvs {
                server 192.168.10.130:22;
                server 192.168.10.131:22;
        }

        server {
                listen 172.16.100.6:22202;
                proxy_pass sshsrvs;
                proxy_timeout 60s;
                proxy_connect_timeout 10s;
        }

}

我们启动或者重启nginx,然后我们就可以通过22202 访问后端的ssh服务了,mysql服务也类似~当然是轮询访问啦~和上面的web服务类似~

时间: 2024-10-26 00:08:45

基于nginx的负载均衡概述与实现的相关文章

基于nginx的负载均衡

1.场景 nginx3连接广域网其他服务器在内网 nginx 1      --------------------- /      \      \                              \ server 1   server 2   server3                      nginx3 <-- \       /      /                              / nginx 2    ----------------------

分布式存储之MogileFS基于Nginx实现负载均衡(Nginx+MogileFS)

MogileFS分布式文件系统特点: 1.具有raid的性能 2.不存在单点故障 3.简单的命名空间: 每个文件对应一个key:用于domain定义名称空间 4.不共享任何数据 5.传输中立,无特殊协议:可以通过NFS或HTTP进行通信 6.自动文件复制:复制的最小单位不是文件,而class 7.应用层: 用户空间文件系统,无须特殊的核心组件 Nginx+MogileFS的好处: 1.将请求代理至后端MogileFS服务器集群中,能实现负载均衡的效果.  2.能对后端的tracker节点进行健康

Linux 下 tomcat基于nginx做负载均衡

测试目的:在一台装有nginx服务器上访问nginx这台的ip地址,刷新一次就会显示后端三台不同的tomcat服务器的测试页. 测试环境:三台centos 6.8 一台 centos 7.3 软件版本: nginx 1.12.1 tomcat 8 软件部署的话 就不操作了 之前已经部署好了的,不会的话 看我之前的博客里都有. nginx 安装 http://dklwj.blog.51cto.com/9199080/1949570 tomcat 安装: http://dklwj.blog.51ct

使用nginx sticky实现基于cookie的负载均衡

在多台后台服务器的环境下,我们为了确保一个客户只和一台服务器通信,我们势必使用长连接.使用什么方式来实现这种连接呢,常见的有使用nginx自带的ip_hash来做,我想这绝对不是一个好的办法,如果前端是CDN,或者说一个局域网的客户同时访问服务器,导致出现服务器分配不均衡,以及不能保证每次访问都粘滞在同一台服务器.如果基于cookie会是一种什么情形,想想看, 每台电脑都会有不同的cookie,在保持长连接的同时还保证了服务器的压力均衡,nginx sticky值得推荐. 如果浏览器不支持coo

使用nginx sticky实现基于cookie的负载均衡【转】

在多台后台服务器的环境下,我们为了确保一个客户只和一台服务器通信,我们势必使用长连接.使用什么方式来实现这种连接呢,常见的有使用nginx自带的ip_hash来做,我想这绝对不是一个好的办法,如果前端是CDN,或者说一个局域网的客户同时访问服务器,导致出现服务器分配不均衡,以及不能保证每次访问都粘滞在同一台服务器.如果基于cookie会是一种什么情形,想想看, 每台电脑都会有不同的cookie,在保持长连接的同时还保证了服务器的压力均衡,nginx sticky值得推荐. 如果浏览器不支持coo

Nginx基于TCP的负载均衡的配置例子

原文:https://blog.csdn.net/bigtree_3721/article/details/72833955 nginx-1.9.0 已发布,该版本增加了 stream 模块用于一般的 TCP 代理和负载均衡. The ngx_stream_core_module module is available since version 1.9.0. This module is not built by default, it should be enabled with the -

Nginx的负载均衡方案详解

Nginx的负载均衡方案详解 作者:chszs,转载需注明.博客主页:http://blog.csdn.net/chszs Nginx的负载均衡方案有: 1.轮询 轮询即Round Robin,根据Nginx配置文件中的顺序,依次把客户端的Web请求分发到不同的后端服务器. 配置的例子如下: http{ upstream sampleapp { server <<dns entry or IP Address(optional with port)>>; server <&l

使用nginx+Apache负载均衡及动静分离

使用nginx+Apache负载均衡及动静分离 介绍    LB负载均衡集群分两类: LVS (四层)和 nginx或haproxy (七层)    客户端都是通过访问分发器的VIP来访问网站 在七层中的网站页面有: .php .html .png .jpeg .jsp 等, 有动态页面有静态页面. 需要在应用层基于不同的应用进行分发. 一:实验拓扑图:     二:实验目标 实战:使用Apache+nginx实现动静分离的负载均衡集群 三:实验环境 主机作用分类 主机名 IP地址 安装软件 N

基于Apache+Tomcat负载均衡的两种实现方法

Apache+Tomcat实现负载均衡的两种实现方法 如果我们将工作在不同平台的apache能够实现彼此间的高效通信,因此它需要一种底层机制来实现--叫做apr Apr的主要目的就是为了其能够让apache工作在不同的平台上,但在linux上安装apache的时候通常都是默认安装的 [[email protected] ~]#rpm -qi aprName                 :apr                                        Relocation