Tomcat cluster mechanism analysis and production deployment selection

Tomcat cluster mechanism analysis and production deployment selection
Why cluster?

Why cluster? There are two main reasons: first, for some core system requirements, services cannot be interrupted for a long time. To provide high availability, we need a cluster composed of multiple machines. On the other hand, as the traffic increases and the business logic becomes more and more complex, the processing capability of a single machine is insufficient to handle so many and complex logic. Therefore, a number of machines need to be added to improve the processing capability of the entire service.

Where are the cluster difficulties?

If a web application does not involve sessions, it is quite simple to create a cluster because nodes are stateless and nodes in the cluster do not need to communicate with each other, you only need to evenly distribute requests to the cluster nodes. However, basically all web applications use the session mechanism. Therefore, the whole difficulty for web Application Clusters lies in the synchronization of session data.

Of course, you can avoid complicated data synchronization operations through some strategies, such as storing session information in the distributed cache or centralized management in the database as mentioned above, for example, each tomcat instance only needs to write data to or read data from the database to avoid communication between tomcat clusters. However, this method is insufficient. We need to introduce additional database or cache services and ensure their high availability, which increases machine and maintenance costs.

Full-node session Synchronization Model

 

In view of the shortcomings in storing sessions in the database or cache in a unified manner, another solution is to synchronize data between tomcat cluster nodes, no matter which node you access, you can find the corresponding session. For example, if the client first accesses the generated session, tomcat will synchronize the session information to other nodes, in addition, each request is completed and all the operations on the session will be synchronized during the request process. In this way, the response session information can be found at any node in the cluster in the next request, and the information is timely guaranteed. If any node goes down, the overall external service is not affected.

Session backup single-Node Model

The second cluster session management mechanism provided by Tomcat is the single-node backup mechanism. Let's take a look at the specific working mechanism of this method. The cluster generally provides the overall service through Server Load balancer, all nodes are hidden in the backend to form a whole. The implementation of the preceding modes does not require the assistance of Server Load balancer, so the Server Load balancer is omitted in the figure. The most common load method is to use apache to drag all nodes. It supports the "326257DA6DB76F8D2E38F2C4540D1DEA. the session id of tomcat1 is decomposed and located on the node named tomcat1 In the tomcat cluster (this method is called SessionStick, implemented by the apachejk module ). Each session has an original and a backup, and the backup and the original are not stored on the same node. For example, when the client initiates a request and is distributed to the worker AT1 instance node through Server Load balancer, generate an include. the session id of the tomcat1 suffix, And the tomcat1 node selects the node backed up by the session object according to certain policies, and then contains the {session id, the backup ip} information is sent to tomcat2, tomcat3, and tomcat4, as shown in the dotted line, so that each node has a session id and backup ip list, that is, each node has a backup IP address for each session.

After completing the preceding step, back up the session content to the backup node. If the backup addresses of the s1 and s2 sessions of tomcat1 are Tomcat 2, back up the session object to Tomcat 2, similarly, Tomcat 2 backs up s3 sessions to Tomcat 4, and Tomcat 4 backs up s4 and s5 sessions to Tomcat 3, so that all sessions in the cluster have a backup. When the Session 1 fails, the SessionStick client will continue to access the worker AT1 node to ensure that the session can be obtained. When tomcat1 fails, tomcat also provides a failover mechanism. apache perceives that the worker AT1 node in the backend cluster is removed, and then requests are randomly allocated to any other node, there are two scenarios:

① The backup node tomcat2 can still get the s1 session. In addition, tomcat2 also needs to mark this s1 session as the original and continue to select a backup address to back up the s1 session, so that there is a backup again.

② If the non-Backup node atat3 is found, the s1 session cannot be found at this time, so it will ask all nodes in the cluster, "Who has the backup IP address of the s1 session ?", Because only atat2 has s1 backup address information, it receives the request and replies to inform tomcat3 node that the s1 session backup is in tomcat2. Based on this information, the s1 session can be found, in addition, tomcat3 generates an s1 session locally and marks it as the original, and the copy on tomcat2 remains unchanged. In this way, the s1 session can also be found, and the entire request is processed normally.

 

Production deployment selection

Both models have their own advantages and disadvantages. in actual production, you should select a suitable model based on the actual situation.

For the full-node session Synchronization Model

In details, it is easy to find that the sessions between nodes in the cluster are replicated to each other. Once the number of nodes in the cluster and the amount of access are large, a large amount of session information needs to be copied and synchronized to each other, it is easy to cause network congestion, and these synchronization operations may become the bottleneck of overall performance. Based on experience, this solution recommends 3-6 cluster nodes in actual production, it cannot build a larger cluster, and it has a large amount of data redundancy and a low utilization rate.

For the cluster incremental session manager, you can use it by configuring the server. xml file. To use the cluster mode in tomcat, you must Add under Node The cluster incremental Session Manager adds a subnode under this node.

For the session backup Model

The network traffic of the above full-node session Synchronization Model is increasing by square as the number of nodes increases. It is precisely because of this that large-scale clusters cannot be built, to make cluster nodes larger, the primary solution is traffic growth during data replication. tomcat proposes a session backup model to optimize the previous model, it increases the network traffic of session backup linearly with the increase of the number of nodes. Each session has only one backup, which greatly reduces network traffic and logical operations, this model can be used to build large clusters. A production cluster can contain more than 10 nodes.

For the cluster backup session manager, you can use it by configuring the server. xml file. Its configuration is similar to that of DeltaManager. Add a subnode under the node.

This model also needs to be considered. Although this mode supports a larger cluster, it only has one data backup. If the source data and the machine where the backup data is located are down at the same time, there is no way to recover the data, but the probability of downtime is very small.