Author: Chszs, reprint should be indicated. Blog home: Http://blog.csdn.net/chszs
Some time ago, I spent a lot of time looking for a way to push the newly developed code to the production system to be able to 0 downtime, and 0 impact on the use of users.
My idea is to use the cluster to fix it by notifying the load balancing Nginx, removing the Tomcat nodes from the cluster, and then upgrading the application on Tomcat, then notifying the load balancing nginx and reloading the Tomcat node. Do this in turn, replacing all Tomcat in the cluster once.
So the question is, how does it affect the user when removing the Tomcat node and loading the new Tomcat node? The method is simple, sharing session.
Below, we use an example to illustrate this scenario. Our example uses a nginx for load balancing, two tomcat on the back end, and each Tomcat session is saved to the Redis database. Where Nginx is configured as a non-sticky run mode, that is, each request can be assigned to any node in the cluster. When new code is to be on line, simply remove the Tomcat instance, at which point all the access users are routed to the active Tomcat instance, and since the session data is stored in the Redis database, active users are not affected. When Tomcat is updated, you can add this node to the Nginx.
Install Nginx
# sudo rpm-ivh nginx-1.4.2-1.el6.ngx.x86_64.rpm
Modify the configuration file/etc/nginx/nginx.conf and add the following:
HTTP {
upstream tomcat {
server localhost:8080;
Server localhost:8081;
}
Include /etc/nginx/mime.types;
Default_type Application/octet-stream;
Modify the configuration file/etc/nginx/conf.d/default.conf and replace the contents of the Location section:
Location/{
proxy_pass http://tomcat;
}
Restart Nginx
# sudo service nginx restart
Next, install two Tomcat instances. Since we are demonstrating on the same server, to have two tomcat not collide, you need to modify the port number of the second Tomcat instance. Because Nginx is configured as Non-sticky run mode, the Round-robin load Balancing method is used for each request, which means that it draws a new session for each request.
Next, download and install Redis. Step omitted, very simple.
Finally, we need to configure Tomcat so that Tomcat saves session sessions to the Redis database.
We want to use a third party library such as Tomcat-redis-session-manager, home page see:
Https://github.com/jcoleman/tomcat-redis-session-manager
Note that this library is not out-of-the-box, and that you need to make some adjustments when you use it. You need to download the source code, and after updating the dependent library version, rebuild the project. For example, I use the Commons-pool2-2.2.jar and Jedis-2.6.1.jar dependent libraries. Remember to copy these jar files to the Lib subdirectory of each Tomcat instance.
After updating the Commons-pool, Jedis, and Tomcat versions of these libraries, you can use Build.gradle to build the entire project. After the build is completed, the newly generated tomcat-redis-session-manager-1.2.jar are copied to the Lib subdirectory of each Tomcat instance. and modifying the context.xml configuration file for each Tomcat instance:
<valve classname= "Com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve"/>
<manager Classname= "Com.orangefunction.tomcat.redissessions.RedisSessionManager"
host= "localhost"
port= "6379"
database= "0"
maxinactiveinterval= "/>"
Restart the Tomcat instance. You can check to see that Redis did save the session of Tomcat. Then when we remove or restore the Tomcat instance, the access user does not actually suffer.