What is a Sticky? In order to understand how Sticky works, we can first consider a question: how does load balancing work?
DNS resolution, assigned to different server IPs during domain name resolution;
IP Hash, according to the client's IP, assign requests to different servers;
cookie, the server sends a cookie to the client, and requests with a specific cookie are assigned to its issuer.
Sticky is a cookie-based load balancing solution. The session between the client and the back-end server is maintained through cookies. Under certain conditions, it can be guaranteed that the same client accesses the same back-end server. When the request comes, the server sends a cookie and says: bring it next time, come to me directly.
For the convenience of description, the cookies in the text all refer to the cookies used by sticky.
#Sticky works Sticky is a module of nginx, which makes requests from the same client fall on the same server by distributing and identifying cookies. Sticky is handled as follows (assuming the cookie name is route):
1. The client initiates a request for the first time, and the request header does not contain the route cookie. nginx receives the request and finds that there is no route in the request header, and allocates the request to the backend server in a round- robin manner.
2. After the back-end server processes the request, it returns the response header and content to nginx.
3. nginx generates the route cookie and returns it to the client. The value of route corresponds to the backend server, which may be plaintext or hash values such as md5 and sha1.
4. The client receives the request and creates a cookie for the route .
5. When the client sends the request again, bring the route .
6. nginx receives the route and transfers it directly to the corresponding backend server.
The detailed configuration process for sticky is here .
#Parameter parsing
语法：session_sticky [cookie=name] [domain=your_domain] [path=your_path] [maxage=time] [mode=insert|rewrite|prefix] [option=indirect] [maxidle=time] [maxlife=time] [fallback=on|off] [hash=plain|md5]
Default: session_sticky cookie=route mode=insert fallback=on
context: upstream
illustrate:
This command can open the function of session retention. The following are the specific parameters:
cookie set the name of the cookie used to record the session
domain sets the domain name of the cookie, not set by default
path sets the URL path of the cookie, not set by default
maxage sets the lifetime of the cookie. If it is not set by default, it is a session cookie, which will be invalid when the browser is closed.
mode sets the mode of the cookie:
insert: In the reply, this module directly inserts the cookie with the corresponding name through the Set-Cookie header.
prefix: A new cookie will not be generated, but a specific prefix will be added in front of the cookie value of the response. When the browser requests again with this cookie with a specific identifier, the module deletes the added cookie before passing it to the backend service. prefix, the backend service still gets the original cookie value, and these actions are transparent to the backend. For example: "Cookie: NAME=SRV~VALUE".
rewrite: Use the server ID to override the session sticky cookie set by the backend. If the backend service does not set the cookie in the response header, it is considered that the request does not need session sticky. Using this mode, the backend service can control which requests require session sticky and which requests do not.
option Set options for session sticky cookies, which can be set to indirect or direct. Indirect will not transmit session sticky cookies to backend services, which are completely transparent to backend applications. direct is the opposite of indirect.
maxidle sets the longest idle timeout for session cookies
maxlife sets the maximum lifetime of the session cookie
fallback sets whether to retry other machines, when sticky's backend machine hangs up, do you need to try other machines
Hash sets whether the server identifier in the cookie is in plain text or md5 value, and md5 is used by default
maxage is the lifetime of the cookie. If it is not set, it will be invalid after the browser or App is closed. On the next startup, the backend servers are randomly assigned again. So if you want the client's request to fall on the same backend server for a long time, you can set maxage.
Whether it is plaintext or hash value, hash has a fixed number. Because the hash is the identifier of the server, there are as many servers as there are hash values.
#some exceptions#
##Requests from the same client may fall on different backend servers##If the client initiates multiple requests at the same time. Since none of these requests carry cookies, the server will randomly select the backend server and return different cookies. When the last of these requests returns, the client's cookie is stabilized, and the value is based on the last returned cookie.
##Cookie does not necessarily take effect## Since the cookie is initially sent by the server, if the client disables the cookie, the cookie will not take effect.
##Clients may not carry cookies## When an Android client sends a request, it generally does not bring all cookies, and it is necessary to explicitly specify which cookies will be carried. If you want to use sticky for load balancing, please add cookies to Android development.
#Notes* The cookie name should not be the same as the cookie name used by the business. Sticky's default cookie name is route, which can be changed to any value. But remember, it cannot have the same name as the cookie used in the business. * The first request sent by the client is without cookies. The cookie sent by the server takes effect only when the client requests the next time.