Nginx Load Balancing Session replication Solution

Nginx load balance, must use the distributed cluster scheme, as long as the distribution, session sharing is a big problem, not just nginx. We use Nginx to do load balancing, the same request is not necessarily assigned to which server, then our next request may be divided into other servers, this situation, will cause session loss problem, to a big problem. This situation is more common in the landing issue, for example: our first request (by a server response) can enter the login interface, at this time a generated verification code exists in a session, then we lose the login information and verification code after the submission, the request is divided into B server to deal with, So b certainly get less than a session of information, get the corresponding verification code, of course, the error is the verification code is not correct. So how to solve the distributed session replication (sharing) problem. Some information from the Internet, sorted as follows: 1. Do not use session, swap cookies

Session is stored on the server side, cookies are stored in the client, we can access the page generated by the user session into the cookie, is a cookie as a transit point. You access Web Server A, generate a session and then put it in the cookie, when your request is assigned to B server, Server B first to determine whether the server has this session, if not, to see the client's cookie inside there is no this session, If there is no, the session really does not exist, if the cookie inside, the cookie inside the Sessoin synchronization to Server B, so you can achieve synchronization of the session.

Description: This approach to achieve simple, convenient, and will not increase the burden of the database, but if the client to ban the cookie, then the session will not be synchronized, which will bring loss to the site; cookies are not secure enough, but they can be forged even though they have been added to the secret. 2.session exists in memcache or Redis

Memcache can do distributed, PHP configuration file Set storage mode for memcache, so that PHP itself will establish a session cluster, to store the session data in the Memcache.

Description: In this way to sync session, will not increase the burden of the database, and security than with cookies greatly improved, put the session into memory, than from the file to read a lot faster. But memcache the memory into many kinds of storage blocks, there is a block size, this way is decided, memcache can not fully utilize memory, will produce memory fragmentation, if the storage block is insufficient, also can produce memory overflow.

Redis is commonly used for project caching, we can cache session to Redis to achieve the purpose of session replication. Currently, this scheme is implemented by Nginx + Redis + tomcat, as follows:
(1) Add the required jar packs to Tomcat's lib directory (Tomcat-redis-session-manager the corresponding jar packs, mainly three).
(2) Configure the Conf/context.xml under the Tomcat directory and add the following:

<valve classname= "Com.radiadesign.catalina.session.RedisSessionHandlerValve"/>

        <manager classname= " Com.radiadesign.catalina.session.RedisSessionManager "

                host=" 192.168.0.222 "   #redis地址

                port=" 6379 "                #redis端口

                database= "0"

                maxinactiveinterval= "/>" #session失效时间

3. The session exists in the database

Using the database to synchronize session, will increase the database IO, increase the burden of the database. And the database read-write speed is slow, not conducive to the timely synchronization of the session, not recommended. 4.nginx Ip_hash Strategy

Nginx Load Balancing Strategy:
Nginx's upstream currently supports 4 different ways of allocating
1), polling (default)
Each request is assigned to a different back-end server in chronological order, and can be automatically removed if the backend server is down.
2), Weight
Specifies the polling probability, proportional to the weight and the access ratio, for the performance of the backend server.
3), Ip_hash
Each request is allocated according to the hash result of the access IP, so that each visitor has a fixed access to a back-end server that resolves the session's problem.
4), Fair (third party)
The response time of the backend server is allocated to the request, and the response time is short for priority assignment.
5), Url_hash (third party)

The Ip_hash technology in Nginx can direct an IP request to the same backend, so that a client under this IP and a backend can establish a solid session,ip_hash is defined in the upstream configuration:

    Upstream nginx.example.com  
        {   
             ip_hash;  
                 Server 192.168.1.111:80;   
                 Server 192.168.1.114:80;  
        }  
        Server  
        {  
                 listen;  
                 Location/  
                 {  
                         proxy_pass  
                        http://nginx.example.com;  
                 }  
     }  

Ip_hash is easy to understand, but because only the IP factor can be used to allocate the backend, the Ip_hash is flawed and cannot be used in some cases:

(1) Nginx is not the most front-end server.
Ip_hash requirements Nginx must be the most front-end server, otherwise nginx not get the correct IP, can not be based on IP hash. For example, the use of squid as the most front-end, then Nginx IP can only get Squid server IP address, using this address to shunt is definitely confused.

(2) There are other ways of load balancing at the back end of the nginx.
If there is another load balance on the back end of the Nginx and the request is diverted in another way, then a client's request must not be positioned on the same session application server. In this way, the Nginx backend can only point directly to the application server, or a squid, and then point to the application server. The best way to do this is to use location for a diversion, which will require part of the session to be diverted through Ip_hash, leaving the rest to the back end. 5.upstream_hash

To solve some of the ip_hash problems, you can use Upstream_hash, a third-party module, which is used in most cases as url_hash, but does not prevent it from being used for session sharing:
If the front end is squid, he will add IP to x_forwarded_for this http_header, with Upstream_hash can use the head to do the factor, the request to the specified back end:
Visible This document: http://www.sudone.com/nginx/nginx_url_hash.html
In the document, you use the $ Request_uri to do the factor and slightly change:
Hash $http _x_forwarded_for ";
This is changed to the use of x_forwarded_for this head as a factor, in the new version of Nginx can support reading cookie value, so can also be changed to:
Hash $cookie _jsessionid;
If the session configured in PHP is no cookie, with Nginx own Userid_module module can be used Nginx spontaneous a cookie, see the UserID module in English documents:
Http://wiki.nginx.org/NginxHttpUserIdModule
Another module that can be written with Yiu Weibin upstream_jvm_route:http://code.google.com/p/nginx-upstream-jvm-route/

Turn from: http://blog.csdn.net/xluren/article/details/16951247