当前位置：首页 > 教程 > 正文内容

proxy和nginx的关系(nginx和haproxy的区别)

2023-06-05 01:00:09教程1

proxy和nginx的关系

1、从应用方面

tomcat一般是做动态解析才会用得到，支持jsp的解析，需要配置JDK支持。

nginx，则一般是做静态，本身不具备动态解析功能，需要配置其他插件或通过其他软件协同才具备动态功能，比如php，tomcat，或者proxypass到win2008的iis服务器做ASP的动态链接等，但nginx在静态上的功能非常强大，也可做访问控制，而且可以做成各种协议负载服务器，包括流媒体的也可以做，具体得去官方网站去看；

2、在性能方面

如果再不做系统调优的情况下，tomcat一般支持并发并不高100个差不多了；nginx在静态方面支持并发轻松达几万。

nginx和haproxy的区别

Nginx 跟 Haproxy 其实他们两个的定位是有所不同的，Nginx的定位是一个server，Haproxy的定位是一个load balancer。

Nginx通过各种plugin module可以支持Load balance的功能，而且性能不弱于haproxy太多，所以总有人拿来将两个东西比较。其实Apache也可以通过相关模块做load balancer，只不过性能差得多而已所以没人用而已。当然了Nginx的LB功能现在是其支柱主打功能而已。

看到有很多答案对于haproxy多进程有误解，这里特别说下，haproxy早就支持多进程模型，但是并不是Nginx的Worker Master结构，而是平等多进程结构，同时也支持REUSE PORT选项，所以在这里Nginx跟Haproxy对于多核利用上都是一样的并没有本质区别。

haproxy从1.8之后，添加了多线程的模式，现在它更推荐的也是这个模型，在一些平台上能够更好的利用多核。而Nginx从来没有多线程模型。而且看起来社区也没打算支持。

Nginx其实基于server的功能来说，是Haproxy不具备的，让Haproxy像一个普通Web server那样回复一个普通的HTTP请求是很难的，不大规模修改源码根本做不到。Haproxy是围绕转发模型设计的，整个流程就是围绕如何快速把一个请求或者回复转发到另一端。并不是像Server一样接受请求然后回复。

但是Nginx作为一个纯粹的LB来说，尤其是针对Web LoadBalancer来说，功能没有haproxy那么细致。Haproxy支持的ACL对象非常广泛，很多情况并不需要脚本辅助就可以完成复杂的功能，而Nginx稍微复杂的LoadBalance功能都需要使用脚本才能完成，这样性能就会差很多。

从功能角度上来讲，Nginx其实功能比Haproxy要多（当然并不都是免费的），因为他的开发社区和定位方向都比Haproxy要大和宽泛。在Nginx上面的各种解决方案也要多的多。比如WAF，haproxy一致都没有比较好的原生解决方案。还有包括最近针对Service Mesh的支持，haproxy都是很难跟得上。

但是基础功能，包括HTTP2，TLS 1.3，Script， SSL/TLS offload，ocsp，SNI preload，其实haproxy最新版本早就已经支持，甚至比Nginx还更早些（HTTP2比较晚，但是现在也支持了）。另外，关于硬件SSL offload支持其实主要是OpenSSL的engine的支持，所以这个大家都差不多，只要兼容最新OpenSSL都没什么问题。

Haproxy的优点其实是转发性能稍高，因为haproxy追求zero copy的forward流程，所以代码都倾向于优化在这一点上。但是这个优势现在被广泛的TLS/SSL应用抹平了，对比0 copy节省的时间来说加解密的消耗的性能占绝大多数，所以haproxy基本上在现在的广泛SSL环境下没有什么优势了。除非你想用纯HTTP，而且还想使用比较复杂的基于HTTP头部的Load Balance功能，那么Haproxy是个好选择，否则只是单纯LB的话，LVS性能其实更更高，毕竟人家在Kernel里面。

从代码层面来说，Nginx的结构化代码和模块化都比Haproxy好太多。Haproxy代码模块化一直是个大问题，内部结构模块化不足，二次开发困难，最近到1.9了才有些改善，但是仍然有很多内部trick的hack和让人发懵的FLAG。相比Nginx做到的彻底的模块化，可以轻易的通过开发自己的模块来改变或者实现相关功能，这个haproxy是不具备的。

