Cluster mode II (larger cluster) from single-machine to cluster-session management

The network traffic of full node replication from single machine to cluster session management mode one is increasing with the increase of the number of nodes, and it is precisely because of this factor that it is impossible to build larger clusters, in order to make the cluster nodes more larger, The first solution is the data replication traffic growth problem, the following will describe another way of session management, each session will only have a backup, it makes the session backup network traffic with the increase in the number of nodes linearly trend growth, greatly reducing network traffic and logical operation, can build a larger cluster.

Here's a look at how this works, clusters generally provide overall service through load balancing, and 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 the S1 session is marked as original and continues to pick a backup address to back up the S1 session, so that there is 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.

Management from single machine to cluster session the article analyzes the different models of the Web Server's session management from single machine to cluster, including non-persistent single machine, single-machine file persistence, stand-alone database (cache) persistence, cluster database (cache), cluster full node replication, Copy backup of the cluster originals, and so on. This paper analyzes the working principle and advantages of different models, and deeply understands the various conversational management modes which are helpful to the selection of the conversation scheme of the actual project.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Cluster mode II (larger cluster) from single-machine to cluster-session management