反向代理Nginx
引用：https://baijiahao.baidu.com/s?id=1600687025749463237&wfr=spider&for=pc
参考下图，正向代理用途：Client无法直接访问Server，比如谷歌FQ，于是请求发送给代理，代理可以访问Server并将其返回信息返回给Client。
反向代理用途：1.把Server的IP域名隐藏起来不直接暴露，Proxy充当跳板机/前置机的功能；2.对于大量的客户端并发请求，进行分发给各个服务器，实现负载均衡。
反向代理TCP/UDP负载均衡配置和选择：编辑nginx.conf文件
#进程数，一般一个进程就够了 worker_processes 1; events { #单个进程最大连接数（最大连接数=连接数*进程数） worker_connections 1024; } #TCP/UDP套接字固定字符串：stream stream { #反向代理URL管理 upstream myproxy { #源地址哈希法，就是对访问客户端的IP进行hash后的结果进行分配，这样每一个客户端固定请求同一个后端服务器。 #ip_hash; #按照服务器响应时间的长短来进行分发的，服务器响应时间越短的，优先分发。 #fair
#正常分发 server 192.168.3.22:13333; server 192.168.3.22:13334; #权重，权重越大，连接数量越多，压力越大。 #server 11.22.333.44:5555 weight=2; #server 11.22.333.11:6666 weight=1; #表示当前的server临时不參与负载。 #server 11.22.333.22:8888 down; #其他全部的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。 #server 11.22.333.33:8888 backup; } server { #region 统一监听端口 listen 13335; #连接超时时间 proxy_connect_timeout 3s; #N秒内服务器没有接收到数据自动断开与客户端的连接，如不想要此功能则注释该行 #proxy_timeout 10s; #反向代理URL proxy_pass myproxy; } }
打开cmd，输入nginx -c nginx.conf，回车执行。
注意如果要关闭nginx，关了控制台是没用的，需要另外打开一个cmd窗口输入nginx -s quit，回车执行。
一般只修改配置文件，不需要重启或关闭nginx，执行 nginx -s reload 重新加载配置文件即可。
深入Nginx
附上原文链接：https://blog.csdn.net/wy757510722/article/details/75267431
nginx是以多进程的方式来工作的，当然nginx也是支持多线程的方式的,只是我们主流的方式还是多进程的方式，也是nginx的默认方式：
1.nginx、redis等每个单独的进程都可以独占资源，通常情况下每个服务器会开几十个nginx、redis进程，这样如果采用多线程的模式，各个线程能够利用的资源就会受到一些限制，诸如：ulimit -n 命令展示的每个进程最多可以打开的文件数这样的限制。
2.nginx中除了master需要跟worker通过管道进行通信，worker之间不需要通信，而且每个worker的功能都一样，属于常驻进程。在这种场景下多线程的优势体现不出来，而且也可以避免多线程在编程时需要考虑资源访问互斥、同步等问题带来的编程复杂度的提升，以及可能带来的调试困难。（这里的同步、互斥并非指线程间消息传递等操作）
3.nginx采用多进程的方式，既可以避免因某个线程故障导致整个服务不可用的问题，也可以实现配置热加载，不停服升级版本。
多进程工作模式
1. nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号(重新加载配置文件，重启nginx命令等)，向各worker进程发送信号，监控 worker进程的运行状态,当worker进程异常情况下退出后，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了 。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的 。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 。
2.Master接收到信号以后怎样进行处理（./nginx -s reload ）?首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自 master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出 。
3. worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master 进程fork(分配)过来，在master进程里面，先建立好需要listen的socket之后，然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。一般来说，当一个连接进来后，所有在accept在这个socket上面的进程，都会收到通知，而只有一个进程可以accept这个连接，其它的则accept失败，这是所谓的惊群现象。当然，nginx也不会视而不见，所以nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
4.nginx采用这种进程模型有什么好处呢？采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。
5.有人可能要问了，nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的 。对于IIS服务器每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。我们之前说过，推荐设置worker的个数为cpu的核数，在这里就很容易理解了，更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，提供了cpu亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效。
