• nginx正反向代理，负载均衡

    Nginx可以正向代理，反向代理 ，负载均衡

    Nginx有两种代理协议

    1. 七层代理（http协议）
    2.  
    3. 四层代理（tcp/udp流量转发）

    四层代理七层代理概念

    四层代理

    四层代理：基于tcp/ip协议层的转发代理方式，基于ip和端口号实现负载均衡，或者正向代理。

    四层代理无法获取http请求中的URL信息，只能对tcp或者udp的数据包进行转发

    隐藏客户端，目标服务器只能看到代理服务器的请求，不知道客户端的ip
    客户端访问代理服务器，代理服务器转发请求，后端服务器只知道代理服务器，不知道客户端ip

    七层代理

    七层代理，代理的是http的请求和响应，客户端请求代理服务器，由代理服务器转发客户端的http请求，转发到内部的服务器（可以是单台，也可以是一组），后端的websever，再把响应送达代理服务器，最后再到客户端

    隐藏后端服务器，客户端只与反向代理通信，不与后端服务器通信
    客户端访问代理服务器，代理服务器转发请求，客户端不知道服务端的ip，只知道代理服务器的地址

    正反向代理

    正向代理客户端访问代理服务器，代理服务器转发请求，客户端只知道代理的地址，后端的webserver的ip地址，客户端也不知道
    反向代理客户端访问的是代理服务器，代理服务器转发http请求，但是客户端不知道访问的是哪一台服务器

    四层代理和七层代理之间的区别

    四层代理四层代理速度更快，四层代理是基于IP地址和端口号，只负责将ip和端口转到后端服务器，不对请求做任何处理，只是负责转发而已，而且四层转发走的是内核态，四层代理无法提供更改功能，只是转发
    七层代理走的是用户态，需要对http的请求进行处理和解析，在解析过程中可以根据请求头和请求体的内容进行一定的操作，内容过滤。转发比较慢，但是提供的功能更高级，用户的体验更好

    正向代理和反向代理

    正向代理都是通过代理服务器访问，明确指向了后端服务器，一般都是1对1
    反向代理都是通过代理服务器访问，但一个代理服务器会有多台后端服务器供代理服务器进行转发请求，只有一对多，才涉及负载均衡的算法问题

    选择场景（什么时候用四层和七层）

    1. 1.七层代理：需要对http请求进行控制和处理，只能选择七层代理（工作中常见的的代理方式）
    2.  
    3. 2.四层代理：只需要对tcp/udp数据包（流量转发），可以选择四层，也可以选择七层代理
    4.  
    5. 3.七层可以对ip和端口进行转发，也可以对域名进行代理
    6.  
    7. 4.四层只能是ip和端口，不能对域名进行代理
    8.  
    9. 5.负载均衡算法：有些是无法在四层代理使用

    四层代理和七层代理模块

    1. 七层代理只能写在http模块的全局配置当中
    2. Upstream：用于处理http请求，支持方向代理，负载均衡，缓存功能
    3. 在ypstream模块中可以对配置多个服务器
    4.  
    5.  
    6. 四层代理的模块stream
    7. Stream只能写在全局模块当中的单独配置，stream代理无所谓协议的，只管流量

    正向代理：类似于vpn，科学上网，加速器，指定国家

    反向代理：企业架构都是反向代理，客户端通过代理服务器访问后台，但是后端有多台服务器

    七层代理实际写法

    要在http全局模块下配置

    1. upstream  test(test可以自定义名称) {
    2.           server 192.168.233.62；
    3.           server 192.168.233.63；
    4. }
    5.  
    6. Location  {
    7.           Proxy_pass http://test;
    8. }

    负载均衡的算法

    轮询

    1. 1.rr（round  robin） 负载均衡最简单的算法，轮询，请求轮流分配到后端服务器，默认算法，可以不加，
    2.  
    3. 默认算法，特点是每发起一次都是新的请求，服务器上没有缓存
    4.  
    5. 服务器处理能力相近，而且，对访问量比较小的网站适用

    加权轮询

    1. 2.weight加权轮询 建立在默认轮询算法的基础之上，为后端服务器分配不同的权重，处理能力强的服务器可以分配的权重值要高一些。
    2.  
    3. 轮询次数基本上按照权重进行分配，服务器上也没有缓存
    4.  
    5. 中大型网站可以使用加权轮询
    6.  
    7. 权重高的服务器会被频繁请求响应，权重低的可能闲置，这种情况回合另外一种算法配合使用

    最少连接数算法

    1. 会把请求发送到连接数量较少的后端服务器，   least_conn;
    2.  
    3. 最少连接算法可以单独使用，但是一般都是结合加权轮询一块使用，避免所以得请求都发送到处理能力强的服务器
    4.  
    5. 提高整个集群的稳定性
    6.  
    7. 中型网站，大型网站，日常访问可以满足

    ip_hash

    1. iphash会根据客户端ip地址解析出一个hash值，然后将请求放到对应的后端服务器，下一次用户再访问时，同一客户端的请求将会被分配到同一台服务器
    2.  
    3. Ip_hash第一次访问之后，后续访问是有缓存的
    4.  
    5. 如果后端服务器的数量发生变化，可能会进行重新分配
    6.  
    7. Ip_hash适用于高并发，请求不会跳转，请求的是本地缓存
    8.  
    9. 即使分配了权重它依然只会选择同一服务器地址

    url_hash

    1. 根据请求url地址计算hash值，然后将请求发送到相应的后端服务器，相同的url地址请求会被分配到同一个服务器
    2.  
    3. Url_hash和ip_hash 是可以结合在一块使用，也是可以适用于并发较高的场景，主要是ip_hash和url_hash访问之后第二次都是访问本地缓存，可以降低后端服务器的压力

    基于域名的反向代理

    主机1

    主机2

    主机3

    四层的反向代理

    1. 四层的反向代理
    2.  
    3. events {
    4.  
    5. 在四层代理中可以使用加权轮询，最小连接数算法也可以实现负载均衡
    6.  
    7. 但ip_hash 和 url_hash 不可以在stream中使用，四层只是转发数据包，不能对请求进行处理
    8.  
    9. http七层代理可以处理地址，可以处理请求地址和请求的url

    方式

    轮询默认算法 可以不加 ，每个后端服务器都会换一次
    加权轮询给后端服务器设置不同的权重，通过权重分发代理请求（客户端请求），权重高的轮询的次数就多，权重少，轮询的次数就比较少，但是不绝对，而且有一种可能，会导致权重高的服务器会被频繁的请求，权重少的在一边闲置
    最小连接数最小连接数：会把请求转发到当前连接数较小的服务器，避免请求集中到高性能或者高权重的服务器，可以加权轮询配合使用，适用于大部分场景
    Ip_hash根据客户端请求的ip地址生成一个hash值，然后转发到后端服务器，下一次在访问，还是之前的服务器，而且还有缓存，如果还有需要把请求客户端地址，转发到固定的服务器，可以使用这个方法，大并发，小并发都可以用，具体看企业需求，但是后端服务器发生变化（比如损坏），请求的后端服务器也会发生变化（后端服务器数量变少，后端服务器的数量增加，请求的地址未必会变）
    url_hash

    根据请求的url地址生产一个hash值，然后转发到后端服务器，但是下一次访问访问，请求的url不练，还是上次访问的后端服务器，而且也有缓存

    Url地址发生变化，或者后端服务器数量也发生变化，可能会变更后端服务器的地址

    缩容的情况，业务量比较少，不需要那么多后端服务器，才会缩容，只会扩
    实验
     正向代理
    1. [root@master01 conf]# vim nginx.conf
    2.  
    3. 43         location / {
    4. 44             root   html;
    5. 45             index  index.html index.htm;
    6. 46             proxy_pass http://192.168.233.82;    #正向代理82，访问81就等于访问82
    7. 47         }

    七层反向代理
    1. [root@master01 conf]# vim nginx.conf
    2.  
    3.  17 http {
    4.  18     include       mime.types;
    5.  19     default_type  application/octet-stream;
    6.  20 
    7.  21     #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    8.  22     #                  '$status $body_bytes_sent "$http_referer" '
    9.  23     #                  '"$http_user_agent" "$http_x_forwarded_for"';
    10.  24 
    11.  25     #access_log  logs/access.log  main;
    12.  26     upstream chen {
    13.  27         server 192.168.233.81;  
    14.  28         server 192.168.233.82;
    15.  29         server 192.168.233.83;
    16.  30 }
    17.  47         location / {
    18.  48             root   html;
    19.  49             index  index.html index.htm;
    20.  50             proxy_pass http://chen;     #这里代理的是upstream  里面自定义的 chen
    21.  51         }
    22. #如本机ip是66，通过访问66可以轮询到81,82,83
    23. [root@master01 conf]# nginx -t
    24. [root@master01 conf]# systemctl restart nginx

    轮询算法

    算法都是配置在代理里面的

    加权轮询

    1. 26     upstream chen {
    2.  27         server 192.168.233.82 weight=2;
    3.  28         server 192.168.233.83 weight=1;
    4.  29 }
    5. #这里的算法为默认的轮询，数字越大权重越高，访问到的概率越大，这里访问82的概率会大一点

     最小连接数
    1.  26     upstream chen {
    2.  27         least_conn;
    3.  28         server 192.168.233.82 weight=2;
    4.  29         server 192.168.233.83 weight=1;
    5.  30 }
    6. #最小连接数可以单独使用，但一般都是配合加权轮询一块使用,避免所有的请求都发送到处理能力强的服务器。
    7. #中型网站，大型网站，日常访问可以满足

    ip_hash
    1.     upstream chen {
    2.         ip_hash;
    3.         server 192.168.233.82 weight=2;
    4.         server 192.168.233.83 weight=1;
    5. }
    6. #ip_hash会根据客户端ip地址解析出一个hash值，然后将请求放到对应的后端服务器，下一次用户再访问时，统一客户端的请求将会被分配到同一台服务器，ip_hash的第一次访问之后，后续访问是有缓存的，如果后端服务器的数量发生变化，可能会进行重新分配，iphash适用于高并发，请求不会跳转，请求的是缓存

  • 相关阅读:
    【Linux】Alibaba Cloud Linux 3 yum 安装 PHP8.1
    指南：清晰理解zkEVM、EVM 兼容性和Rollup
    Spring Security（一）- SpringSecurity 框架简介
    git clean 命令详解
    qt中弱属性机制
    打车APP开发平台具体解决了哪些出行问题？
    live555 音视频处理相关文档解读，
    C++设计模式-桥接（Bridge）
    深度剖析Vue2、Vue3响应式原理 | 逐步推敲手写响应式原理全过程
    安卓开机启动流程
  • 原文地址：https://blog.csdn.net/2301_79410672/article/details/133862008