• Nginx之会话管理解读


    目录

    session概念

    问题引进

    Nginx_hash高级负载均衡

    ip_hash

     hash $cookie_xxx

     hash $request_uri

     补充知识点:服务器扩容


    session概念

    Session对象存储特定用户会话所需的属性及配置信息。这样,当用户在应用程序的Web页之间跳转时,存储在Session对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web页时,如果该用户还没有会话,则Web服务器将自动创建一个 Session对象。

    问题引进

    集群模式下,里面会含有多个服务器,而客户端在某个时刻访问哪个服务器是由负载均衡器决定的,这里就产生了一个问题如果一个用户的Session信息如果存储在一个服务器上,那么当负载均衡器把用户的下一个请求转发到另一个服务器上,由于服务器上没有用户的session信息,那么该用户就需要重新进行登录操作,或者是在某一个服务器上时创建的重要session信息将丢失。

    纯 ip hash 像局域网内的访问ip 访问会导致ip倾斜 

    Nginx_hash高级负载均衡

    ip_hash

    ip_hash 可以保证用户访问可以请求到上游服务中的固定的服务器,前提是用户ip没有发生更改。

    ip_hash是一个算法,原理很简单,根据请求所属的客户端IP计算得到一个数值,然后把请求发往该数值对应的后端。也就是同一个客户端的请求,会发往同一台后端,所以可以达到保持会话的效果。

    不同的ip地址经过ip_hash后生成不同的hash值,同一个ip经过ip_hash后会是同一个值,比如两台服务器的话,值%2取余就可以打到固定的机器上了。 ​

    1. http {
    2. upstream myapp1 {
    3. server srv1.example.com;
    4. server srv2.example.com;
    5. server srv3.example.com;
    6. }
    7. server {
    8. listen 80;
    9. location / {
    10. proxy_pass http://myapp1;
    11. }
    12. }
    13. }

    不能把后台服务器直接移除,只能标记down. 

     该配置适合中小型公司使用,如果是大型项目的话,不太适合。如果后台服务器挂一台,回话就会中断,又需要重新登录,之前的回话保持的数据都消失了,用户体验和安全性不太好。

     hash $cookie_xxx

    $cookie_xxx:是指cookie里的变量。

    1. upstream iphashserver {
    2.         hash $cookie_grafana_session;
    3.         server www.test.com:8002;
    4.         server www.test.com:8003;
    5.     }

    cookie_grafana_session:请求携带grafana_session一样的就会分发到同一台服务器上面

    同理也可以设置php里的sessionID或者Tomcat里的jsessionid,可以达到保持回话的目的。

    ip_hash和cookie_jsessionid的什么区别:一个局域网,大家都接到了同一个路由器上,去请求一个服务器的时候,服务器只会认为你们是同一个ip打过来的,都是路由器的ip(网关),所以都会把流量分发到同一台机器,这个时候后台服务器负载就不均衡了。后者是更具回话sessionId做的hash的,这样会平均打倒后端服务上。

     在upstream 里面配置 hash 的方式 使用 cookie_jsessionid 去做hash

    1. #user nobody;
    2. worker_processes 1;
    3. #error_log logs/error.log;
    4. #error_log logs/error.log notice;
    5. #error_log logs/error.log info;
    6. #pid logs/nginx.pid;
    7. events {
    8. worker_connections 1024;
    9. }
    10. http {
    11. include mime.types;
    12. default_type application/octet-stream;
    13. sendfile on;
    14. #tcp_nopush on;
    15. #keepalive_timeout 0;
    16. keepalive_timeout 65;
    17. #gzip on;
    18. upstream backend {
    19. # 指定hash 方式是 cookie_jessionid nginx自带的方式
    20. hash $cookie_jsessionid;
    21. server 172.16.225.1:8081;
    22. server 172.16.225.1:8080;
    23. }
    24. server {
    25. listen 80;
    26. server_name localhost;
    27. #charset koi8-r;
    28. #access_log logs/host.access.log main;
    29. location / {
    30. # 指定负载到后端upstream
    31. proxy_pass http://backend;
    32. }
    33. error_page 500 502 503 504 /50x.html;
    34. location = /50x.html {
    35. root html;
    36. }
    37. }
    38. }

     hash $request_uri

    原理:请求同一个uri会打到同一个服务器上。(uri:指的是完整的url除了域名部分的后半段)

    1. upstream iphashserver {
    2. hash $request_uri;
    3. server www.test.com:8001;
    4. server www.test.com:8002;
    5. }

     补充知识点:服务器扩容


    1、硬件扩容
    简介:也叫纵向扩容。简单来讲就是通过增加和改价硬件的方式来换取服务器的高性能。比如说买块内存条,换个ssd。

    瓶颈:一直扩容下去也是有瓶颈的,比如主板只能支持100G的内存,你插再大的内存条也不管事,主板不支持,所以得再叠加水平扩容。

    2、水平扩容
    简介:通过集群的方式来提高服务器的性能。

  • 相关阅读:
    处理服务器返回的utc 时间转正标准时间
    POJ3268最短路径题解
    热门开源项目推荐
    云安全—集群攻击入口攻与防
    Spring Boot虚拟线程与Webflux在JWT验证和MySQL查询上的性能比较
    SpringMVC入门
    生产者、消费者问题
    TinyRenderer学习笔记--Lesson 5
    java 8 stream api将List<T>转换成树形结构
    linux目录与文件操作命令
  • 原文地址:https://blog.csdn.net/m0_62436868/article/details/132834078