精通Nginx：实战指南与高级应用

需积分: 10 88 浏览量更新于2024-07-18 收藏 3.41MB PDF 举报

《完整的Nginx Cookbook》是一本由Derek De Jonghe撰写的权威指南，全面介绍了如何在IT行业中高效利用Nginx，一本专为系统管理员、开发人员和运维工程师设计的实用教程。该书不仅涵盖了基础配置和安装，还深入探讨了高级应用部署、负载均衡、内容缓存、Web服务器功能、安全控制以及监控和管理等方面，旨在帮助读者实现无瑕的应用交付。作为NGINX技术的经典参考书籍，作者通过丰富的实践案例和详尽的步骤，确保读者能够快速掌握如何在实际环境中部署和优化Nginx，提升网站性能和稳定性。《完整的Nginx Cookbook》特别强调了负载均衡功能，这对于现代Web服务架构至关重要，它可以帮助分散流量压力，提高系统的可扩展性和可用性。此外，书中也讲解了如何利用Nginx的缓存机制来加速静态内容的访问，从而节省服务器资源，同时提供更快的用户体验。安全控制是另一个关键部分，书中详细介绍了如何设置防火墙规则、SSL/TLS配置，确保网络通信的安全可靠。对于那些关注监控和管理的读者，该书会介绍如何通过各种工具和技术来监控Nginx的工作状态，及时发现和解决问题，以及如何进行有效的维护和日志管理，确保系统的稳定运行。《完整的Nginx Cookbook》适合于各个层次的读者，无论是初学者想要系统学习Nginx，还是经验丰富的技术人员寻求更深入的理解和实战技巧，都能从中受益。书中提供的FREETRIAL和LEARNMORE选项，使得读者可以先体验一部分内容，然后决定是否购买完整版以获取更全面的知识。版权信息方面，《完整的Nginx Cookbook》由O'Reilly Media Inc.出版，2017年首次发行，享有所有权利。本书已在全球多个城市发行，并支持在线购买。此外，还列出了编辑、审稿人、设计师等团队成员的名字，体现了出版行业的专业性和对质量的把控。《完整的Nginx Cookbook》是一本不可或缺的IT资源，无论是在个人学习还是团队协作中，都能为Nginx的管理和优化提供强大的支撑，帮助读者构建高性能、安全的网络服务架构。

ber of connections, DNS resolvers, and connection ramp-up peri‐

ods; and if the server is active, down, or in backup mode.

NGINX Plus offers even more features for TCP load balancing.

These advanced features offered in NGINX Plus can be found

throughout Part I of this book. Features available in NGINX Plus,

such as connection limiting, can be found later in this chap‐

ter. Health checks for all load balancing will be covered in Chapter 2.

Dynamic reconfiguration for upstream pools, a feature available in

NGINX Plus, is covered in Chapter 8.

1.3 Load-Balancing Methods

Problem

Round-robin load balancing doesn’t fit your use case because you

have heterogeneous workloads or server pools.

Solution

Use one of NGINX’s load-balancing methods, such as least connec‐

tions, least time, generic hash, or IP hash:

upstream backend {

least_conn;

server backend.example.com;

server backend1.example.com;

}

This sets the load-balancing algorithm for the backend upstream

pool to be least connections. All load-balancing algorithms, with the

exception of generic hash, will be standalone directives like the pre‐

ceding example. Generic hash takes a single parameter, which can be

a concatenation of variables, to build the hash from.

Discussion

Not all requests or packets carry an equal weight. Given this, round

robin, or even the weighted round robin used in examples prior, will

not fit the need of all applications or traffic flow. NGINX provides a

number of load-balancing algorithms that can be used to fit particu‐

lar use cases. These load-balancing algorithms or methods can not

only be chosen, but also configured. The following load-balancing

methods are available for upstream HTTP, TCP, and UDP pools:

4 | Chapter 1: High-Performance Load Balancing

Round robin

The default load-balancing method, which distributes requests

in order of the list of servers in the upstream pool. Weight can

be taken into consideration for a weighted round robin, which

could be used if the capacity of the upstream servers varies. The

higher the integer value for the weight, the more favored the

server will be in the round robin. The algorithm behind weight

is simply statistical probability of a weighted average. Round

robin is the default load-balancing algorithm and is used if no

other algorithm is specified.

Least connections

Another load-balancing method provided by NGINX. This

method balances load by proxying the current request to the

upstream server with the least number of open connections

proxied through NGINX. Least connections, like round robin,

also takes weights into account when deciding to which server

to send the connection. The directive name is least_conn.

Least time

Available only in NGINX Plus, is akin to least connections in

that it proxies to the upstream server with the least number of

current connections but favors the servers with the lowest aver‐

age response times. This method is one of the most sophistica‐

ted load-balancing algorithms out there and fits the need of

highly performant web applications. This algorithm is a value

add over least connections because a small number of connec‐

tions does not necessarily mean the quickest response. The

directive name is least_time.

Generic hash

The administrator defines a hash with the given text, variables

of the request or runtime, or both. NGINX distributes the load

amongst the servers by producing a hash for the current request

and placing it against the upstream servers. This method is very

useful when you need more control over where requests are sent

or determining what upstream server most likely will have the

data cached. Note that when a server is added or removed from

the pool, the hashed requests will be redistributed. This algo‐

rithm has an optional parameter, consistent, to minimize the

effect of redistribution. The directive name is hash.

1.3 Load-Balancing Methods | 5

about how many connections are handled by each server and how

many requests are queued.

Discussion

In dealing with distribution of load, one concern is overload. Over‐

loading a server will cause it to queue connections in a listen queue.

If the load balancer has no regard for the upstream server, it can

load the server’s listen queue beyond repair. The ideal approach is

for the load balancer to be aware of the connection limitations of the

server and queue the connections itself so that it can send the con‐

nection to the next available server with understanding of load as a

whole. Depending on the upstream server to process its own queue

will lead to poor user experience as connections start to timeout.

NGINX Plus provides a solution by allowing connections to queue

at the load balancer and by making informed decisions on where it

sends the next request or session.

The max_conns parameter on the server directive within the

upstream block provides NGINX Plus with a limit of how many

connections each upstream server can handle. This parameter is

configurable in order to match the capacity of a given server. When

the number of current connections to a server meets the value of the

max_conns parameter specified, NGINX Plus will stop sending new

requests or sessions to that server until those connections are

released.

Optionally, in NGINX Plus, if all upstream servers are at their

max_conns limit, NGINX Plus can start to queue new connections

until resources are freed to handle those connections. Specifying a

queue is optional. When queuing, we must take into consideration a

reasonable queue length. Much like in everyday life, users and appli‐

cations would much rather be asked to come back after a short

period of time than wait in a long line and still not be served. The

queue directive in an upstream block specifies the max length of the

queue. The timeout parameter of the queue directive specifies how

long any given request should wait in queue before giving up, which

defaults to 60 seconds.

1.4 Connection Limiting | 7

剩余180页未读，继续阅读

太阳下山明早依旧爬上来

粉丝: 9
资源: 9

精通Nginx：实战指南与高级应用

The Complete NGINX Cookbook

Complete-NGINX-Cookbook-2019.pdf

complete_nginx_cookbook.pdf

boost asio cookbook pdf

llvm cookbook 中文版

apache maven cookbook 下载

javascript cookbook 是什么

pandas cookbook中文版

正则表达式cookbook pdf

cmake cookbook pdf下载

最新资源