Reasonable use of nginxhash strategy for more meaningful load balancing

Foreword:

At present, many web applications, or web interfaces, use a server container to listen to the port at the entrance of the server, and then forward the request, such as nginx, Apache, etc.

The server container plays a vital role in the entire web service, including: it can well manage the service process, perform proxying, pre-process requests, and load balancing.

The focus of today's discussion is on the rational use of nginx's hash strategy for more meaningful load balancing in server clusters.

 

Overview:

When our service is supported by a single server, there is no concept of load balancing at all. Load balancing is only used when the service is supported by multiple servers (ie, server clusters).

Load balancing, as the name suggests, is a strategy used to prevent a situation where one server is overloaded while other servers are idle. Through this strategy, the load of servers providing the same service can be basically the same. To put it bluntly, when the client initiates a request, the load balancer will forward the request to an upstream server for processing through a preset policy.

as the picture shows:

Load balancing is a very mature technology, among which polling the back-end servers; hashing through the client's IP request; assigning weights to the back-end servers, etc., are relatively common load balancing strategies. I won't go into details here.

It is unreasonable to blindly adopt a load balancing strategy for services. Load balancing is a round-robin strategy by default, which is not efficient in some scenarios.

More meaningful load balancing:

The focus of today's explanation is on two common load balancing hash strategies and their corresponding usage scenarios.

1. ip_hash (request ip through the client to hash, and then select the back-end server through the hash value):

When a specific url path on your server is continuously accessed by the same user, if the load balancing strategy is still polling, the user's multiple accesses will be hit to each server, which is obviously not efficient (will establish multiple http links etc.). Even consider an extreme case, the user needs to upload the file to the server in shards, and then the server will merge the shards. If the user's request reaches different servers, the shards will be stored in different server directories. As a result, the shards cannot be merged. Therefore, such scenarios can consider using the ip_hash strategy provided by nginx. It can not only satisfy each user's request to the same server, but also satisfy the load balancing between different users.

The configuration code is as follows:

[plain]  view plain copy  

 

1. upstream backend{  
2.     ip_hash;  
3.         server 192.168.128.1:8080 ;  
4.         server 192.168.128.2:8080 ;  
5.         server 192.168.128.3:8080 down;  
6.         server 192.168.128.4:8080 down;  
7. }  
8. server {  
9.         listen 8081;  
10.         server_name test.csdn.net;  
11.   
12.         root /home/system/test.csdn.net/test;  
13.   
14.     location ^~ /Upload/upload {  
15.             proxy_pass http://backend;  
16.     }  
17.   
18. }  

The above is a minimalist nginx service listening on port 8081. When the request url is /Upload/upload, the ip_hash strategy will be followed; upstream is the load balancing module of nginx. Here, the strategy is configured as ip_hash to participate in load balancing There are four machines, of which the last two have the keyword down added at the end, indicating the meaning of offline.

 

2、url_hash（通过请求url进行hash，再通过hash值选择后端server）：

一般来讲，要用到urlhash，是要配合缓存命中来使用。举一个我遇到的实例：有一个服务器集群A，需要对外提供文件下载，由于文件上传量巨大，没法存储到服务器磁盘中，所以用到了第三方云存储来做文件存储。服务器集群A收到客户端请求之后，需要从云存储中下载文件然后返回，为了省去不必要的网络带宽和下载耗时，在服务器集群A上做了一层临时缓存（缓存一个月）。由于是服务器集群，所以同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。在此类场景下，为了使得缓存命中率提高，很适合使用url_hash策略，同一个url（也就是同一个资源请求）会到达同一台机器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取，既减少了带宽，也减少的下载时间。

配置代码如下：

[plain]  view plain  copy

 

1. upstream somestream {  
2.         hash $request_uri;  
3.         server 192.168.244.1:8080;  
4.     server 192.168.244.2:8080;  
5.         server 192.168.244.3:8080;  
6.         server 192.168.244.4:8080;  
7. }  
8. server {  
9.         listen       8081 default;  
10.         server_name  test.csdn.net;  
11.         charset utf-8;  
12.         location /get {  
13.         proxy_pass http://somestream;  
14.     }  
15. }  

The above is also a minimal nginx service that listens to port 8081. When the request url is /get, it will go through url_hash; the upstream module is also configured, and hash $request_uri indicates that the hash policy is performed according to the url rules.

 

Summarize:

The above is all the content to be introduced in this article. This article focuses on the usage scenarios and basic configuration of ip_hash and url_hash. In addition, when configuring nginx server, you can be more flexible. Different locations use different strategies, which can make the service strategy more efficient. Reasonable. Hope this article can bring you some help.