从开发社区来说，Nginx也比Haproxy好太多，Haproxy虽然社区历史更久，但是一直都是不愠不火，贡献者因为原作者的严格的控制，一直都很少，再加上没有module开发功能，所以吸引的开发者一直都不多。带来的问题就是版本更新慢，支持的新功能慢。HTTP2的开发完全靠原作者一个人，所以支持进度严重拖后。

这篇文章看起来好像是变成了对haproxy吐槽，但是因为在工作中接触这两个东西实在太多，而且是进行深度二次开发，所以自认为还是有一定的了解的。从目前来看，如果haproxy不能更开放招募更多的贡献者，不能彻底修改架构支持module开发，是无法比拟NGINX的。

另外Haproxy优势一点的就是免费版的功能比Nginx免费版的更实惠。对于小又穷的站点的确是个好处。

nginx-proxy

nginx代理出现403异常，可通过以下几个原因排查：

一、由于启动用户和nginx工作用户不一致所致

1.1查看nginx的启动用户，发现是nobody，而为是用root启动的

命令：ps aux | grep "nginx: worker process" | awk'{print $1}'

1.2将nginx.config的user改为和启动用户一致，

命令：vi conf/nginx.conf

二、缺少index.html或者index.php文件，就是配置文件中index index.html index.htm这行中的指定的文件。

1. server {

2. listen 80;

3. server_name localhost;

4. index index.php index.html;

5. root /data/www/;

6. }

如果在/data/www/下面没有index.php,index.html的时候，直接文件，会报403 forbidden。

三、权限问题，如果nginx没有web目录的操作权限，也会出现403错误。

解决办法：修改web目录的读写权限，或者是把nginx的启动用户改成目录的所属用户，重启Nginx即可解决

1. chmod -R 777 /data

2. chmod -R 777 /data/www/

四、SELinux设置为开启状态（enabled）的原因。

4.1、查看当前selinux的状态。

1. /usr/sbin/sestatus

4.2、将SELINUX=enforcing 修改为 SELINUX=disabled 状态。

1. vi /etc/selinux/config

2. #SELINUX=enforcing

3. SELINUX=disabled

4.3、重启生效。reboot。

1. reboot

haproxy与nginx

从定位上来说，nginx重点是web服务器，替换的是apache，同时具备lb的作用，haproxy是单纯的lb，可以对照lvs进行比较

从架构上来说，进程模型不一样，haproxy是单进程方式无法充分利用多核，nginx是多进程模式

上手难易上来说，nginx的模块化更好，和lua之耦合比较紧密，比较方便进行业务模块的添加，开发起来轻量，haproxy需要多整体架构比较熟悉才能二次开发，haproxy在转发性能上略胜一筹，代码里面有很多geek的用法，比如rbtree非常高效

两个都是比较好的开源软件，nginx社区活跃，haproxy更新稍慢，比如https功能做了很久才发布

haproxy和nginx区别

Linux集群主要分成三大类( 高可用集群，负载均衡集群，科学计算集群)

高可用集群( High Availability Cluster)

负载均衡集群(Load Balance Cluster)

科学计算集群(High Performance Computing Cluster)

================================================

高可用集群(High Availability Cluster)

常见的就是2个节点做成的HA集群，有很多通俗的不科学的名称，比如"双机热备", "双机互备", "双机".

高可用集群解决的是保障用户的应用程序持续对外提供服务的能力。 (请注意高可用集群既不是用来保护业务数据的，保护的是用户的业务程序对外不间断提供服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度)

Linux平台常见的高可用集群有这些:

1. RedHat 公司的开放源代码RedHat Cluster Suite, 简称RHCS . (产品介绍

http://www.redhat.com/solutions/clustersuite/

)

- RHCS实际上是一个套件，除了现在提到的高可用集群软件，还包含了一个基于LVS的负载均衡软件.

- RHCS包含的集群软件，是GPL协议下开放源代码的集群系统.

- RHCS目前的版本有 RHCS v3和 v4,分别对应于RedHat 企业版Linux的 3.0家族和4.0家族.

