老旧话题:重新看看当年感觉很难的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文件的内容:

刷新一下网页,然后在再次查看原来的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进程管理器,然后执行如下代码:

刷新网页,如下图所示:

错误原因相比大家看到了,大概意思就是说“/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共享》。

装逼完毕,如有问题,火速留言指正!

你可能感兴趣的:(php,session,redis,cookie)