PHP multiple servers cross-domain SESSION sharing

With the gradual development of website business scale and visits, the original mini website structure of a single server and a single domain name can no longer meet the development needs.

At this time, we may purchase more servers and enable multiple second-level subdomains in a channelized manner to distribute and deploy the website on independent servers according to business functions; or use load balancing technology (such as: DNS polling, Radware, F5, LVS, etc.) allows multiple channels to share a single set of servers.

　OK, we have already conceived such a solution in our minds, but after entering in-depth development, new technical problems arise:

　We distribute and deploy the website program to multiple servers, and independently divide it into several second-level domain names. Since Session is limited by the implementation principle (Session in PHP is saved in the form of a file on the hard drive of the local server by default), our website Users often have to enter usernames and passwords back and forth between several channels to log in, which greatly reduces the user experience. In addition, the original program can directly read the data (such as nickname, points, login time, etc.) from the user's Session variables. Because Session variables cannot be updated synchronously across servers, developers must read and write to the database in real time, thus increasing the burden on the database.

As a result, the need to solve the problem of session sharing between cross-server websites became urgent, and eventually a variety of solutions were born. Here are 4 more feasible solutions for comparison and discussion:

　1. Session sharing based on NFS

　NFS is the abbreviation of Net FileSystem, which was first developed by Sun to solve the problem of directory sharing between Unix network hosts.

　This solution is the simplest to implement. It does not require too much secondary development. You only need to mount the shared directory server to the local session directory of each channel server. The disadvantage is that NFS relies on complex security mechanisms and file systems, so concurrency efficiency Not high, especially for small files such as sessions with high concurrent reading and writing, the io-wait of the shared directory server will be too high, which will eventually drag down the execution efficiency of the front-end WEB application.

　2. Database-based Session sharing

　The first choice is of course the famous Mysql database, and it is recommended to use the memory table Heap to improve the reading and writing efficiency of session operations. This solution is quite practical and I believe it is commonly used by everyone. Its disadvantage is that the concurrent reading and writing capabilities of the session depend on the performance of the Mysql database. At the same time, you need to implement the session elimination logic yourself in order to regularly update and delete session records from the data table. , table locks are prone to occur when concurrency is too high. Although we can choose a table engine with row-level locks, we have to deny that using a database to store Session is still a bit overkill.

　3. Cookie-based Session Sharing

　We may be unfamiliar with this solution, but it is still commonly used in large websites. The principle is to encrypt and serialize the session information of all users of the site and then use it as a cookie to uniformly plant it under the root domain name (such as: .host.com). When using the browser to access all second-level domain name sites under the root domain name, It will pass the characteristics of all cookie contents corresponding to the domain name, thereby realizing the shared access of the user's cookie-based Session among multiple services.

　The advantage of this solution is that it does not require additional server resources; the disadvantage is that due to the limitation of the http protocol header confidence length, it can only store a small part of user information. At the same time, the cookied Session content needs to be securely encrypted and decrypted (such as using DES, RSA etc. for plaintext encryption and decryption; and then use MD5, SHA-1 and other algorithms for anti-counterfeiting authentication). In addition, it will also occupy a certain bandwidth resource because the browser will attach the local cookie to the http header when requesting any resource under the current domain name. passed to the server.

　4. Session sharing based on Memcache

　Since Memcache is a memory sharing system based on Libevent multi-channel asynchronous I/O technology, the simple Key + Value data storage mode makes the code logic compact and efficient, so it has an absolute advantage in concurrent processing capabilities. What I have experienced so far The project reaches an average query rate of 2000/second, and the server CPU consumption is still less than 10%.

It is also worth mentioning that the Expires data expiration and elimination mechanism unique to Memcache's memory hash table coincides with the Session expiration mechanism, reducing the code complexity of expired Session data deletion, compared with "database-based storage solutions" ", this logic alone creates huge query pressure on the data table.

　Storage based on Memcache is recommended among these solutions!

　Other solutions still have their uses. The specific choice of which solution requires a comprehensive evaluation by the developer based on current server resources, website concurrency pressure, etc.