Shulou(Shulou.com)06/02 Report--

Session persistence (Session Affinity), sometimes called sticky session (Sticky Sessions), is not only one of the important problems to be solved in the field of load balancing design, but also a relatively complex problem.

Session persistence refers to a mechanism on the load balancer that not only completes the load balancing task, but also distributes a series of related access requests to a server.

When the user initiates a request to the server, the server creates a session and writes the session id back to the customer in the form of cookie.

Look at an example: when I visit the SAP UI5 application

Observe in the header of the http request that the client requires the server to return the request field that returns session id in the form of cookie:

Sure enough, session id is returned in the header field of the server response:

This cookie information can be viewed in the Cookies area of the Application tab of the Chrome developer tool:

In this way, as long as the client's browser is not closed, when you visit the server, the access request will automatically attach a session id. When the server detects the session id, it will use the session maintained in memory to serve the client.

Let's go back to the topic of conversation persistence. When do you need session persistence? For example, when you shop on Taobao or JD.com, from completing user authentication to browsing the store, choosing your favorite products to join the shopping cart, and finally placing an order to complete the payment, you need to go through many interactions with the server to complete the entire transaction. Because these interactions are closely related sequentially and logically, the server needs a Context, that is, the output of the previous interaction, when performing one of the interaction steps of these interactions, so it requires that these related interactions are completed by one server.

In this case, assuming that the load balancer still distributes the session of these related interactions to different server instances, it will lead to a very bad user experience, such as the login page pops up every time the customer clicks on the browser. Or even if the user enters the correct CAPTCHA, it still prompts the CAPTCHA error. Due to the different server processing instances, it is also possible to lose the items that the customer put into the shopping cart.

This is why the session persistence mechanism is introduced: to ensure that requests for a full session from the same client are forwarded to the same server in the background for processing.

So how is Cloud Foundry's Session Affinity implemented?

The official document describes:

Https://docs.cloudfoundry.org/concepts/http-routing.html#sessions

(1) To support sticky sessions, configure your app to return a JSESSIONID cookie in responses. The app generates a JSESSIONID as a long hash in the following format:

Your application needs to add a JSESSIONID field to the response result with the length as follows:

1A530637289A03B07199A44E8D531427

(2) If an app returns a JSESSIONID cookie to a client request, the CF routing tier generates a unique VCAP_ID for the app instance based on its GUID in the following format

CF routing tier generates a VCAP_ID based on the JSESSIONID generated by app: 323f211e-fea3-4161-9bd1-615392327913

(3) next, each time the customer initiates a request, both JSESSIONID and VCAP_ID must be provided. JSESSION_ID is handed over to the application to achieve session adhesion. VCAP_ID is used to identify the application instance of the service. If the application fails, gorouter will route the request to another application instance.

For more original Jerry articles, please follow the official account "Wang Zixi":

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.