http://nginx.org/en/docs/http/ngx_http_upstream_module.html憎亚，以及一些自己的理解（不見得正確!!!）。
這個模塊有很多指令，包含在如下：
? upstream;server;zone;state;hash;ip_hash;keepalive;ntlm;
? least_conn;least_time;health_check;match;queue;sticky;
? sticky_cookie_insert;
包含內(nèi)嵌變量如下：
$upstream_addr刨沦；$upstream_bytes_received；$upstream_cache_status；
$upstream_connect_time；$upstream_cookie_name癣疟；$upstream_header_time；
$upstream_http_name潮酒；$upstream_response_length睛挚；$upstream_response_time；
$upstream_status
先來一個例子：
upstream backend {
server backend1.example.com? ? ? ?weight=5; ?//比重為5急黎，未設(shè)置的默認為1
server backend2.example.com:8080; ?//帶端口的扎狱，未設(shè)置的默認為80
server unix:/tmp/backend3; ? ? ? ? //設(shè)置的是Unix的socket連接，比TCP的要更快一點
server backup1.example.com:8080? ?backup; ?//backup標(biāo)識這它為備份后端勃教，只有前面的掛掉了淤击，才會啟用備份后端
server backup2.example.com:8080? ?backup;
}server {
location / {
proxy_pass http://backend; ?//這里使用了HTTP方式。
}
}
另一個示例：
resolver 10.0.0.1;
upstreamdynamic{
zone upstream_dynamic 64k;
server backend1.example.com? ? ? weight=5;
server backend2.example.com:8080 fail_timeout=5s slow_start=30s;
server 192.0.2.1? ? ? ? ? ? ? ? ?max_fails=3;
server backend3.example.com? ? ? resolve;
server backend4.example.com? ? ? service=http resolve;
server backup1.example.com:8080? backup;
server backup2.example.com:8080? backup;
}server {
location / {
proxy_pass http://dynamic;
health_check;
}
}
指令介紹：
upstream
Syntax:? ? ?upstream name { ... }
Default:? ? ?—
Context:? ? ?http
定義一組server故源，每個server可監(jiān)聽不同的端口污抬，而且可以混著監(jiān)聽TCP和Unix域 socket。
如：
upstream backend {
server backend1.example.com weight=5; ? //監(jiān)聽TCP绳军，未設(shè)置端口印机，默認端口為80
server 127.0.0.1:8080? ? ? ?max_fails=3 fail_timeout=30s; //監(jiān)聽TCP ? max_fails 和 fail_timeout 在后面再講。
server unix:/tmp/backend3; //監(jiān)聽socket
server backup1.example.com? backup;
}
默認情況下门驾，Nginx使用輪詢（round-robin）的方式來做server的負載平衡尋址射赛，上面的例子中，server1比重占5奶是，后面2個server比重各占1楣责，也就是說平均下來每7個請求會有5個請求走到server1（概率上來講，統(tǒng)計上來講聂沙，實際上在某個特定長度的時間段里腐魂，不見得是完全符合這一的規(guī)律）。如果被請求的server發(fā)生了錯誤類似超時之類的逐纬，總之是無法提供服務(wù)了蛔屹，Nginx就會尋找下一個服務(wù)(下一個服務(wù)還是按輪詢來找，還是按配置順序來找豁生？）兔毒，直到嘗試所有server，只要有一個server能提供服務(wù)甸箱，Nginx就能對外提供服務(wù)育叁，如果所有的server都不能提供服務(wù)，則Nginx也不能對外提供服務(wù)了芍殖。
server
Syntax:? ? ?server address [parameters];
Default:? ? ?—
Context:? ? ?upstream ? ?//其實在HTTP,stream,upstream里都有自己的server指令豪嗽，所有談到server指令，首先要分清楚它的上下文(context)是什么。
配置server的地址和參數(shù)龟梦，地址可以使用域名或IP隐锭，可以攜帶端口，端口是可選的计贰，如果未攜帶端口钦睡，默認為80。地址也可以使用Unix域socket躁倒，路徑以
"unix:"為前綴荞怒。一個命名域名可以一次性解析多個server定義的IP（A domain name that resolves to
several IP addresses defines multiple servers at once.）
先來一個示例：
upstream big_server_com { ?//這里的?big_server_com 就是上面所說的 命名域名(A domain name)
server127.0.0.3:8000 weight=5;
server127.0.0.3:8001 weight=5;
server192.168.0.1:8000;
server192.168.0.1:8001;
}
server指令上可使用的參數(shù)：
weight=number
比重，設(shè)置后端的server的比重秧秉，在前面的示例里已經(jīng)見過了褐桌。未設(shè)置默認為1。
max_conns=number
限制該server的最大活動(active)連接數(shù)象迎，默認值為0撩嚼，意思是無限制，如果server組沒有運行在共享內(nèi)存模式下挖帘，則限制應(yīng)用于每個處理的worker（work的概念見Nginx核心模塊的worker_processes指令）。如果Nginx啟用了idle keepalive和multiple workers以及shared memory恋技，則 活動連接總數(shù)+空閑連接可能會大于 max_conns 的值拇舀。（share memory和idle keepalive 參見后面的文檔部分。）
max_fails=number
Nginx連接后端的server時蜻底，如果后端服務(wù)不可訪問了骄崩，如何判斷該服務(wù)不可用，這個參數(shù)是其中之一薄辅，另外一個是max_timeout要拂，意思是指設(shè)定的超時時間段內(nèi)，連接后端server失敗時站楚，最多嘗試多少次脱惰，就判定該server為不可用了。默認次數(shù)為1窿春，如果設(shè)置為0拉一，則禁用判斷服務(wù)不可用，即一直不斷的嘗試連接后端server旧乞。如下的這些指令另可能會考慮嘗試連接：
proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, 和 memcached_next_upstream 指令蔚润。
fail_timeout=time
這是一個設(shè)置參數(shù)，一般跟上面的參數(shù)協(xié)同使用尺栖。該參數(shù)的含義：
1：當(dāng)連接后端server失敗時嫡纠，多長時間內(nèi)可反復(fù)嘗試連接后端server；
2：一旦超過這個設(shè)置時間段，則判斷該server的狀態(tài)為不可用（unavailable ）除盏；
這個參數(shù)的默認值為10秒
backup
標(biāo)識該server是備份server叉橱，當(dāng)主server不可用時(主server可能是一組server），請求將被傳送到backup的server上了痴颊，平時backup的server不接受處理請求赏迟。backup也可能是一組server。
down
標(biāo)識該（組）server永久下線蠢棱，不可用锌杀。
Nginx Plus版本還提供了一些額外的參數(shù)共使用，未包含著開源版本里泻仙，所以也沒法使用糕再，略過，它們是：
resolve玉转；route突想；service；slow_start（這些都是upstream 上下文中server指令的參數(shù)）究抓；
如果只有一個server猾担，則 max_fails,fail_timeout，slow_start等參數(shù)都會被忽略刺下，也即server永遠不會被判為不可用绑嘹。
zone
Syntax:? ? ?zone name [size];
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.9.0.
設(shè)置共享內(nèi)存區(qū)的名稱和大小，并維持server組的配置和運行時狀態(tài)在worker間是共享的橘茉。不同的server組可以共享同一個區(qū)工腋，這種情況下，大小只需設(shè)置一次畅卓。
示例：
upstream dynamic {
zone upstream_dynamic 64k; ?//下面定義的server組共享命名為upstream_dynamic擅腰，大小為64K的內(nèi)存。
server backend1.example.com? ? ? weight=5;
server backend2.example.com:8080 fail_timeout=5s slow_start=30s;
server 192.0.2.1? ? ? ? ? ? ? ? ?max_fails=3;
server backend3.example.com? ? ? resolve;
server backend4.example.com? ? ? service=http resolve;
server backup1.example.com:8080? backup;
server backup2.example.com:8080? backup;
}
state
Syntax:? ? ?state file;
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.9.7.
設(shè)置文件來保持動態(tài)配置組的狀態(tài)翁潘。
示例：
state /var/lib/nginx/state/servers.conf; # path for Linux
state /var/db/nginx/state/servers.conf;? # path for FreeBSD
state一般用來限制列出server列表及這些server的參數(shù)趁冈，state設(shè)定的文件會在2種情況下被讀取：
1）初次解析Nginx配置文件的時候拜马；
2）修改upstream 配置的時候箱歧；
應(yīng)該避免直接修改文件內(nèi)容，state指令不能和server指令一起使用一膨。
在Nginx被reload的時候呀邢，如果剛好做了更改，則會丟失更改豹绪。做二進制升級的時候也會導(dǎo)致丟失价淌。
hash
Syntax:? ? ?hash key [consistent];
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.7.2.
用在設(shè)置負載平衡(loadbalancing)中申眼，客戶端尋址server基于hash函數(shù)，這里設(shè)置hash的key值蝉衣，key值可以包含文本括尸，變量或二者的組合。注意病毡，摘除掉一個server濒翻，會導(dǎo)致hash重新計算，也即原來的大多數(shù)的key可能會尋址到不同的server上啦膜。這個hash方法兼容Perl 的 Cache:Memcached 庫有送。若有consistent參數(shù)，則Hash一致性將選擇 ketama算法僧家。這個算法保障雀摘，如果有server被摘除掉（從server group里），只有少數(shù)的key會重新映射到其他的server上去八拱，也即大多數(shù)的key不受server摘除的影響阵赠，還走原來的server。這對提高緩存server命中率有很大幫助肌稻。這個方法跟Perl的Cache:Memcached:Fast庫保持一致（該庫的ketama_points參數(shù)須設(shè)置為160）.
upstream backend {
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
ip_hash
Syntax:? ? ?ip_hash;
Default:? ? ?—
Context:? ? ?upstream
也是設(shè)置load balancing的一種哈希方法清蚀。在尋址后端server時，根據(jù)客戶端的IP來作為hash的key爹谭。使用的是IP4的前三位
XXX.YYY.ZZZ.WWW枷邪，這里是XXX，也即XXX參與IP_HASH旦棉，后面的3端未參與。如果是IP6药薯，則是整個IP6地址绑洛。這種方式確保同一客戶端能被分配到相同的server上去，這對于后端有session的情況很有用（除非該后端的服務(wù)不可用）童本。
如果某server臨時性的不可用了真屯，需要用 down 標(biāo)識出來。以保留該server的客戶端IP地址穷娱，也即再復(fù)活時绑蔫，還能迅速接管它直接接管的客戶端IP。
示例
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}
keepalive
Syntax:? ? ?keepalive connections;
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.1.4.
維持upstream server的鏈接緩存泵额。
connections：設(shè)置維持鏈接的最大數(shù)量值配深，即使沒有客戶端連接，也保障Nginx跟upsteam
server間的鏈接是活動的嫁盲。注意篓叶，這里是指每一個worker。當(dāng)連接數(shù)量超過最大值時，Nginx會把最近重復(fù)被利用次數(shù)最少的連接給關(guān)閉缸托。說白了左敌，就是Nginx跟后端server之間的連接池。
尤其要注意的是俐镐，keepalive不限制Nginx
worker與后端server之間的連接總數(shù)矫限。keepalive設(shè)置的是空閑連接數(shù)，如果與后端server的連接不是空閑連接佩抹，一種有在使用叼风，則可以一直增長連接數(shù)，直到打開連接數(shù)超過空閑連接數(shù)匹摇，并且這些連接也空閑下來了咬扇，才會去關(guān)閉連接。
connections這個值要設(shè)置的小一點廊勃，小到什么程度呢懈贺？足以讓upstream server出來新傳入的連接。
示例：
upstream memcached_backend {
server 127.0.0.1:11211;
server 10.0.0.2:11211;
keepalive 32;
}
server {
...
location /memcached/ {
set $memcached_key $uri;
memcached_pass memcached_backend;
}
}
對于HTTP坡垫，proxy_http_version指令必須設(shè)置為 “1.1”梭灿，并且頭部字段 “Connection”必須清空為“”。
示例如下：
upstream http_backend {
server 127.0.0.1:8080;
keepalive 16;
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}
}
或者對于HTTP 1.0 的長連接冰悠，可以設(shè)置Connection為“Keep-Alive”堡妒。但不推薦這樣使用。
示例如下：
upstream http_backend {
server 127.0.0.1:8080;
keepalive 16;
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.0;
proxy_set_header Connection "Keep-Alive";
...
}
}
對于FastCGI server溉卓，需要設(shè)置fastcgi_keep_conn來維持長連接皮迟。
upstream fastcgi_backend {
server 127.0.0.1:9000;
keepalive 8;
}
server {
...
location /fastcgi/ {
fastcgi_pass fastcgi_backend;
fastcgi_keep_connon;
...
}
}
注意：在使用非輪詢算法的負載平衡時，有必要在keepalive指令前維持他們的連接（不太好理解）桑寨。
ntlm
Syntax:? ? ?ntlm;
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.9.2.
允許代理請求使用NTLM認證伏尼，貌似不太常用，略過尉尾。
示例：
upstream http_backend {
server 127.0.0.1:8080;
ntlm;
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}
}
http {
...
upstream exchange {
zone exchange 64k;
ntlm;
server exchange1.example.com;
server exchange2.example.com;
}
server {
listen? ? ? ? ? ? ? 443 ssl;
ssl_certificate? ? ?/etc/nginx/ssl/company.com.crt;
ssl_certificate_key /etc/nginx/ssl/company.com.key;
ssl_protocols? ? ? ?TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass? ? ? ? ?https://exchange;
proxy_http_version 1.1;
proxy_set_header? ?Connection "";
}
}
}
least_conn
Syntax:? ? ?least_conn;
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in versions 1.3.1 and 1.2.2.
這是一種負載平衡的方法爆阶，最少連接數(shù)。在考慮server權(quán)重的情況下沙咏，負載平衡尋址找接受連接最少的server辨图。如果符合條件的最少連接有多個server，則根據(jù)權(quán)重來輪詢肢藐。
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
least_time
Syntax:? ? ?least_time header | last_byte [inflight];
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.7.10.
這也是一種負載平衡的方法故河，平均響應(yīng)時間最短。在考慮權(quán)重的情況下吆豹，尋址平均響應(yīng)時間最短的server忧勿，如果符合條件的server有多個杉女，則根據(jù)權(quán)重來輪詢。
如果設(shè)置了 header 參數(shù)鸳吸，則$upstream_response_time 變量記錄響應(yīng)頭部傳輸?shù)臅r間熏挎；如果設(shè)置了last_byte，則$upstream_response_time變量記錄response的整個過程的時間晌砾。
upstream backend {
least_time header;
server backend1.example.com;
server backend2.example.com;
}
health_check
Syntax:? ? ?health_check [parameters];
Default:? ? ?—
Context:? ? ?location
允許對server 組進行周期性的健康檢查坎拐，服務(wù)可用性檢查。支持如下可選參數(shù)：
interval=time
設(shè)置多長時間進行一次檢查养匈，默認是5秒哼勇。
jitter=time
設(shè)置檢查時間間隔有一定的隨機的延遲（抖動），默認沒有延遲呕乎。
fails=number
設(shè)置多少次連續(xù)失敗后积担，即判斷該server為不可用，默認為1次猬仁。
passes=number
設(shè)定多少次連續(xù)成功訪問到后端帝璧，即可判斷該服務(wù)為可用，默認為1次湿刽。
uri=uri
設(shè)置健康檢查的URL的烁，默認為 "/"。
location / {
proxy_pass http://backend;
health_check uri=/some/path;
}
mandatory
設(shè)定是否要先強制檢查server的可用性才認為健康诈闺，如果設(shè)置了這個渴庆，server的初始狀態(tài)為“checking”，只有當(dāng)health check完成后雅镊，才標(biāo)識為health襟雷。如果該參數(shù)未設(shè)定，默認為不需要強制檢查仁烹，server天生為health的耸弄。
match=name
指定match的配置響應(yīng)應(yīng)該通過的測試，以便通過健康檢查晃危。默認情況下叙赚，響應(yīng)狀態(tài)應(yīng)該為2XX或3XX老客。2XX和3XX意味著服務(wù)是可用的僚饭。
示例：
match server_ok {
??? status 200-399;
??? header Content-Type = text/html;
??? body !~ "maintenance mode";
}
http {
??? match server_ok {
??????? status 200-399;
??????? header Content-Type = text/html;
??????? body !~ "maintenance mode";
??? }
server {
??? location / {
??? ......
??? health_check match=server_ok;
??? }
??? }
}
這個示例中， 響應(yīng)狀態(tài)必須為200-399胧砰，Content-Type必須為text/html鳍鸵，響應(yīng)體信息中不能含有"maintenance mode"
port=number
執(zhí)行健康檢查時，連接到server的端口尉间，默認情況下為server的端口偿乖。
示例：
location / {
proxy_pass http://backend;
health_check;
}
上面的配置击罪，每5秒（默認）會對“/”路徑進行一次檢查，任何一次的檢查請求失敗贪薪，或狀態(tài)不是2XX或3XX的媳禁，則認為該server的狀態(tài)為 unhealthy，客戶端的請求不會傳輸?shù)?unhealthy 或 checking 狀態(tài)的server上去画切。
server group必須工作在共享內(nèi)存模式下竣稽。
如果一個server group 有多個健康檢查的配置，任何一個健康檢查的失敗霍弹，都將導(dǎo)致該server狀態(tài)為 unhealthy 毫别。
location / {
??? proxy_pass http://backend;
??? health_check interval=10 fails=3 passes=2;
}
http {
??? ...
??? match server_ok {
??? status 200-399;
??? body !~ "maintenance mode";
??? }
??? server {
??????? ...
??????? location / {
??????????? proxy_pass http://backend;
??????????? health_check match=server_ok;
??????? }
??? }
}
match
Syntax:? ? ?match name { ... }
Default:? ? ?—
Context:? ? ?http
定義健康檢查需要匹配的條件〉涓瘢可以參照上面的 health_check 來看岛宦。
有如下使用方法：
status 200; ?//狀態(tài)必須為200
status ! 500; //狀態(tài)碼不能為500
status 200 204; //狀態(tài)碼為200 或 400
status ! 301 302; //狀態(tài)碼不能為301或302
status 200-399; //狀態(tài)碼為200-399之間 都可以
status ! 400-599; //狀態(tài)碼不能再 400-599之間
status 301-303 307;//狀態(tài)碼在301-303之間或者307header Content-Type = text/html; //head 包含 Conten-type并且值為 text/html
header Content-Type != text/html; //head 包含 Conten-Type，但值不能是 text/html
header Connection ~ close; // head包含 Connection 參數(shù)耍缴，值為能匹配 "close"正則的內(nèi)容砾肺。
header Connection !~ close; //包含 Connection參數(shù)，不能匹配 "close"正則的內(nèi)容
header Host; //head 包含 Host 參數(shù)
header ! X-Accel-Redirect; //head 不能有 X-Accel-Redirectbody ~ "Welcome to nginx!"; //body 中能匹配含 “Welcome to nginx!"
body !~ "Welcome to nginx!"; //body 中不能匹配含 "Welcome to nginx!"
match 可以有多個配置私恬，必須所有配置都通過檢查债沮，才能算是健康的，示例：（注意本鸣，不是在location 那里可以將match設(shè)置為多個match name）
# status is 200, content type is "text/html",
# and body contains "Welcome to nginx!"
match welcome {
status 200;
header Content-Type = text/html;
body ~ "Welcome to nginx!";
}# status is not one of 301, 302, 303, or 307, and header does not have "Refresh:"
match not_redirect { //同時滿足才可以
status ! 301-303 307;
header ! Refresh;
}# status ok and not in maintenance mode
match server_ok { //同時滿足才可以
status 200-399;
body !~ "maintenance mode";
}
queue
Syntax:? ? ?queue number [timeout=time];
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.5.12.
如果一個請求沒有立刻被分配到一個server疫衩，那么該請求放到一個
queue 里去。這個指令設(shè)置 queue 里能存放請求的最大值荣德，如果 queue 滿了闷煤，或者在 queue存放超過其超時設(shè)置時間還沒被選出來傳送給server，則會返回 502（Bad Gateway）錯誤給客戶端涮瞻。queue的超時時間默認為60秒鲤拿。
示例：
upstream backend {
server backend1.example.com? max_conns=3;
server backend2.example.com;
queue100 timeout=70;}
upstream backend {
zone backends 64k;
queue750 timeout=30s;
server webserver1.example.com max_conns=250;
server webserver2.example.com max_conns=150;
}
sticky
Syntax:? ? ?sticky cookie name [expires=time] [domain=domain] [httponly] [secure] [path=path];
sticky route $variable ...;
sticky learn create=$variable lookup=$variable zone=name:size [timeout=time];
Default:? ? ?—
Context:? ? ?upstream
This directive appeared in version 1.5.7.
設(shè)置session親和性，這會使得每個客戶端的請求會分發(fā)到一組server中的相同的server中去署咽，即該客戶端的上一個請求是哪個server處理的近顷，下一個還分發(fā)給它來處理，保持會話的親和性宁否。設(shè)置會話親和性有3種方法窒升，cookie,route,learn。
cookie
使用cookie方法慕匠，則意味著派發(fā)server的依據(jù)是Nginx產(chǎn)生的cookie.cookie設(shè)創(chuàng)建饱须，誰處理。首次客戶端請求沒有攜帶特定的cookie台谊，則服務(wù)器端產(chǎn)出一個蓉媳，并告訴客戶端譬挚，帶上這個cookie，下次直接來找我酪呻，下次請求含有該特定cookie减宣，則直接派發(fā)給產(chǎn)出該cookie的服務(wù)器。
upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
尚未綁定到具體server的客戶端請求會由負載平衡的方法來選擇分派到哪個server玩荠，然后cookie會傳給該server蚪腋，如果被派分的server不能處理該請求，將選擇一個新的server來處理它姨蟋。第一個參數(shù)設(shè)置cookie的名稱屉凯，其他參數(shù)有：
expires:設(shè)置超時時間，max或具體的小時眼溶，天等悠砚，如果未設(shè)置，可能會導(dǎo)致用戶超時堂飞。
domain：cookie適用的域名灌旧。
httponly:設(shè)置cookie 的 httponly屬性。
secure:設(shè)置cookie的secure屬性绰筛。
path:設(shè)置cookie的path屬性万矾。
route
使用route方法津滞，后端server會在首次收到客戶端的請求時分配一個route，該客戶端所有后續(xù)的請求都會在cookie里或URI里攜帶這個route信息。這個信息將和upstream上下文里的"server"指令的"route"參數(shù)配合來識別后端server粱檀。如果server的route參數(shù)未設(shè)定树枫，route名稱將十六進制表示的IP地址和端口的MD5哈希戚啥，或Unix的socketpath袒啼，如果被派分的server不能處理該請求，將選擇一個新的server來處理它具被。route的參數(shù)設(shè)定的變量可能包含路由信息玻募，第一個非空變量用來匹配后端server。
upstream backend {
server backend1.example.com route=a;
server backend2.example.com route=b;
sticky route $route_cookie $route_uri;
}
map $cookie_jsessionid $route_cookie {
~.+\.(?P\w+)$ $route; //從cookie里取
}
map $request_uri $route_uri {
~jsessionid=.+\.(?P\w+)$ $route; //從URI里取
}
upstream backend {
server backend1.example.com route=a;
server backend2.example.com route=b;
sticky route $route_cookie $route_uri;
}
也是在backend第一次response之后一姿，會產(chǎn)生一個route信息七咧，route信息通常會從cookie/URI信息中提取。這樣Nginx會按照順序搜索$route_cookie叮叹、$route_uri參數(shù)并選擇第一個非空的參數(shù)用作route艾栋，而如果所有的參數(shù)都是空的，就使用上面默認的負載均衡算法決定請求分發(fā)給哪個backend衬横。
learn
更為復(fù)雜和職能裹粤，Nginx分析upstream server的響應(yīng)终蒂，并學(xué)習(xí)服務(wù)器正常的cookie蜂林，可能是業(yè)務(wù)上使用的遥诉。通常需要和zone搭配使用。
upstream backend {
server backend1.example.com:8080;
server backend2.example.com:8081;
sticky learn
create=$upstream_cookie_examplecookie //創(chuàng)建一個叫 EXAMPLECOOKIE cookie噪叙。
lookup=$cookie_examplecookie ? ?//在請求里查找 EXAMPLECOOKIE cookie矮锈。
zone=client_sessions:1m; ? ?//session 存儲在內(nèi)存共享區(qū)，所以要配置zone睁蕾，設(shè)置名稱和大小苞笨。在64位的環(huán)境下，1M zone可以存儲8000個session.timeout = 1h; ?//在timeout時間段內(nèi)子眶，zone里的session如果沒被訪問過瀑凝，則會被移除，默認的超時時間是10分鐘臭杰。
}
sticky_cookie_insert
Syntax:? ? ?sticky_cookie_insert name [expires=time] [domain=domain] [path=path];
Default:? ? ?—
Context:? ? ?upstream
Nginx從V1.5.7后已拋棄該指令粤咪，使用上面的sticky cookie 等方式，故不表渴杆。
