session

session简介

上次咱们说了cookie(http://www.javashuo.com/article/p-tlmdohfp-ko.html)，因为HTTP的无状态性，这个cookie至关于大楼保安给进入大楼的人的一张小纸条，一段信息数据，下次进入的时候出示小纸条就能够了。那么，保安怎么去校验这张纸条呢？怎么判断这张纸条是有效的，而不是伪造的，也没有过时呢？这就要用到session了。

这里的session，咱们用来表示一次HTTP链接和会话，通过校验以后，留存在服务器端的一些数据，特别是关于用户的数据。就比如你进入大楼时，在访客登记表(这里涉及到session的存储方式:文件，数据库，缓存)上登记的信息。登记完了以后，保安大叔给你一段cookie，后续你进入，出示小纸条，保安大叔就去登记表上查，看有没有小纸条上记录的信息。那经过什么去查呢，session_id。这个session_id是在大叔发送小纸条时，经过系统生成的，通常是惟一的，带有有效期的，它保留在服务器端，也写入cookie。用session_id一查，看是否有记录，是否还在有效期。固然还有用token来替代session_id的，本质是同样的。

session锁问题

假如咱们遇到一种这样的状况，A用小纸条请求进入大楼，保安大叔[1](PHP进程[1])一看，身份没问题，只是有效期快到了，我给你改一个新的有效期(参考身份证)。这个时候，A的双胞胎兄弟B用一张如出一辙的小纸条请求进入大楼，另外一个保安大叔[2](PHP进程[2])一查，确实有记录，身份也没问题，可是这个记录正在被保安大叔[1]修改，那如今要不要放行呢？

这就涉及到session读写锁的问题了。

当A请求时，PHP启动了session_start()表示会话开启（第一次没有小纸条）/重用现有会话（有小纸条）。此时，PHP就加上一个读写锁，阻塞（等待），（注意: 这部分锁住的时间不会计算在PHP的“max_execution_time”配置项的时间内，“max_execution_time”详见set_time_limit()。），对应的session被锁定（若是是session文件，在Linux主机上是依靠flock()方法实现的），对session的操做都会先保存在内存中，直到脚本经过session_write_close()或者脚本结束才会写入session中，从而释放锁。在这锁未释放的期间，其余PHP进程请求的对session的操做，都会等待。

若是不加锁，A请求作修改，B也同时作修改，最后的结果是总有一我的的修改不生效，被另外一我的的修改覆盖掉了，致使数据不一致问题。

若是加锁，也会致使一个问题，对B的校验必须等待A的释放或者完成以后才能进行，影响了响应的速度。因此，

涉及到的ajax接口不须要用session的就不session_start()；

不须要写入session的就在session_start()后直接加入session_write_close()；

须要写入session的，写入session后直接加入session_write_close()。

总而言之，能不锁就不锁，要锁的话尽可能压缩锁的时间。