07 Nov 2018
这里牵扯到了负载均衡中会话保持的知识。这里的sticky是基于cookie来将同一个用户的请求sticky到同一个后端服务的方法。
关于会话保持，可以参照:
nginx社区版是不包含sticky模块的，只有nginx企业版(nginx plus)才包含这个模块。
此模块老的版本是nginx-sticky-module，但是那个模块已经不更新了，所有有人fork了一个新版本nginx-sticky-module-ng，目前收录在了nginx第三方模块的列表中。
基于cookie将请求转发至同一个upstream服务器的nginx模块。当upstream拥有多个server时，将同一个client的请求发送至同一个server是很有必要的。这属于会话保持，其中cookie粘连是其中一种。还有一种通过ip地址的方法(ip_hash)，这种方法并不适用于所有情况，因为有可能大量的用户通过同一个代理ip来请求。这种情况下，负载均衡分配给不同server的压力可能就会不平衡。
当某个请求被接收，而sticky module无法被应用时，nginx会切换回经典的轮询方式来处理或者返回”Bad Gateway”(取决于no_fallback的配置)。
当浏览器不支持cookie时，sticky module是不会起作用的。
# 首先下载nginx-sticky-module-ng并解压，然后在编译nginx的时候，用--add-module参数指定其路径 ./configure ... --add-module=/absolute/path/to/nginx-sticky-module-ng make make install
upstream {
sticky;
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server 127.0.0.1:9002;
}
sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h]
[hash=index|md5|sha1] [no_fallback] [secure] [httponly];
issues and warnings:
- 当给同一个domain配置不同带sticky的upstream并指向不同的location时，使用不同的path配置。详细可查看这里
- sticky模块不可以和server的backup配置一起使用
- sticky模块可以与nginx_http_upstream_check_module一起使用（从版本1.2.3开始）
- sticky模块可能需要使用SSL支持配置nginx（使用secure参数时）
production note:
- 使用了原版的nginx-module-sticky，结果和nginx1.14版本一起用时有问题，换了nginx-module-sticky-ng恢复正常。但是还是有一个问题，get时可以保持同一个server，但是post时会随机切换，不懂这个原理，因为没有影响业务，就没有深究。
- 使用了多层nginx代理，nginx-nodejs-nginx-tomcat，都启用了sticky，最开始是不正常的，当给sticky中的cookie名称设定为非默认的name，让不同nginx有不同的cookie名称时正常了。