我研究了AWS ALB的黏性会话（每次重新连接会话寿命都会延长）
我們決定使用ALB的黏著會話（Sticky Session）功能，但在檢視配置時發現只能設定會話持續時間。這意味著，例如我們設定了24小時的會話持續時間，即使在24小時快要結束前登錄應用程式，由於黏著會話的Cookie已過期，將重新轉發到未登錄的實例，導致登錄會話被中斷。覺得有點不方便後，重新閱讀了手冊，發現了以下描述。
可以在目标组级别启用粘性会话。
还可以通过设置负载均衡器生成的cookie的持续时间，以秒为单位。
这段时间将在每个请求中设置。
因此，在每个期限到期之前，如果客户端发送请求，粘性会话将继续。
如果启用了多个目标组的粘性会话，建议为所有目标组设置相同的持续时间。
我决定实际验证一下，在一定的模糊有效期内发送请求会延长会话的意思。
验证环境
以下是验证环境的设定。
当访问nginx的/stikky.txt时，会返回nginx01和nginx02。
黏性会话的持续时间设定为3秒（在实际环境中，是不会设置这么未来的，哈哈）。
Client --- ALB --- Nginx01
└- Nginx02
检验结果
首先，尝试以5秒的间隔进行轮询。
根据命令结果，可以看到它交替连接到Nginx01和Nginx02。
由于黏性会话在3秒钟后失效，所以当在5秒后再次访问时将被视为新连接，并重新分配，重新发行cookie。
[root@localhost ~]# yes "date '+%d-%m %H:%M:%S'|tr '\n ' ' ' ; curl -c ./cookie_elb.txt -b ./cookie_elb.txt http://nginx-1428263045.us-west-2.elb.amazonaws.com/stikky.txt;sleep 5;" | sh
27-01 05:45:03 nginx02
27-01 05:45:08 nginx01
27-01 05:45:14 nginx01
27-01 05:45:20 nginx02
27-01 05:45:25 nginx02
27-01 05:45:31 nginx01
27-01 05:45:36 nginx01
尝试用1秒的间隔进行轮询。
尽管试了30秒以上，但现在始终连接到了Nginx02。
虽然担心会中断会话，但似乎即使经过5秒，会话仍然保持。
也就是说，如果在会话期间重新连接，会话时间也会延长，这应该是对的。
[root@localhost ~]# yes "date '+%d-%m %H:%M:%S'|tr '\n ' ' ' ; curl -c ./cookie_elb.txt -b ./cookie_elb.txt http://nginx-1428263045.us-west-2.elb.amazonaws.com/stikky.txt;sleep 1;" | sh
27-01 06:03:12 nginx01
27-01 06:03:14 nginx01
27-01 06:03:15 nginx01
27-01 06:03:17 nginx01
27-01 06:03:18 nginx01
27-01 06:03:20 nginx01
27-01 06:03:21 nginx01
27-01 06:03:23 nginx01
27-01 06:03:24 nginx01
27-01 06:03:26 nginx01
27-01 06:03:27 nginx01
27-01 06:03:29 nginx01
27-01 06:03:30 nginx01
27-01 06:03:32 nginx01
27-01 06:03:33 nginx01
27-01 06:03:35 nginx01
27-01 06:03:36 nginx01
27-01 06:03:38 nginx01
27-01 06:03:39 nginx01
27-01 06:03:41 nginx01
27-01 06:03:42 nginx01
27-01 06:03:44 nginx01
27-01 06:03:45 nginx01
27-01 06:03:47 nginx01
27-01 06:03:48 nginx01
27-01 06:03:50 nginx01
那么，粘性会话期应该设置多长时间呢？
根据上述验证结果，在一个频繁通信的后台系统中，粘性会根据通信次数不断更新，只要不退出登录就会一直保持。而在没有用户操作的情况下不会进行通信的系统中，如果处于无操作状态太长时间，粘性会达到有效期限，因此最好将其设置为与系统会话超时相同。这样一来，在系统会话过期并需要重新登录时，粘性会话也会到期，从而避免用户意外断开会话的情况。
