为什么要选择 nginx，和其他常见的负载均衡库对比有什么优缺点？

选择 Nginx 作为负载均衡器有很多原因，主要包括其性能、灵活性和广泛的功能。

Nginx 的优点

  1. 高性能和低资源占用：
    • Nginx 以其高性能和低资源占用著称。它可以处理大量的并发连接，适用于高流量网站。
  2. 灵活的配置：
    • Nginx 提供了丰富的配置选项，允许用户根据具体需求进行细致的调整。它支持多种负载均衡算法，如轮询（Round Robin）、最少连接（Least Connections）和 IP 哈希（IP Hash）。
  3. 广泛的功能：
    • Nginx 不仅是一个负载均衡器，还是一个功能强大的反向代理服务器、HTTP 服务器和邮件代理服务器。它支持 SSL/TLS 加密、HTTP/2、缓存、压缩等多种功能。
  4. 开源和社区支持：
    • Nginx 是开源软件，有一个活跃的社区提供支持和插件扩展。大量的文档和资源可以帮助用户快速上手和解决问题。

Nginx 的缺点

  1. 配置复杂性：
    • 虽然 Nginx 非常灵活，但其配置文件语法对新手来说可能比较复杂，需要一定的学习曲线。
  2. 高级功能的商业版：
    • 一些高级功能（如更高级的负载均衡算法和监控功能）仅在 Nginx Plus（商业版）中提供，需要额外付费。

与其他常见负载均衡解决方案的对比

HAProxy

优点：

  • 专为负载均衡设计：HAProxy 是专门为负载均衡设计的，性能极佳，可以处理极高的并发连接数。
  • 多种负载均衡算法：提供多种负载均衡算法，适应不同场景需求。
  • 强大的健康检查：HAProxy 提供详细的健康检查机制，可以确保后端服务器的健康状态。

缺点：

  • 功能单一：与 Nginx 的多功能相比，HAProxy 主要专注于负载均衡和反向代理，不支持如静态文件服务等功能。
  • 配置复杂：HAProxy 的配置文件也相对复杂，特别是对于复杂的负载均衡策略。

Apache HTTP Server (with mod_proxy_balancer)

优点：

  • 成熟且稳定：Apache HTTP Server 是一个非常成熟且稳定的服务器软件，适用于各种 web 应用场景。
  • 模块化设计：通过模块（如 mod_proxy 和 mod_proxy_balancer）扩展功能，增加了灵活性。

缺点：

  • 性能较低：相对于 Nginx 和 HAProxy，Apache 的性能稍逊一筹，特别是在处理高并发连接时。
  • 较高的资源消耗：Apache 的资源消耗相对较高，可能在高流量场景下表现不如 Nginx。

AWS Elastic Load Balancing (ELB)

优点：

  • 与 AWS 集成：ELB 深度集成到 AWS 生态系统中，适合使用 AWS 其他服务的用户。
  • 自动伸缩：ELB 可以根据流量自动伸缩，减少用户的运维负担。
  • 高可用性：由 AWS 提供和管理，保证了高可用性和稳定性。

缺点：

  • 成本：使用 ELB 会产生额外的费用，对于流量较大的用户可能成本较高。
  • 控制有限：相比于自托管的负载均衡器，ELB 的配置和控制选项相对有限。

为什么选择 Nginx

为什么NGINX如此重要？

因为它是应用程序路由结构的一部分。当然，路由是一项非常关键的功能，因为它可以实现负载平衡。负载平衡是高可用性系统的关键推动因素。运行这些系统需要“多一切”：一个服务器，一个数据中心，一个区域，区域，提供商等等。如果没有负载均衡器，您就无法在冗余单元之间路由请求。

但是为什么选择NGINX而不是其他东西，比如Pound？

我们喜欢 Pound。它易于部署和管理。没有什么问题。

事实上，只要您的负载平衡设置没有任何特殊要求，它就是一个很好的选择。

特殊要求？

好吧，在我们的例子中，我们想要处理WebSocket请求。我们需要支持更快的SPDY和HTTP2协议。我们还想使用Tornado Web框架。所以，在与Pound呆了一段时间之后，我们最终选择了NGINX开源。

NGINX是一个事件驱动的Web服务器，具有内置的代理和负载平衡功能。它具有对FCGI和uWSGI协议的内置本机支持。这允许我们在快速应用程序服务器（如uWSGI）中运行Python WSGI应用程序。

NGINX还支持第三方模块，用于完整的TCP/IP套接字处理。这允许我们在异步WebSocket Python应用程序和上游Node.js代理之间进行选择和混合。

更重要的是，NGINX可通过Puppet完全部署和配置。

为什么需要之2

其他讨论

POST-1

我最近遇到了一个博客（不是数字海洋博客，其他一些博客），说Nginx的性能优于Apache，因为“Nginx没有为新请求创建新流程。

Apache为每个请求创建一个新进程“这不完全正确，Apache MPM有两个模型，

1。Prefork（Above语句适用于此模型）

2。Worker工作者MPM为每个进程使用具有多个线程的进程。每个线程一次处理一个连接。此模型适用于高性能Web服务器。

我没有在Nginx上工作，但是用Apache（Tuned）和lighthttpd管理了很少的高流量网站。我想更多地了解Nginx对Apache或lighthttpd的性能优势。是否进行过任何研究/负载测试以证明Nginx在高流量网站上的性能优于Apache（Tuned）？

请用数据支持你的陈述。 （在Data中，我们相信其余的是;）

