老旧话题：从新看看当年感受很难的session

原文地址：https://t.ti-node.com/thread/...

这基本上算是个老旧的话题了，几乎全部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文件的内容：

<?php
// 开启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 = "N;/path"这样的，其中N是一个正整数，这个数值的含义就是指将目录分红几个层次，好比咱们修改为session.save_path = “2;/var/lib/php/sessions”，而后重启一下apache或者fpm进程管理器，而后执行以下代码：

<?php
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 = "tcp://127.0.0.1:6379"，而后重启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共享》。

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