老旧话题：重新看看当年感觉很难的session

原文地址：https://t.ti-node.com/thread/&＃8230;

这基本上算是个老旧的话题了，几乎所有phper在第一次面试的时候都会被问到关于session的问题，如果不出意外，往往是如下三板斧：

1. php的session是什么东西
2. php的session存在什么地方、时候过期
3. php的session和COOKIE有什么区别

这三个问题堪称是关于php session三大基础问题了，要是掌握不好，直接导致面试挂掉，令人唏嘘不已。

就以上三个问题简单回顾一下：

1. session翻译成中文，大抵就是会话。我们知道http协议是一个无状态的协议，用极为粗暴的土话表示无状态就是说“你压根不知道这个http请求是哪个犊子发起的”或者“你永远不知道这个http请求的那头到底是上次那个哈士奇还是上上次那个胖子”，所以为了解决这个问题，php引入session来额外标记“到底谁发起的这个http请求”。在php中，php会为每个不同的用户生成一个随机的session id，每个人拥有的session id都是不同的。用户在与服务器产生的每一次交互中，都是利用session id来辨别的用户。让php产生session是一件很容易的事情，直接调用session_start()函数就可以了，如下图就是产生的session文件：

其中sess是文件前缀，后面的“njjf8l3lh**ff6”就是你的session id了。但是现在session文件内容是空的，如果我们用如下代码，就可以产生session文件的内容：

// 开启session
session_start();
$_SESSION['hello'] = 'world';

刷新一下网页，然后在再次查看原来的session文件，其中就会有如下内容：

就是说，你往全局变量$_SESSION保存的内容本质上都是PHP用文本形式给你存储到服务器上了。服务器根据你的session id读取相应的session文件然后把其中内容读出来，你就会得到你的$_SESSION数据。

1. php的session默认是以文件的形式存储的系统磁盘中，在运行于ubuntu 16.04系统的php 7.0.28中，session是存储于/var/lib/php/sessions文件夹下，可以通过php.ini配置文件中的session.save_path来查看确定。php的过期时间是由php配置项session.gc_maxlifetime来确定的，值的单位是秒钟，默认是1440，也就是说当这个session文件具体上次修改时间超过了1440秒后这个session文件就算是过期了。值得注意的是，过期了不代表这个session文件会马上被垃圾回收机制删除掉，还是有可能会残存一段时间的。那么，究竟何时会被删除？这取决于session.gc_probability和session.gc_divisor两个配置项了。这两个选项的比值 ( session.gc_probability / session.gc_divisor ) 就是触发垃圾回收机制的概率，比如 ( 1 / 100 ) 就可以简单粗暴的理解为“每产生100个请求，就有1次会触发php垃圾回收机制去删除过期的session文件”，所以你记住了：在php中如果你想要一个精确过期的session文件，最起码默认的session配置是绝对不可能的。话说回来，还不都是因为php并没有启动一个单独的线程或者进程去扫描垃圾，所以，也只能用这个“概率”这种粗暴的方式来解决这个问题，又不是不能用。

2. 开篇说了，为了搞明白“到底是哈士奇还是胖子”的问题，不得不引入额外标记数据才行，所以实际上，先有的COOKIE而有后的session，都是为了解决这个问题而产生的。二者的恩怨情仇在于：

   • COOKIE存在于客户端，而session存在于服务器端，所以session相对更安全
   • 服务器可以读取session和COOKIE，但是客户端（也就是浏览器）只能读取COOKIE
   • 默认情况下，session是离不开COOKIE的，说到底“安全的session使用方式”必须依靠COOKIE才能混口饭吃。因为session id就是依靠COOKIE保存起来的，客户端浏览器每次发送请求都会携带上该COOKIE，该COOKIE默认名称是PHPSESSID，数值就是session id。
   • 如果说就是用不了COOKIE，那么session也并不是真的不能用。禁用COOKIE的情况下，session可以通过配置利用URL来传递，也就是query string直接暴露在网址中，非常不安全非常吓人，严重不推荐这种方式，甚至应该直接禁用！
   • COOKIE大小稍微有限制（据说考虑用localstorage代替？），session相对宽松

大概就这些，不再赘述，我是建议大家配合php.ini文件去研究上面三个问题。

如果说真的只回顾一下这三个问题，那岂不是真的应了“一看标题猛如虎，打开内容1-5”？我说过了的，我这里是个正经的博客网站，是个真正的有些内涵的php文化网站，不能只讲些个初级的内容，是个话题都都要无论如何强塞点儿看起来高端的玩意进去撑场面。

刚叨叨过了，默认配置下session是以文本文件形保存在服务器的某个文件夹中的，有心的人应该知道“一个目录中文件过多是会降低读取效率的”，所以，在用一些PC软件的时候可以看到这些软件会把TA需要的数据分散开来到不同的次级目录中去。php的session文件也可以这么干，总体来说是比较简单粗暴的。我们需要关注下两个php配置项：

• 一个是session.save_handler，默认这货的值是“files”，也就是文件
• 一个是session.save_path，默认这货的值是一个目录路径，比如/var/lib/php/session。现在我们将这个值改成类似于session.save_path = &＃8220;N;/path&＃8221;这样的，其中N是一个正整数，这个数值的含义就是指将目录分成几个层次，比如我们修改成session.save_path = “2;/var/lib/php/sessions”，然后重启一下apache或者fpm进程管理器，然后执行如下代码：

