如何进行tengine session_sticky_module模块源码分析和使用,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
前言
nginx以前对session 保持支持不太好,主要采用ip_hash把同一来源的客户(同一C段的IP)固定指向后端的同一台机器,ip_hash有个缺点是不能实现很好的负载均衡;直到nginx的扩展模块nginx-sticky-module的出现,解决了session sticky的问题。
个人感觉tengine的session sticky模块更好一些,于是把tengine的sticky移植到了nginx里。
temgine session_sticky_module模块是一个负载均衡模块,通过cookie实现客户端与后端服务器的会话保持, 在一定条件下可以保证同一个客户端访问的都是同一个后端服务器。
基本参数:
-
cookie设置用来记录会话的cookie名称
-
domain设置cookie作用的域名,默认不设置
-
path设置cookie作用的URL路径,默认不设置
-
maxage设置cookie的生存期,默认不设置,即为session cookie,浏览器关闭即失效
mode设置cookie的模式:
-
insert: 在回复中本模块通过Set-Cookie头直接插入相应名称的cookie
-
rewrite: 使用服务端标识覆盖后端设置的用于session sticky的cookie。如果后端服务在响应头中没有设置该cookie,则认为该请求不需要进行session sticky,使用这种模式,后端服务可以控制哪些请求需要sesstion sticky,哪些请求不需要。
option 设置用于session sticky的cookie的选项,可设置成indirect或direct。indirect不会将session sticky的cookie传送给后端服务,该cookie对后端应用完全透明。direct则与indirect相反。
maxidle设置session cookie的最长空闲的超时时间
-
maxlife设置session cookie的最长生存期
-
fallback设置是否重试其他机器,当sticky的后端机器挂了以后,是否需要尝试其他机器
-
hash设置cookie中server标识是用明文还是使用md5值,默认使用md5
目前控制台只支持两种模式,insert和rewrite模式。
两种模式下,其他的配置都是相同的。
在insert模式下,cookie的值不经过后端,完全由lb进行管理,每个后端的rs生成一个唯一的id值,加上maxidle和maxlife值,用分隔符隔开,用作cookie的value,来进行会话保持,这个条件需要option=indirect和session_sticky_hide_cookie配合。
在rewrite模式下,除了mode改变,其他完全没变,cookie的值由后端rs是否设置来决定。
session_sticky格式补充
第一次请求的时候,因为请求不带cookie值,或者说cookie值本身是错误的,会触发第一次选取rs,并且将cookie值通过response返回
curl -v 127.0.0.3:978
* About to connect() to 127.0.0.3 port 978 (#0)
* Trying 127.0.0.3… connected
* Connected to 127.0.0.3 (127.0.0.3) port 978 (#0)
> GET / HTTP/1.1
> User-Agent: kcurl/1.0 (curl 7.19.7) (x86_64-unknown-linux-gnu) libcurl/7.19.7 OpenSSL/1.0.1e zlib/1.2.3
> Host: 127.0.0.3:978
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Tengine/2.3.0
< Date: Sun, 28 Apr 2019 10:24:01 GMT
< Content-Type: text/plain
< Content-Length: 3
< Connection: keep-alive
< Set-Cookie: LBSID=d349ca31adc862f4d7e6faa19e516d6d|1556447041|1556447041; Path=/
<
* Connection #0 to host 127.0.0.3 left intact
* Closing connection #0
821
返回的cookie值构成为,
LBSID=d349ca31adc862f4d7e6faa19e516d6d|1556447041|1556447041;
LBSID:配置文件中session_sticky指定的键值
d349ca31adc862f4d7e6faa19e516d6d:所选取的后端计算出来的哈希值
1556447041:lastseen,最后一次使用这个cookie的时间戳(用于比较maxidle,下一次请求的将把这个时间戳带回来,如果与当前的时间戳比较超出maxidle,过期处理)
1556447041:firstseen,第一次使用这个cookie的时间戳(用于比较maxlife,基本在请求和返回交互的过程中不会修改)
curl –cookie "LBSID=d349ca31adc862f4d7e6faa19e516d6d|1556447041|1556447041; Path=/" 127.0.0.3:978
* About to connect() to 127.0.0.3 port 978 (#0)
* Trying 127.0.0.3… connected
* Connected to 127.0.0.3 (127.0.0.3) port 978 (#0)
> GET / HTTP/1.1
> User-Agent: kcurl/1.0 (curl 7.19.7) (x86_64-unknown-linux-gnu) libcurl/7.19.7 OpenSSL/1.0.1e zlib/1.2.3
> Host: 127.0.0.3:978
> Accept: */*
> Cookie: LBSID=d349ca31adc862f4d7e6faa19e516d6d|1556447041|1556447041; Path=/
>
< HTTP/1.1 200 OK
< Server: Tengine/2.3.0
< Date: Sun, 28 Apr 2019 10:30:13 GMT
< Content-Type: text/plain
< Content-Length: 3
< Connection: keep-alive
< Set-Cookie: LBSID=d349ca31adc862f4d7e6faa19e516d6d|1556447413|1556447041; Path=/
<
* Connection #0 to host 127.0.0.3 left intact
* Closing connection #0
821
可见,第二次请求带着cookie,返回值更新了,lastseen,并且选定了刚刚的rs(d349ca31adc862f4d7e6faa19e516d6d),并且lastseen也更新了时间戳
max_idle测试
curl 10.10.117.238/ok -v
* About to connect() to 10.10.117.238 port 80 (#0)
* Trying 10.10.117.238…
* Connected to 10.10.117.238 (10.10.117.238) port 80 (#0)
> GET /ok HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.10.117.238
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: LB 1.0.0
< Date: Thu, 17 Oct 2019 07:26:09 GMT
< Content-Type: application/octet-stream
< Content-Length: 2
< Connection: keep-alive
< Set-Cookie: LBSID=10.0.23.20:80|1571367|1572197167; Path=/
<
* Connection #0 to host 10.10.117.238 left intact
ok
第一次请求选择了rs:10.0.23.20:80
curl –cookie "LBSID=10.0.23.20:80|1571297169|1571297169; Path=/" 10.10.117.238/ok -v
* About to connect() to 10.10.117.238 port 80 (#0)
* Trying 10.10.117.238…
* Connected to 10.10.117.238 (10.10.117.238) port 80 (#0)
> GET /ok HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.10.117.238
> Accept: */*
> Cookie: LBSID=10.0.23.20:80|15734169|1571297217; Path=/
>
< HTTP/1.1 200 OK
< Server: LB 1.0.0
< Date: Thu, 17 Oct 2019 07:26:38 GMT
< Content-Type: application/octet-stream
< Content-Length: 2
< Connection: keep-alive
< Set-Cookie: LBSID=10.0.23.20:80|15734169|1571297217; Path=/
<
* Connection #0 to host 10.10.117.238 left intact
ok
max_idle设置为30,在18秒内的请求没有超时,继续使用10.0.234.20:80这个rs。
curl –cookie "LBSID=10.0.234.20:80|1571297198|1571297217; Path=/" 10.10.117.238/ok -v
* About to connect() to 10.10.117.238 port 80 (#0)
* Trying 10.10.117.238…
* Connected to 10.10.117.238 (10.10.117.23) port 80 (#0)
> GET /ok HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.10.117.238
> Accept: */*
> Cookie: LBSID=10.0.23.20:80|1571297198|1571297217; Path=/
>
< HTTP/1.1 200 OK
< Server: LB 1.0.0
< Date: Thu, 17 Oct 2019 07:27:47 GMT
< Content-Type: application/octet-stream
< Content-Length: 2
< Connection: keep-alive
< Set-Cookie: LBSID=10.0.23.6:80|1571297198|1571297217; Path=/
<
* Connection #0 to host 10.10.117.238 left intact
ok
一旦超过max_idle,该session失效,重新选择rs,更新lastseen和firstseen
关于如何进行tengine session_sticky_module模块源码分析和使用问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注亿速云行业资讯频道了解更多相关知识。
原创文章,作者:1402239773,如若转载,请注明出处:https://blog.ytso.com/tech/safety/222586.html