Analysis of tomcat cluster mechanism and its production and deployment selection

Why use a cluster?

Why use a cluster? There are two main reasons: first, for some core systems require long-term non-disruptive services, in order to provide high availability we need a cluster of multiple machines, on the other hand, as the traffic becomes more and more complex business logic, single machine processing capacity is not enough to deal with so many and complex logic, A number of additional machines are required to improve the overall service processing capacity.

Where is the cluster difficulty?

If a Web application does not involve a session, then the cluster is quite simple, because the nodes are stateless, the nodes in the cluster do not need to communicate with each other, only need to evenly distribute the individual requests to the cluster node. But basically all Web Applications use session mechanisms, so the whole difficulty in making a Web application cluster is the synchronization of session data.

Of course, there are some strategies you can use to circumvent complex amounts of data synchronization operations, such as the one mentioned earlier to save session information in a distributed cache or database unified centralized management, such as, each tomcat instance only to write or read the database, to avoid the the communication between Tomcat clusters. However, there are shortcomings in this approach, as well as the additional introduction of database or caching services, while ensuring their high availability and increased machine and maintenance costs.

Full node session synchronization model

Given the lack of a unified session to the database or cache, providing another solution is that the Tomcat cluster node itself completes its own data synchronization, regardless of which node is accessed to find the corresponding session, such as the first time the client accesses the build session, Tomcat It synchronizes the session information to the other nodes, and it synchronizes the request during each request completion . Session all operations, so that the next request to any node in the cluster can find the response session information, and can guarantee the timeliness of information. And any one node is down and does not affect the overall external services.

Session Backup single node model

TomcatThe second type of cluster session management mechanism is a single-node backup mechanism, the following look at the specific mechanism of this approach, the cluster is generally through load balancing to provide overall services, all nodes are hidden in the backend to form a whole. The previous implementations of the various modes do not require load balancing assistance, so load balancing is omitted from the diagram. The most common way to load is in frontApachedrag all nodes, and it supports a similar "326257DA6DB76F8D2E38F2C4540D1DEA.TOMCAT1"the sessionIDTo decompose and navigate toTomcatin the cluster toTOMCAT1named node (this method is calledSession Stick, byApache JKmodule implementation). There is one original and one backup per session, and the backup and the originals are not saved on the same node, such as when a client initiates a request and is distributed through load balancing toTOMCAT1instance node, generate a containing. TOMCAT1suffix of the session ID, andTOMCAT1node selects the node that this session object backs up according to a certain policy, and then contains the{SessionID, BackupIP}Information sent toTOMCAT2,TOMCAT3,TOMCAT4, as shown in the dashed line, so that each node has a sessionID, BackupIPlist, where each node has a backup of each sessionIPaddress.

After completing the previous step, the session content is backed up to the backup node, ifTOMCAT1of theS1,S2the backup address for two sessions isTOMCAT2, the session object is backed up toTOMCAT2, similar to the one inTOMCAT2putS3session Backup toTOMCAT4,TOMCAT4putS4,S5two conversations back toTOMCAT3, so that all sessions in the cluster already have a backup. WhenTOMCAT1has not failed due toSession StickThe technology client will always have access toTOMCAT1node, ensuring that the session is always available. And whenTOMCAT1when it fails,Tomcatalso provides aFailovermechanism toApacheperceiving back-end clustersTOMCAT1When the node is removed, it randomly assigns the request to any other node, and then there are two scenarios:

① just to the backup node tomcat2 , and still get to S1 Session, in addition,tomcat2 also want to do is to S1 session is marked as original and continues to pick a backup address backup S1 session, so there's a backup.

② If a non-backup node is dividedTOMCAT3, and I'm sure I can't find it nowS1session, and then it will ask the cluster all nodes, "Ask who hasS1Backup of the sessionIPaddress information? ", because onlyTOMCAT2have aS1The backup address information that it receives after the inquiry is answered to informTOMCAT3nodeS1the backup of the sessionTOMCAT2, according to this information, you can findS1session, andTOMCAT3build locally on your ownS1session and mark it as an original,TOMCAT2the copy on the same, so you can findS1session, normal complete entire request processing.

Production Deployment Selection

The above two models have their own advantages and disadvantages, in the actual production deployment should be based on the actual situation to choose the appropriate model.

For a full-node session synchronization model

It is easy to see that the session between nodes of the cluster is 22 of each other, once the number of cluster nodes and access to large, will lead to a large number of session information need to replicate with each other, it is easy to cause network congestion, and these synchronization operations are likely to become the bottleneck of overall performance, based on experience, The number of cluster nodes recommended in the actual production of this scheme is 3-6 , it is unable to build a larger cluster, and redundant large amount of data, the utilization rate is low.

For the cluster incremental session manager, you can use it by configuring the server.xml file, and using cluster mode in Tomcat requires a <Engine> node under Add <cluster> node, and the cluster incremental session manager is precisely adding a child node under this node <manager classname= "Org.apache.catalina.ha.session.DeltaManager"/> .

For a session backup model

For the above-mentioned full-node session synchronization model of network traffic with the increase in the number of nodes in the square trend growth, it is because of this factor can not build a larger cluster, in order to make the cluster node can be increased, the primary solution is the data replication traffic growth problem,Tomcat A session backup model is proposed to optimize the previous model, which causes the network traffic of session backup to increase linearly with the number of nodes, each session will have only one backup, greatly reduce network traffic and logical operation, this model can build a larger cluster. Production can be composed of more than 10 nodes as a cluster.

For a clustered Backup session Manager, you can use it by configuring the server.xml file, which is basically similar to the configuration of Deltamanager, in <cluster Add a child node under the > Node <manager classname= "Org.apache.catalina.ha.session.BackupManager"/> .

Using this model also takes into account that although this mode supports a larger cluster, it has only one data backup, if the source data and the backup data are in the same time the machine is down, there is no way to recover data, but just at the same time the probability of downtime is very small.

Like the Java classmate to make a friend:

Analysis of tomcat cluster mechanism and its production and deployment selection