还有一个问题就是小文件的效率问题，一般我们的 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 的同步

我们前端可能有很多台服务器，用户在 A 服务器上登录了，种下了 session 信息，然后访
问网站的某些页面没准跳到 B 服务器上去了，如果这个时候 B 服务器上没有 session 信息
又没有做特殊处理，可能就会出问题了。
session 同步有很多种，如果你是存储在 memcached 或者 MySQL 中，那就很容易了，指
定到同样的位置即可，如果是文件形式的，你可以用 NFS 统一存储。

还有一种方式是通过加密的 cookie 来实现，用户在 A 服务器上登录成功，在用户的浏览
器上种上一个加密的 cookie，当用户访问 B

 

服务器时，检查有无 session，如果有当然没

问题，如果没有，就去检验 cookie 是否有效，cookie 有效的话就在 B 服务器上重建
session

 

。这种方法其实很有 用，如果网站有很多个子频道，服务器也不在一个机房，

session 没办法同步又想做统一登录那就太有用了。

 

当然还有一种方法就 是在负载均衡那一层保持会话，把访问者绑定在某个服务器上，他
的所有访问都在那个服务器上就不需要 session 同步了，这些都是运维层面的东西。就说

 

这 么多吧，根据自己的应用来选择使用 session，不要因为大家都说 session 影响系统性能
就畏首畏尾，知道问题，解决问题才是关键，惹不起躲得起不适合这里。