Resolve the session implementation principles in php and the problems that should be paid attention to when using large websites.

This article provides a detailed analysis of the session implementation principles in php and the issues that should be paid attention to in large website applications. For more information, see Php session principle
We know that session is a way to maintain user session data on the server side, and the corresponding cookie is to maintain user data on the client side. HTTP is a stateless protocol. after The server responds, it loses contact with the browser. as early as possible, Netscape introduced cookies to the browser so that data can be exchanged across pages on the client, how does the server remember the session data of many users?

First, you need to establish a one-to-one connection between the client and the server. each client must have a unique identifier so that the server can recognize it. We recommend that you use two unique identifiers: cookie or GET. By default, PHP uses session to create a cookie named "PHPSESSID" (you can use php. ini modifies the session. if the cookie is disabled on the client, you can also specify the GET method to transfer the session id to the server (modify php. session in ini. use_trans_sid and other parameters ).

We can check the session. save_path directory on the server side and find many files like sess_vv9lpgf0nmkurgvkba1vbvj915. this is actually the data corresponding to the session id "vv9lpgf0nmkurgvkba1vbvj915. The truth is here, the client passes the session id to the server, the server finds the corresponding file based on the session id, and obtains the session value after deserializing the file content during reading, serialized before writing during storage.

This is the case. if the server does not support the session or you want to customize the session, you can create a session id that never repeats through the uniqid of PHP, you can find a place to store the session content. you can also learn to store the session in the MySQL database.

Why do I have to execute session_start () before using session ()?
After the solution is implemented, the so-called session is actually a session id on the client side and a session file on the server side. executing session_start () before creating a session tells the server to implant a cookie and prepare the session file, otherwise, how to store your session content? before reading the session, executing session_start () tells the server to deserialize the session file according to the session id.

Only one session function can be executed before session_start (). session_name (): reads or specifies the session name (for example, the default value is "PHPSESSID"). This must be executed before session_start.

Session affects system performance
Session does affect system performance on websites with high traffic. one of the reasons that affect performance is caused by the file system design. when there are more than 10000 files under the same directory, file locating takes a lot of time, PHP supports session directory hash. we can modify php. session in ini. save_path = "2;/path/to/session/dir", the session will be stored in two subdirectories, each of which has 16 subdirectories [0 ~ F], but it seems that PHP session does not support creating directories. you need to create these directories in advance.

Another problem is the efficiency of small files. Generally, our session data is not too large (1 ~ 2 K), if there are a large number of such 1 ~ 2 K files are stored on disks, and I/O efficiency will be poor. we recommend that you use the Reiserfs file system in the PHP Manual. However, the prospect of Reiserfs is worrying. The author of Reiserfs killed his daughter-in-law, suSE also abandoned Reiserfs.

In fact, there are many ways to store sessions, which can be viewed through php-I | grep "Registered save handlers, for example, Registered save handlers => files user sqlite eaccelerator can be stored through files, users, sqlite, and eaccelerator. if memcached is installed on the server, mmcache is available. Of course there are many more such as MySQL and PostgreSQL. They are all good choices.

Session synchronization
We may have many front-end servers. users have logged on to server A and planted session information. then, some pages on the website may jump to server B, if there is no session information on server B and no special processing is performed at this time, a problem may occur.
There are many kinds of session synchronization. if you store them in memcached or MySQL, it is easy to specify the same location. if it is in the file format, you can use NFS for unified storage.

Another way is to use encrypted cookies. after A user successfully logs on to server A, an encrypted cookie is added to the browser. when A user accesses server B, check whether there is a session. If yes, check whether the cookie is valid. If yes, re-create the session on server B. This method is actually very useful. if the website has many sub-channels and the server is not in the same data center, it would be useful if the session cannot be synchronized and you want to perform unified login.

Of course, there is another way to maintain the session at the layer of server load balancer, bind the visitor to a server, and all the accesses to the server do not require session synchronization, these are all at the O & M level. Let's just talk about this. choose to use sessions based on your own applications. Don't be afraid of the impact of sessions on system performance. knowing the problem and solving the problem is the key, it is not suitable for hiding.