- RHCS是一个独立的产品，不包括在RedHat Enterprise Linux当中，无论是购买还是下载，都是单独存在的.

RHCS的获得:

RHCS的获得有三个途径:

a. 从redhat 的官方销售渠道购买，得到的是RedHat RHCS产品的二进制代码(光盘或直接从RHN-RedHat Network下载)，源代码，以及支持和升级服务.

b. 从redhat 的官方站点下载SRPM包，编译并安装. 无原厂商业支持和升级服务. 这里下载 (ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHCS和ftp:/tp.redhat.com/pub/redhat/linux/enterprise/3/en/RHCS)

c. 从centOS官方站点下载RHCS的二进制代码包并安装，无原厂商业支持和升级服务. 这里下载(

http://mirror.centos.org/centos/4/csgfs/

, 请阅读此目录中的README文件)

nginx和proxy的区别

nginx的proxypath作用是为处理网站的html内容提供路径，实现server的效果，加一行proxy_redirect后，可以使得非公布域名可以被客户端识别。

值得注意的是，这个域名并非公布的域名，返回给客户端是会自然产生错误的。可以设置多个匹配规则与确保代理功能的完美实现。

haproxy和nginx

lvs解决负载均衡问题因为lvs是一种高性能的负载均衡工具，能够将大量的流量请求分发到多个服务器上，解决服务器负载不均衡、容易崩溃的问题，提高了应用系统的可靠性和稳定性。此外，lvs还能实现NAT转发、IP负载均衡、优先级路由等多种负载均衡方式，可以根据业务需求进行选择，更加灵活。随着互联网的快速发展和应用系统的不断壮大，负载均衡技术的应用越来越广泛。除了lvs外，还有HAProxy、nginx、F5等多种负载均衡工具可以选择，需要根据实际场景和需求进行选型。同时，负载均衡的配置和维护对于应用系统的正常运行也非常关键。

nginx与haproxy区别

可以测试一下，haproxy和转发性能要比Nginx要好，但CPU占用要高于Nginx。我测试过的数据，在相同的测试环境下(Hits per Second)， lvs (DR)=

1.6 W ， CPU = 25% Nginx = 2 W ， CPU = 80% Haproxy =

2.3 W ， CPU = 95%

nginx haproxy lvs区别

一、单DB架构

单DB架构一般就是nginx直接upstream请求到后端Tomcat，扩容时基本是增加新的Tomcat实例，然后通过Nginx负载均衡upstream过去，此时数据库还不是瓶颈，但是当访问量达到一定级别后数据库的压力就上来了，单个数据库可能扛不住，可以通过分表分库或者读写分离加缓存来解决。

二、DB+Cache/数据库读写分离架构

此时通过使用数据库读写分离或者Redis这种缓存来支撑更大的访问量，但是使用缓存会存在与数据库数据不一致的问题，或者Redis不能直接命中数据库导致数据库压力过大，可以考虑使用Redis的主从或者用一致性哈希算法做分片的Redis集群。使用缓存这种架构，要求应用对数据一致性的要求不是很高。

三、OpenResty+Local Redis+Mysql集群架构

OpenResty首先通过Lua读取本机Redis缓存，如果命不中，则回源到后端Tomcat集群，后端Tomcat集群再读取Mysql数据库，Redis都是安装到和OpenResty同一台服务器上，OpenResty直接读取本机可以减少网络延时。Redis通过主从方式同步数据。

四、OpenResty+Redis集群+Mysql集群架构

此时架构与之前架构不同的是，此时我们使用一致性哈希算法实现Redis集群，而不是读取本机Redis，保证其中一台不可用时，只有很少的数据会丢失，防止击穿到数据库。Redis集群分片可以使用Twemproxy如果Tomcat实例很多的话，就要考虑Redis和Mysql链接数问题，因为大部分Redis/Mysql客户端都是通过连接池实现，此时链接数会成为瓶颈，一般方法是通过中间件来减少链接数。

此时的问题就是Twemproxy实例众多，应用维护、配置困难，需要在这之上做负债均衡，比如，通过LVS/HaProxy实现VIP(虚拟Ip)，可以做到切换对应用透明，故障自动转移。还可以通过实现内网DNS来做其负载均衡。