echo "let rock session";
session_start();

刷新网页，如下图所示：

错误原因相比大家看到了，大概意思就是说“/var/lib/php/sessions/n/j/”这个文件夹不存在，那么切换到这个目录下看看，如下图：

果然是空的，也就说没有/n/j这个子目录，看来得手工创建了。然而，真的不能去手工创建，因为你哪儿知道文件夹的名字是啥？回到配置文件一顿研究，在session.save_path配置项附近发现如下英文字样：

; NOTE 1: PHP will not create this directory structure automatically.
; You can use the script in the ext/session dir for that purpose.
; NOTE 2: See the section on garbage collection below if you choose to
; use subdirectories for session storage

英文比较蹩脚昂，大概翻译一下，多包涵：

; NOTE 1: PHP压根不会帮你创建这些文件夹，您自己个儿下载php源码包，到ext目录的session目中去找那个脚本去创建
; NOTE 2: 如果你要用子目录存储session的话，记得看下垃圾回收，不看就有坑。（坑在这里直接告诉大家吧，大概就是说你要自己搞子目录存session，那我那个靠信仰和概率才能触发的垃圾回收机制就压根就不触发了，你自己想办法搞定你的过期session，我不管了）

所以呢，我们下载一个php源码包，最好是和你运行环境版本一样的php源码包并解压，命令行切到ext/session目录下，如下图：

看到那个mod_files.sh没？Linux下就这脚本。mod_files.bat就是给windows用的。给这个脚本chmod +x mod_files.sh加个执行权限，然后查看下使用方式：

为了帮助眼近视的读者，友情翻译一下使用方式：

./mod_files.sh 'session文件根目录' 目录深度 哈希函数比特量
对应我的php开发环境就是：
./mod_files.sh /var/lib/php/sessions/ 2 5
其中第一项就是你存储session的根目录，第二项就是那个N，第三项查看session.hash_bits_per_character配置项

然后执行，如下图所示：

此时到/var/lib/php/sessions中查看下，果然有目录了，那么，再次刷新网页，本以为很顺利的你可能依然会遇到错误，如下：

session_start(): open(/var/lib/php/sessions/n/j/sess_njjf8l3lhfrpq8nrlnl1d9qff6, O_RDWR) failed: Permission denied (13)

模模糊糊认得Permission denied这几个字母，好像是权限的问题，难道是因为当前apache进程用户或者fpm进程用户没有权限往这些目录写数据吗？改下这些目录的拥有者撒，改成www-data（我系统中fpm的运行用户），再试试，果然好了！

总有刁民以为这就可以解决很大的问题了，然而很悲剧的是：并不是。当前这个方案一定程度可以解决session文件过多的问题，但是依然有两个问题没有得到解决：

1. 依然是文件存储，如果访问量太大的话，session文件从硬盘的读取IO或许会成为程序的瓶颈，当然SSD速度一定会好很多
2. 如果网站分别部署到了两台服务器上，session无法共享，出现故障。什么意思呢？就是为了保证高可用，网站程序分别在A服务器上和B服务器上，然后最外面使用一台nginx挡在最前面做负载均衡，路人甲的某次http请求可能会被分配到A上，也可能会被分配到B上。路人甲在A上产生的session文件会被保存到A服务器硬盘上，但是服务器B上却没有，如果该用户请求被打到B上的时候，很不幸，session丢失了，一些数据也就会丢失，路人甲八成会骂娘骂客服。也就说，A服务器和B服务器需要共享同一套session！

借此，就引入一个问题，就是分布式web部署中，如何解决session共享的问题！

关子我就不卖了，没意思，首先想到的是redis，为A和B提供一台C redis服务器就可以了，这样可以“ 多快好省 ”地一举解决问题！按照预想，引入redis后可以顺利解决三个问题：

• 内存级的读写速度，唰唰唰！
• session轻松easy实现了共享，哪怕以后业务服务器继续横向扩展到服务器D
• session的过期终于可以精确到秒了，说没就没，不用再靠信仰和概率了

将session存入redis需要修正如下两处php配置，首先设置session.save_handler = redis，其次是设置ession.save_path = &＃8220;tcp://127.0.0.1:6379&＃8243;，然后重启apache或者fpm，刷新一下网页，如果网页不报什么错误，理论上session数据就已经到redis中去了，连接redis查看下key，如下图：

从上至下我一共执行了五次redis命令，分别表示：

1. 查看所有keys从而获取php分配给我的session文件名称
2. 获取这个key的剩余时间，过期后redis该key算失效了
3. 查看这个key的数据类型，可以看出是string类型
4. 使用get直接获取string的值
5. 过了一段时间，我又刷新了一下网页，然后再次用ttl看该key的剩余时间，再次被延长到1440秒了

除了redis外（memcache我就不举例了，和redis类似），还有一种方案就是通过nfs共享来实现，大概原理就是弄一台服务器，通过内网共享对所有php业务服务器开放读写，大家知道linux下磁盘是可以挂载在某个文件夹下的，所以将nfs挂载到各个php业务服务器的某个目录下，然后按照上述文章修改响应配置就可以了。这个，我也没有尝试过也懒得自己去尝试了，所以偷个懒直接给大家抛个连接吧，是老叶博客上的一篇文章，《iMySQL | 老叶茶馆，PHP实现多服务器session共享之NFS共享》。

装逼完毕，如有问题，火速留言指正！