Nginx笔记(四)

代理一组服务器
  • 使用upstream指令来定义一组服务器,指令放在http context里
    • 如:

      http {
          upstream backend {
              server backend1.example.com weight=5;
              server backend2.example.com;
              server 192.0.0.1 backup;
          }
      }
      
  • 使用proxy_pass指令把请求打到被代理的服务器上
    • 如:

      server {
          location / {
              proxy_pass http://backend;
          }
      }
      
选择一种负载均衡方法
  1. 默认的是权重轮询算法,nginx会按照各个server的权重比来分发请求。
    • 如:

      upstream backend {
         server backend1.example.com;
         server backend2.example.com;
      }
      
  2. 最少连接法:每次都选择连接数组少的server,如果有多个server的连接数相同,再根据这几个server的权重分发请求。
    • 例:

      upstream backend {
          least_conn;
      
          server backend1.example.com;
          server backend2.example.com;
      }
      
  3. ip哈希:使用IPv4的前三个八字节位或者IPv6的全部来计算哈希值,所以相同地址的请求始终会打到相同的Server上,除非这个server不可用。
    • 如果一个server需要暂时移除,使用down参数来避免请求打到这台机器上,应该哈希到这台机器上的请求会自动的发送到组里的下一台。

    • 如:

      upstream backend {
          ip_hash;
      
          server backend1.example.com;
          server backend2.example.com;
          server backend3.example.com down;
      }
      
  4. 哈希:使用自定义的key去进行哈希计算。
    • 通过consistent参数使用ketama一致哈希算法来减少增减服务器对客户端的影响。
      • 例:

        upstream backend {
            hash $request_uri consistent;
        
            server backend1.example.com;
            server backend2.example.com;
        }
        
      • 上面的就是通过uri进行哈希计算。

  5. 最小响应时间:对于每个请求,nginx选择平均等待时间最小并且连接数最少的。
    • 通过least_time的参数来确定平均等待时间的计算方式。

      • header: Time to receive the first byte from the server
      • last_byte: Time to receive the full response from the server
    • 如:

      upstream backend {
          least_time header;
      
          server backend1.example.com;
          server backend2.example.com;
      }
      
