通过ip_hash做会话保持有一定的缺陷，这个是通过客户端ip来实现。同一个网络下众多客户端访问服务器会被扔到同一台机器，再或者是CDN也会导致负载不均衡。所以要实现通过客户端cookie实现，包括F5、深信服设备其中的会话保持也是通过插入cookie值来实现会话保持。下次客户端访问服务器，带上本地cookie，nginx中的sticky模块分析并扔到对应服务器中。

软件版本：
nginx-1.6.0 (后来用nginx-1.2.3)
nginx-sticky-module-1.1

安装：
[root@localhost nginx-1.6.0]# ./configure –prefix=/usr/local/nginx/ –add-module=../nginx-sticky-module-1.1
[root@localhost nginx-1.6.0]# make
make时报错：
objs/addon/nginx-sticky-module-1.1/ngx_http_sticky_misc.o] 错误 1

参考解决方法：

方法一：
http://www.blogjava.net/sliverfancy/archive/2014/03/28/411594.html
说安装openssl-devel，试过无效。

方法二(未测试)：
nginx-1.5.x和nginx-sticky-module-1.1编译会有点问题，应该是nginx新版本没有相应的nginx-sticky-module，解决办法是把nginx-sticky-module-1.1/ngx_http_sticky_misc.c的281行修改为:

digest->len = ngx_sock_ntop(in,sizeof(struct sockaddr_in), digest->data, len, 1);

方法三：
降低nginx版本，我这里换为nginx-1.2.3编译通过。

sticky模块参数只用于upstream段中，并且不能和ip_hash同时存在。
支持的参数：
sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h] [hash=index|md5|sha1] [no_fallback];
name: 可以为任何的string字符,默认是route
domain：哪些域名下可以使用这个cookie
path：哪些路径对启用sticky,例如path/test,那么只有test这个目录才会使用sticky做负载均衡
expires：cookie过期时间，默认浏览器关闭就过期，也就是会话方式。
no_fallbackup：如果设置了这个，cookie对应的服务器宕机了，那么将会返回502（bad gateway 或者 proxy error），建议不启用。

配置参考(反向代理部分略过)：

upstream apache {
 sticky name=srv_id expires=1h domain=.test.com path=/;

 server 192.168.5.4 max_fails=3 fail_timeout=20s;
 server 192.168.5.5 max_fails=3 fail_timeout=20s;
}

参考链接：
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#sticky
http://blog.csdn.net/dc_726/article/details/12348907

本文整理于网络

在使用Nginx时，经常会碰到502 Bad Gateway和504 Gateway Time-out错误，下面以Nginx+PHP-FPM来分析下这两种常见错误的原因和解决方案。

1.502 Bad Gateway错误
在php.ini和php-fpm.conf中分别有这样两个配置项：max_execution_time和request_terminate_timeout。
这两项都是用来配置一个PHP脚本的最大执行时间的。当超过这个时间时，php-fpm不仅会终止脚本的执行，
还会终止执行脚本的worker进程。所以nginx会发现与自己通信的连接断掉了，就会返回给客户端502错误。

以php-fpm的request_terminate_timeout=30 秒时为例，报502 Bad Gateway错误的具体信息如下：
1）Nginx错误访问日志：
2013/09/19 01:09:00 [error] 27600#0: *78887 recv() failed (104: Connection reset by peer) while reading response header from upstream,
client: 192.168.1.101, server: test.com, request: “POST /index.php HTTP/1.1”, upstream: “fastcgi://unix:/dev/shm/php-fcgi.sock:”,
host: “test.com”, referrer: “http://test.com/index.php”

2）php-fpm报错日志：
WARNING: child 25708 exited on signal 15 (SIGTERM) after 21008.883410 seconds from start

所以只需将这两项的值调大一些就可以让PHP脚本不会因为执行时间长而被终止了。request_terminate_timeout可以覆盖max_execution_time，
所以如果不想改全局的php.ini，那只改php-fpm的配置就可以了。

此外要注意的是nginx的upstream模块中的 max_fail 和 fail_timeout 两项。有时Nginx与上游服务器（如Tomcat、FastCGI）的通信只是偶然断掉了，
但max_fail如果设置的比较小的话，那么在接下来的fail_timeout时间内，nginx都会认为上游服务器挂掉了，都会返回502错误。
所以可以将 max_fail 调大一些，将 fail_timeout 调小一些。

2.504 Gateway Time-out错误
php-fpm设置的脚本最大执行时间已经够长了，但执行耗时php脚本时，发现nginx报错从502变为504了。这是为什么呢？
因为我们修改的只是php的配置，nginx中也有关于与上游服务器通信超时时间的配置：

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

以nginx超时时间为90秒，php-fpm超时时间为300秒为例，报504 Gateway Timeout错误时的Nginx错误访问日志如下：
2013/09/19 00:55:51 [error] 27600#0: *78877 upstream timed out (110: Connection timed out) while reading response header from upstream,
client: 192.168.1.101, server: test.com, request: “POST /index.php HTTP/1.1”, upstream: “fastcgi://unix:/dev/shm/php-fcgi.sock:”,
host: “test.com”, referrer: “http://test.com/index.php”

调高这三项的值（主要是read和send两项，默认不配置的话Nginx会将超时时间设为60秒）之后，504错误也解决了。
而且这三项配置可以配置在http、server级别，也可以配置在location级别。担心影响其他应用的话，就配置在自己应用的location中。

注意：
以下部分是对FastCGI生效
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

以下部分是对proxy_pass生效
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;

配置举例：
location ~ \.php$ {
root /home/test.com;
include fastcgi_params;
fastcgi_connect_timeout 180;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/cdai/test.com$fastcgi_script_name;
}