Home > Article > Backend Development > Analyze the implementation principles of session in PHP and issues that should be paid attention to when applying large websites_PHP Tutorial
Analyze the implementation principles of session in PHP and issues that should be paid attention to when applying large websites_PHP Tutorial
- WBOYOriginal
- 2016-07-21 15:05:42814browse
PHP SESSION原理
我们知道，session是在服务器端保持用户会话数据的一种方法，对应的cookie是 在客户端保持用户数据。HTTP协议是一种无状态协议，服务器响应完之后就失去了与浏览器的联系，最早，Netscape将cookie引入浏览器，使得 数据可以客户端跨页面交换，那么服务器是如何记住众多用户的会话数据呢？
首先要将客户端和服务器端建立一一联系，每个客户 端都得有一个唯一标识，这样服务器才能识别出来。建议唯一标识的方法有两种：cookie或者通过GET方式指定。默认配置的PHP使用session的 时会建立一个名叫”PHPSESSID”的cookie（可以通过php.ini修改session.name值指定），如果客户端禁用cookie,你 也可以指定通过GET方式把session id传到服务器（修改php.ini中session.use_trans_sid等参数）。
我们查看服务器端session.save_path目录会发现很多类似sess_vv9lpgf0nmkurgvkba1vbvj915这样的文件，这个 其实就是session id “vv9lpgf0nmkurgvkba1vbvj915″对应的数据。真相就在这里，客户端将session id传递到服务器，服务器根据session id找到对应的文件，读取的时候对文件内容进行反序列化就得到session的值，保存的时候先序列化再写入。
事实就是这 样，所以如果服务器不支持session或者你想自定义session，完全可以DIY，通过PHP的uniqid生成永不重复的session id，然后找个地方存储session的内容即可，你也可以学flickr把session存储在MySQL数据库中。
使用session之前为什么必须先执行session_start()？
了 解的原理之后，所谓的session其实就是客户端一个session id服务器端一个session file，新建session之前执行session_start()是告诉服务器要种一个cookie以及准备好session文件，要不然你的 session内容怎么存；读取session之前执行session_start()是告诉服务器，赶紧根据session id把session文件反序列化。
只有一个session函数可以在session_start()之前执行，session_name()：读取或指定session名称（比如默认的就是”PHPSESSID”），这个当然要在session_start之前执行。
session影响系统性能
session 在大访问量网站上确实影响系统性能，影响性能的原因之一由文件系统设计造成，在同一个目录下超过10000个文件时，文件的定位将非常耗时，PHP支持 session目录hash，我们可以通过修改php.ini中session.save_path = “2;/path/to/session/dir”，那么session将存储在两级子目录中，每个目录有16个子目录[0~f]，不过好像PHP session不支持创建目录，你需要事先把那么些目录创建好 。
还有一个问题就是小文件的效率问题，一般我们的 session数据都不会太大（1～2K），如果有大量这样1～2K的文件在磁盘上，IO效率肯定会很差，PHP手册上建议使用Reiserfs文件系 统，不过Reiserfs的前景堪忧，Reiserfs的作者把媳妇给杀了，SuSE也抛弃了Reiserfs。
其实还有很多中 存储session的方式，可以通过php -i|grep “Registered save handlers”查看，比如Registered save handlers => files user sqlite eaccelerator可以通过文件、用户、sqlite、eaccelerator来存，如果服务器装了memcached，还有会mmcache的 选项。当然还有很多，比如MySQL、PostgreSQL等等。都是不错的选择。
Session synchronization
Our front-end may have many servers. The user logs in on server A, plants the session information, and then accesses certain pages of the website. Maybe it jumped to server B. If there is no session information on server B and no special processing is done at this time, there may be a problem.
There are many types of session synchronization. If you store it in memcached or MySQL, it is very easy. Just specify it to the same location. If it is in file form, you can use NFS to store it uniformly.
Another way is to use encrypted cookies. When the user successfully logs in on server A, an encrypted cookie is planted on the user's browser. When the user visits server B, check whether there is a session. , if there is, of course there is no problem. If not, check whether the cookie is valid. If the cookie is valid, re-establish the session on server B. This method is actually very useful. It is very useful if the website has many sub-channels and the servers are not in the same computer room. The sessions cannot be synchronized and you want to log in uniformly.
Of course, another method is to maintain the session at the load balancing layer and bind the visitor to a certain server. All his visits will be on that server and there will be no need for session synchronization. These are all It's something at the operation and maintenance level. That's all. Choose to use sessions based on your own applications. Don't be timid just because everyone says sessions affect system performance. Knowing the problems and solving them is the key. If you can't afford to offend or hide, you are not suitable here.