A session sharing problem to solve the nginx load balancing

Check some of the information, read some other people wrote the document, summarized as follows, to realize the sharing of Nginx session

PHP server has more than one, with nginx load balancer, so that the same IP access to the same page will be assigned to different servers, if the session is not synchronized, there will be many problems, such as the most common login status, the following provides several ways to solve the problem of session sharing:

1. Do not use session, swap with cookies

The session is stored on the server side, the cookie is stored on the client, we can put the user access page generated by the session into the cookie, is to use a cookie as a transit point. You visit Web Server A, generate a session and then put it into the cookie, when your request is assigned to the B server, Server B first determine whether the server has this session, if not, then to see if there is a client cookie in this session, If not, the session really does not exist, if there is a cookie, the cookie inside the Sessoin synchronization to Server B, so that the session synchronization can be achieved.

Note: This method is simple, convenient, and will not increase the burden of the database, but if the client has forbidden the cookie, then the session will not be synchronized, this will bring a loss to the site, the security of the cookie is not high, although it has been added, but still can be forged.

2, the session exists in the database (MySQL, etc.)

PHP can be configured to save the session in the database, this method is to put the table and other database tables to hold the session together, if MySQL also made a cluster, each MySQL node must have this table, and this session table data table to synchronize in real time.

Note: Using the database to synchronize the session, the database will be increased IO, increase the burden of the database. and the database reading and writing speed is slow, not conducive to timely synchronization session.

3. Session exists in Memcache or Redis

Memcache can be distributed, the PHP configuration file is stored in memcache, so PHP itself will create a session cluster, the session data stored in the memcache.

Note: In this way to synchronize the 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 read much faster. But memcache the memory into many kinds of storage blocks, there is a block size, this way also determines that the memcache can not fully utilize the memory, will produce memory fragmentation, if the storage block is insufficient, but also generate memory overflow.

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

[HTML]View PlainCopy 

2. Upstream nginx.example.com
4. {
6. Server 192.168.74.235:80;
8. Server 192.168.74.236:80;
10. Ip_hash;
12. }
14. Server
16. {
18. Listen 80;
20. Location/
22. {
24. Proxy_pass
26. http://nginx.example.com;
28. }
30. }

Ip_hash is easy to understand, but because the backend can only be assigned with the IP factor, 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, or nginx can not get the correct IP, it can not be based on IP as a hash. For example, the use of squid as the most front-end, then the Nginx IP can only get Squid server IP address, with this address to shunt is definitely confused.
The back end of the 2.nginx also has other ways of load balancing.

If the Nginx backend has other load balancing, and the request is diverted in another way, then a client's request must not be located on the same session application server. In this way, the Nginx backend can only point directly to the application server, or another squid, then point to the application server. The best way is to use location for a diversion, will need to part of the session request through the Ip_hash shunt, the rest of the other back end.

5, Upstream_hash
To solve some of the ip_hash problems, you can use Upstream_hash, the third-party module, which is used in most cases as url_hash, but does not prevent it from being used for session sharing. I never really knew what I was trying to do.

Add: memcached Simple Introduction

First, the concept

Memcached is a set of distributed memory object caching systems developed by danga.com (the technical team of operations LiveJournal) to reduce database load and improve performance in dynamic systems.

Second, the application of the occasion

1. Distributed applications. Because the memcached itself is based on a distributed system, it is particularly suitable for large distributed systems.

2. Database front-section cache. Database is often the bottleneck of the website system. Large concurrent access to the database often results in Web site memory overflow. Of course we can also use Hibernate's caching mechanism. But Memcached is based on distributed, and can be independent of the website application itself, so it is more suitable for large-scale web site for the application of the split.

3. Data sharing between servers. For example, we will be the site's login system, query system split into two applications, placed on different servers, and cluster, that time when the user logged on, how to log on the login information from the system server synchronization to the query system server? At this time, we can use memcached, login system to cache the login information, the query system can get login information, like to obtain local information.

Third, not applicable occasions

Those that do not need to be "distributed", do not need to be shared, or simply scale to a single server, memcached does not bring any benefit, and instead slows down system efficiency because network connectivity also requires resources

Solution, using memcached as session storage, the Memcached server is set on the same Linux host as Nginx.

Resolution process,

The two Apache host IPs are 192.168.74.235192.168.74.236, respectively.

Nginx Host IP is 192.168.74.131

The IP of the memcached host is 192.168.74.131

Install memcached in 192.168.74.131, and start

Take one as an example 192.168.74.236, install PHP and PHP memcached dependent library Yuminstall memcached-devel.i686 libmemcached-devel.i686 php-pecl-memcache.i686

Configure PHP.ini

Session.save_handler= Memcache

Session.save_path= "tcp://192.168.74.131:11211"

or (the following two did not try)

1.. htaccess in a directory:

Php_value Session.save_handler "Memcache"
Php_value Session.save_path "tcp://ip:11211"

2. In one application:

Ini_set ("Session.save_handler", "memcache");
Ini_set ("Session.save_path", "tcp://ip:11211");

Also be sure to comment out the following; Session.save_path= "/var/lib/php/session"

and open the extension=memcache.so.

Reboot Apache, check the phpinfo "registered save handlers" will have "files Usermemcache" These 3 available, if there is proof installed

memcached Server execution and results

[Email protected] ~]# memcached-tool127.0.0.1:11211

# item_size Max_age Pages Count full? Evicted Evict_time OOM

Add the following PHP file on the 236 machine

<?php

Session_Start ();

if (!isset ($_session[' TEST ')) {

$_session[' TEST ' = time ();

}

$_session[' TEST3 '] = time ();

Print $_session[' TEST '];

print "<br><br>";

Print $_session[' TEST3 '];

print "<br><br>";

Print session_id ();

?>

Then go to the memcached server to execute

[Email protected] ~]# memcached-tool127.0.0.1:11211

# item_size Max_age Pages Count full? Evicted Evict_time OOM

1 80B 0s 1 0 no 0 0 0

This should even be able to write the session to the Memcached server.

Summary below:

1. Firewall problems, many connections to LAN server failures are caused by a firewall

2. Dependencies are not installed, the first use of memcached total failure, because I did not install php-memcached such an extension library

A session sharing problem to solve the nginx load balancing