Nginx offers several ways to solve the problems we mentioned earlier. The first and simplest of them is the weight flag, which can be enabled in the definition of your server group:

upstream MyUpstream { 
    server 10.0.0.201 weight=3; 
    server 10.0.0.202 weight=2; 
    server 10.0.0.203; 
} 

By default, servers have a weight of 1, unless you specify otherwise. Such a configuration enables you to give more importance to particular servers: the higher their weight, the more requests they will receive from Nginx. In this example, for every six HTTP requests received, Nginx will systematically distribute:

• Three requests to the 10.0.0.201 server (weight=3)
• Two requests to the 10.0.0.202 server (weight=2)
• One request to the 10.0.0.203 server (weight=1)

For every 12 requests, Nginx will distribute:

• Six requests to the 10.0.0.201 server (weight=3)
• Four requests to the 10.0.0.202 server (weight=2)
• Two requests to the 10.0.0.203 server (weight=1)

Nginx also includes a mechanism that will verify the state of servers in a group. If a server doesn't respond in time, the request will be re-sent to the next server in the group. There are several flags that can be assigned to servers in an upstream block that will allow you to better control this mechanism:

• fail_timeout=N, where N is the number of seconds before a request is considered to have failed.
• max_fails=N, where N is the number of attempts that should be performed on a server before Nginx gives up and switches to the next server. By default, Nginx only tries once. If all servers become unresponsive, Nginx will wait for fail_timeout to expire before resetting all server fail counts and trying again.
• max_conns=N, where N is the number of maximum concurrent connections that can be sent to that server. By default, Nginx will not limit concurrent connections.
• backup marks the server as backup server, instructing Nginx to use it only in the case of failure from another server (it is not used otherwise).
• down marks the server as permanently unavailable, instructing Nginx not to use it anymore.

Finally, Nginx offers plenty of options to achieve session affinity. They come under the form of directives that should be inserted within the upstream block. The simplest of them is ip_hash: this directive instructs Nginx to calculate a hash from the first 3 bytes of the client IPv4 address (or the full IPv6 address), and, based on that hash, keep the client assigned to a particular server. As long as the client IP address remains the same, Nginx will always forward requests to the same server in the upstream group:

upstream { 
    server 10.0.0.201 weight=3; 
    server 10.0.0.202 weight=2; 
    server 10.0.0.203; 
    ip_hash; 
} 

Some administrators may deem this method too unreliable, considering the fact that a majority of internet service providers across the globe still provide dynamic IP addresses, renewed on a 24-hour basis. So why not use your own distribution key? Instead of the client IP address, you could separate requests based on the criteria of your choice, thanks to the hash directive. Since the directive allows variables, you could decide to separate requests based on a cookie value:

upstream { 
    server 10.0.0.201; 
    server 10.0.0.202; 
    hash $cookie_username; 
} 

Based on the data contained in the username cookie, your visitors will be assigned to the first or the second server in the upstream group.