服务器权重
  • 默认的权重是1,通过weight参数来指定权重值。

  • 通过backup来标记备用服务器,如果其他的都宕机了,请求会打到备用的服务器是上。

  • 例:

    upstream backend {
        server backend1.example.com weight=5;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
    
服务器慢启动
  • 对于刚刚恢复的服务器,如果一下子被请求淹没可能会再次宕机。

  • 可以通过server指令的slow_start参数来让其权重从0缓慢的恢复到正常值。

  • 例:

    upstream backend {
        server backend1.example.com slow_start=30s;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
    
  • 注意如果一个组里面只有一个server,那么max_fails,fail_timeout和slow_start参数都会被忽略。并且这个服务器永远都不会被认为是不可用的。

Enabling Session Persistence
  • Session持久性是指nginx识别客户端的session然后把同一个session的请求路由到同一个server上。
  • nginx支持三种session持久的方法,通过sticky指令去设置。
    • sticky cookie方法。通过这种方法,当server第一个响应的时候,nginx添加一个cookie来标识是哪个server响应的,当它下次请求的时候,会带着cookie,nginx会把请求路由到同一台server。

      • 例:

        upstream backend {
            server backend1.example.com;
            server backend2.example.com;
        
            sticky cookie srv_id expires=1h domain=.example.com path=/;
        }
        
    • sticky_route方法,使用这种方法,nginx第一个收到请求的时候会给客户端下发一个路由。后续的请求都会带着路由参数,nginx再来判断请求该打到哪个server上。路由信息可以通过cookie或者uri获取到。

      • 例:

        upstream backend {
            server backend1.example.com route=a;
            server backend2.example.com route=b;
        
            sticky route $route_cookie $route_uri;
        }
        
    • cookie learn 方法。通过这种方法,nginx通过检测请求和响应来寻找session标记。通常,这些标记通过cookie传递。如果一个请求的包含的session标记已经learned,nginx将会把请求打到正确的server上。

    • 例:

      upstream backend {
         server backend1.example.com;
         server backend2.example.com;
      
         sticky learn 
             create=$upstream_cookie_examplecookie
             lookup=$cookie_examplecookie
             zone=client_sessions:1m
             timeout=1h;
      }
      
    • 在这个例子中,server通过在响应中设置一个"EXAMPLECOOKIE"来标记一个session。

    • create的参数指定一个变量来指示一个session的创建,在这个例子中,server发送"EXAMPLECOOKIE"表示新的session建立。

    • lookup的参数指定如何寻找一个已经存在的session,在这个例子中,通过查找客户端的"EXAMPLECOOKIE"来搜索现有的session。

    • zone 指定一块共享的内存来保存sticky sessions的信息。上个例子中,这块空间叫做client_sessions,大小为1M。

限制连接数量
  • 可以通过max_conns参数来限制连接数,如果达到了最大连接数,请求就可以放到通过queue指令生命的队列中来等待后续的处理 ,queue指令设置了可以放到队列中得最大的请求数、

  • 例:

    upstream backend {
        server backend1.example.com  max_conns=3;
        server backend2.example.com;
    
        queue 100 timeout=70;
    }
    
  • 如果队列排满或者在可选参数timeout设置的时间内无法选择上游服务器,客户端将接到一个错误。

  • 注意如果闲置的keepalive连接在另一个worker processes中打开了max_conns限制会被忽略。导致的结果是,在多个工作进程共享内存的配置中,连接的总数可能会超过max_conns的值。

被动的健康监测
  • 当nginx认为一个server不可用,它会暂时停止向这个server转发请求直至nginx再次认为它是可用的。

  • nginx通过两个参数来控制nginx的判断

    • fail_timeout,当在fail_timeout时间段内,失败次数达到一定数量则认为该server不可用。并在接下来的fail_timeout时间内不会再将请求打到这个server上。 - max_fails,这个max_fails就是上面说的失败的一定数量。
  • 默认的值是10秒和1次尝试。

  • 例:

    upstream backend {                
        server backend1.example.com;
        server backend2.example.com max_fails=3 fail_timeout=30s;
        server backend3.example.com max_fails=2;
    }
    
主动的心跳检测
  • 使用health_check指令来检测server是否可用,除此之外还要使用zone指令。

  • 例:

    http {
        upstream backend {
            zone backend 64k;
    
            server backend1.example.com;
            server backend2.example.com;
            server backend3.example.com;
            server backend4.example.com;
        }
    
        server {
            location / {
                proxy_pass http://backend;
                health_check;
            }
        }
    }
    
  • 在上个例子中,nginx每五秒请求一次backend组里的每台机器,请求地址是"/",如果失败或者超时(或者返回的状态码不是2xx或者3xx),nginx就认为这个server宕机了。nginx将停止向它转发请求,直至其再次通过心跳检测。

  • 可以通过参数控制health_check指令的行为。

  • 例:

    location / {
        proxy_pass http://backend;
        health_check interval=10 fails=3 passes=2;
    }
    
  • 上个例子是每十秒检测一次,如果失败了3次就认为宕机了,如果成功2次就认为通过了检测。

  • 也可以检测特定的uri

  • 例:

    location / {
        proxy_pass http://backend;
        health_check uri=/some/path;
    }
    
  • 通过match块自定义成功的状态。

    http {
        ...
    
        match server_ok {
            status 200-399;
            body !~ "maintenance mode";
        }
    
        server {
            ...
    
            location / {
                proxy_pass http://backend;
                health_check match=server_ok;
            }
        }
    }
    
  • 上个例子中要求status在200到399之间,并且body满足提供的正则表达式。

  • match块中可以包含一个status的状态,一个body的状态和多个header的状态。

    match welcome {
        status 200;
        header Content-Type = text/html;
        body ~ "Welcome to nginx!";
    }
    
  • 使用!

    match not_redirect {
        status ! 301-303 307;
        header ! Refresh;
    }
    
  • 上个例子表示status不是301、302、303或者307,并且header中不包含Refresh。

至此Nginx笔记结束,了解了这些后,对于看懂一个Nginx的配置,了解Nginx能够实现什么功能和对其进行小改应该会有一定的帮助。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容