PHP multi-server cross-origin SESSION sharing, php multi-domain session
With the gradual development of website business scale and access volume, the mini-website architecture originally composed of a single server and a single domain name cannot meet the development needs.
In this case, we may purchase more servers and enable multiple second-level subdomains to deploy websites on independent servers in a frequent manner based on business functions; or use Server Load balancer technology (such as DNS polling, Radware, F5, and LVS) to share a group of servers with multiple channels.
Okay, we have already conceived such a solution in our mind, but after in-depth development, new technical problems will follow:
We deploy our website programs on multiple servers, which are independent of several second-level domain names, due to the limitations of the implementation principle, the Session in PHP is saved to the hard disk of the local server by file format by default ), as a result, our website users have to enter the user name and password to log on back and forth between several channels, resulting in a great reduction in user experience. In addition, the original program can directly read data from user Session variables (such as nickname, points, and logon time), because it cannot synchronously update Session variables across servers, forcing developers to read and write databases in real time, this increases the burden on the database.
As a result, the demand for cross-Server Session sharing becomes urgent, and a variety of solutions are finally introduced. The following lists four feasible solutions for comparison and discussion:
1. NFS-based Session sharing
NFS is short for Net FileSystem. It was first developed by Sun to solve directory sharing between Unix network hosts.
This solution is the easiest to implement. 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 the concurrency efficiency is not high, especially for small files with high concurrent reads and writes such as sessions, because the I/O-wait of the shared directory server is too high, the execution efficiency of the front-end WEB application is dragged down.
2. Database-based Session sharing
The first choice is of course the well-known Mysql database, and the memory table Heap is recommended to improve the Read and Write efficiency of session operations. This solution is more practical. I believe it is widely used. Its disadvantage is that the concurrent read/write capability of the session depends on the performance of the Mysql database. At the same time, you need to implement the session elimination logic by yourself, in this way, session records can be updated and deleted from data tables at regular intervals. When concurrency is too high, table locks are prone to occur. Although we can select the row-Level Lock table engine, however, I have to deny that using the database to store sessions is still a battle.
3. Cookie-based Session sharing
This solution may be unfamiliar to us, but it is still widely used in large websites. The principle is to encrypt and serialize the Session information of a full-site user in the form of cookies and uniformly plant them under the root domain name (for example, .host.com ), when a browser accesses all second-level domain site under the root domain name, it will pass the characteristics of all cookies corresponding to the domain name, in this way, users' Cookie-based sessions can be shared among multiple services.
The advantage of this solution does not require additional server resources; the disadvantage is that it can only store a small part of user information due to the limited length of http header confidence, at the same time, the Cookie-based Session content needs to be encrypted and decrypted securely (for example, DES and RSA are used for plaintext encryption and decryption, and MD5 and SHA-1 algorithms are used for anti-counterfeiting authentication ), in addition, it also occupies a certain amount of bandwidth resources, because the browser will attach the local Cookie to the server when requesting any resources under the current domain name in the http header.
4. Memcache-based Session sharing
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 small and efficient, therefore, it has an absolute advantage in concurrency processing capability. Currently, my project has reached an average query rate of 2000/second, and the server CPU consumption is still less than 10%.
In addition, it is worth mentioning that the Expires data expiration and elimination mechanism Expires exclusive to the memory hash table of Memcache coincide with the Session expiration mechanism, reducing the complexity of code deletion for expired Session data, compared with the database-based storage solution, this logic alone puts a great deal of query pressure on data tables.
Memcache-based storage is recommended for these solutions!
Other solutions still have their own use cases. Which of the following sets requires developers to make a comprehensive evaluation based on the current server resources and website concurrency pressure.