Application server clustering of large website architecture

With the development of the website, one application server cannot handle too many user requests. Consider deploying multiple application servers to form a cluster to provide services. Is this the problem?

Question 1: When expanding to multiple application servers, two requests from the same user may be processed by different application servers. How do different application servers manage sessions at this time? (session management of application server clusters)
Question 2: How to evenly distribute requests to application servers in the cluster. (Load balancing of

application server clusters) Session management of
application server clusters: There are four methods for session management of application server clusters: session replication, session binding, session carried in cookies, and session server (or server cluster).
Session replication: When a user logs in for the first time on an application server, its session is replicated to other application servers in the cluster. As shown in the figure below:


Session binding: When a user logs in to an application server for the first time, the load balancing device will remember the application server, and each subsequent request of the user will be dispatched to the application server by the load balancing device for processing. As shown in the figure below:


Cookie carries session: The application server encapsulates the session in a cookie and returns it to the browser. For each subsequent request of the browser, the application server can obtain the session information from the cookie.


Session server (or cluster): A dedicated server or server cluster is used to store sessions, and all sessions used by the application server are stored on this server (in practical applications, the session server can utilize a database or a distributed cache system). As shown below:


After solving the session management of the application server cluster, the application server becomes "stateless": that is, the application server does not save context information, and each server in the cluster is completely equal. The request is submitted to each server and the processing result is the same. We call this statelessness of application servers.

Load balancing of application server clusters:
The statelessness of application servers makes load balancing possible. There are 5 kinds of load balancing methods, namely: http redirection load balancing, DNS domain name resolution load balancing, reverse proxy load balancing, IP load balancing, and data link layer load balancing (also known as triangular transmission mode).

http redirection load balancing:


dns domain name resolution load balancing: dns domain name resolution is usually used as the first level of load balancing, by parsing the request to different load balancing servers inside the website, and then these load balancing servers forward the request to the application on the server.


Reverse proxy server: Since the reverse proxy works at the http level, it is also called application layer load balancing.


IP load balancing: Load balancing is performed at the network layer by modifying the destination address of the request packet. The NAT mode of LVS works in this way.


Data chain layer load balancing: The IP address is not modified during the distribution process of the data chain layer load balancing, only the destination MAC address is modified, and the virtual IP of the application server and the IP of the load balancing server can be configured to be the same. Link layer load balancing is currently the most widely used load balancing method. The best link layer load balancing product under the Linux platform is LVS (linus virtual server). From


the above description, we can understand that as long as the server cluster is stateless, Then the server cluster can be scaled by means of load balancing. Therefore, not only application server clusters, but also service layer clusters can be scaled in this way. But for a distributed cache system, it is stateful, so this scheme cannot be used. See the next blog for details.





Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326987781&siteId=291194637