Post 2-（响应事件驱动的拱门）

同意Buddy :) Nginx是事件驱动的，从设计角度看是异步的，我想这对于长期运行但尺寸较小的更多请求非常有用（示例移动） 正如ONESTONE所说：

“Nginx使用Reactor模式。基本上，它是单线程的（但可以分叉多个进程以利用多个核心。）主事件循环等待操作系统发出准备事件信号 - 例如，数据可用于从套接字读取，在这一点上，它被读入一个缓冲区并进行处理。单个线程可以非常有效地服务数万个同时连接（由于巨大的上下文切换开销，每个连接线程模型都会失败，以及大内存消耗，因为每个线程都需要自己的堆栈）“

但Apache有一个解决方案 - 事件MPM（http://httpd.apache.org/docs/2.2/mod/event.html）

据我所知，此修复程序是实验性的，并且与https有问题:( 但是，根据凯文的说法，当“你在给定的服务器上运行纯PHP内容时，Apache可能超过Nginx，Apache似乎仍然是这项工作的最佳选择。”

http://www.eschrade.com/page/why-is-fastcgi-w-nginx-so-much-faster-than-apache-w-mod_php/

我会按照以下方式设计，

  • CDN（CSS，JS和图像）

*从Apache运行PHP（调优）

正如我之前提到的，我不知道Nginx（从未使用过它）所以想法是学习和进化。在需要和可能时利用Nginx。 我从来没有带任何先入为主的观念/行李教条:)只是一个生活/事件的学生:)

VS HAProxy

负载均衡

负载平衡器是数据中心的入口点。 他们正处于访问任何事物和一切的关键路径上。

这给了他们一些有趣的特征。

首先，它们是在基础设施中监控的最重要的事情。

其次，他们处于一个独特的位置，不仅可以提供有关自己的见解，还可以提供他们所支持的每项服务。

有两种流行的开源软件负载平衡器：HAProxy和nginx。 让我们看看他们在这方面的比较。

启用负载平衡器上的监控

它应该是系统化的一切生产。

  1. 安装新的东西

  2. 启用统计信息和监控内容

  3. 启用日志

从负载均衡器收集指标

有标准的监控解决方案：datadog，signalfx，prometheus，graphite …

这些工具从应用程序，服务器和基础架构收集指标 它们允许探索指标，绘制图表并发送警报。

将负载平衡器集成到我们的监控系统中至关重要。 我们需要了解活动客户端，QPS，错误率等…

毋庸置疑，监控功能将受到负载均衡器测量和提供的信息的限制。

Nginx

nginx只提供7种不同的指标。

Nginx仅在所有站点上给出总和。

每个站点或每个应用程序都不可能获得任何数量。

Active connections: The current number of active client connections
    including Waiting connections.
accepts: The total number of accepted client connections. 
handled: The total number of handled connections. Generally, the 
    parameter value is the same as accepts unless some resource
    limits have been reached (for example, the worker_connections limit). 
requests: The total number of client requests. 
Reading: The current number of connections where nginx is reading the
    request header. 
Writing: The current number of connections where nginx is writing the
    response back to the client. 
Waiting: The current number of idle client connections waiting for a request.

HAProxy

HAProxy提供61种不同的指标。

数字是全局，每个前端和每个后端（无论哪个有意义）。

它们可在人类可读的网页上以原始CSV格式提供。

0. pxname [LFBS]: proxy name
1. svname [LFBS]: service name (FRONTEND for frontend, BACKEND for backend,
any name for server/listener)
2. qcur [..BS]: current queued requests. For the backend this reports the
number queued without a server assigned.
3. qmax [..BS]: max value of qcur
4. scur [LFBS]: current sessions
5. smax [LFBS]: max sessions
6. slim [LFBS]: configured session limit
7. stot [LFBS]: cumulative number of connections
8. bin [LFBS]: bytes in
9. bout [LFBS]: bytes out
[...]
32. type [LFBS]: (0=frontend, 1=backend, 2=server, 3=socket/listener)
33. rate [.FBS]: number of sessions per second over last elapsed second
34. rate_lim [.F..]: configured limit on new sessions per second
35. rate_max [.FBS]: max number of new sessions per second
36. check_status [...S]: status of last health check, one of:
37. check_code [...S]: layer5-7 code, if available
38. check_duration [...S]: time in ms took to finish last health check
39. hrsp_1xx [.FBS]: http responses with 1xx code
40. hrsp_2xx [.FBS]: http responses with 2xx code
41. hrsp_3xx [.FBS]: http responses with 3xx code
42. hrsp_4xx [.FBS]: http responses with 4xx code
43. hrsp_5xx [.FBS]: http responses with 5xx code
44. hrsp_other [.FBS]: http responses with other codes (protocol error)
[...]

ps: 监控应该目前有专门的系统。信息的多少不重要，重要程度才是要关心的。

个人总结

我选择这一节单独写，主要是为了看看 nginx 的优势。

当然所有的技术都会有短板，纠结于技术的好坏本身并没有意义。

我们能把技术用到什么程度，这才是关键。

Nginx 的使用者很多，生态也足够好，这就足以成为其使用的原则。

至于原理，则是在学会使用之后我们需要搞懂的东西。

拓展阅读

Apache

参考资料

Why we use NGINX

What is nginx and why might I want to use it over apache?

Why Use Nginx?

HAProxy vs nginx: Why you should NEVER use nginx for load balancing!