PHPにおけるセッションの実装原則と大規模Webサイト適用時の注意点を分析_PHPチュートリアル
- WBOYオリジナル
- 2016-07-21 15:05:42762ブラウズ
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等等。都是不错的选择。
セッション同期
私たちのフロントエンドには多数のサーバーがある可能性があります。ユーザーはサーバー A にログインし、セッション情報を植え、Web サイトのいくつかのページにアクセスして、サーバー B にジャンプする可能性があります。サーバー上にセッション情報がなく、特別な処理を行わない場合、問題が発生する可能性があります。
セッション同期には色々な種類がありますが、memcachedやMySQLに保存する場合は同じ場所に指定するだけで統一して保存できます。
もう 1 つの方法は、暗号化された Cookie を使用することです。ユーザーがサーバー A に正常にログインすると、ユーザーがサーバー B にアクセスしたときに、セッションが存在するかどうかを確認します。問題がない場合は、Cookie が有効かどうかを確認し、有効な場合はサーバー B でセッションを再確立します。この方法は、Web サイトに多数のサブチャネルがあり、サーバーが同じコンピュータ ルームにない場合に、均一にログインしたい場合に非常に便利です。
もちろん、別の方法は、負荷分散層でセッションを維持し、訪問者を特定のサーバーにバインドすることです。訪問者はすべてそのサーバー上で行われ、セッションの同期は必要ありません。これらはすべて運用と保守の段階で行われます。レベルのもの。セッションがシステムのパフォーマンスに影響を与えると誰もが言うからといって、臆病になる必要はありません。問題を攻撃したり隠したりする余裕がない場合は、それが重要です。ここにはふさわしくありません。