13518219792
对于大访问量的站点使用默认的Session 并不合适，我们可以将其存入数据库、或者使用Redis KEY-VALUE数据存储方案
创新互联是一家专业提供建邺企业网站建设,专注与成都网站设计、成都网站建设、H5响应式网站、小程序制作等业务。10年已为建邺众多企业、政府机构等服务。创新互联专业网站制作公司优惠进行中。
首先新建一个session表
CREATE TABLE `sessions` (
`sid` char(40) NOT NULL,
`updatetime` int(20) NOT NULL,
`data` varchar(200) NOT NULL,
UNIQUE KEY `sid` (`sid`) USING HASH
) ENGINE=MEMORY DEFAULT CHARSET=utf8;
Mysql 的memory引擎采用内存表，所有数据存储在内存，操作速度快
复制代码
?php
//引入数据库文件
include "db.php";
class MySessionHandler implements SessionHandlerInterface
{
private $savePath;
private $sessData;
public $expiretime; //设置过期时间
public $db; //数据库
public function __construct($hanlder =''){
$this-db = Database::getInstance();
//获取数据库实力
///var_dump($this-db);
}
public function open($savePath, $sessionName)
{
return true;
}
public function close()
{
return true;
}
public function read($id)
{
$sql ="select * from sessions where sid ='$id'";
$result = $this-db-execute($sql);
if(!empty($result)){
return $this-sessData = $result;
}
}
//函数的参数 $id - 当前会话ID
//数据DATA - 序列化之后的字符串
public function write($id, $data)
{
// echo $id;
// echo $data;
$now = time();
$newExp = $now+$this-expiretime; //总时间=当前时间 + 期限时间
$sql = "select * from sessions where sid ='$id'";
$result = $this-db-getOne($sql);
//var_dump($result);
if($data==''||isset($data)){
$data = $this-sessData;
}
if($result){
//如果存在则更新
$sql ="update sessions set updatetime = '$newExp',data ='$data' where sid = '$id'";
//echo $sql;
$update_data =$this-db-execute($sql);
if($update_data){
return true;
}
}else{
//不存在则生成生成
$sql = "insert into sessions(sid,updatetime,data) values('$id','$now','$data')";
$insert_data = $this-db-execute($sql);
if($insert_data){
return true;
}
}
return false;
}
public function destroy($id)
{ //销毁
$sql = "delete from sessions where sid="."$id";
$destory = $this-db-execute($sql);
if($destory){
return true;
}else{
return false;
}
}
public function gc($sessMaxLifeTime)
{
$t = time();
$sql ="delete from sessions where $t - 'updatetime'${sessMaxLifeTime}";
$data = $this-db-execute($this-tosql);
if($data){
return true;
}else{
return false;
}
return true;
}
}
复制代码
实例化
此处 PHP 手册可以有两种方法
1，实现了SessionHandlerInterface借口的对象,自PHP5.4可以使用
2 ，直接使用 session_set_save_handler
复制代码
//判断PHP版本
if(version_compare(PHP_VERSION,5.4)==1){
session_set_save_handler($handler, true);
session_start();
}else{
ini_set('session.use_trans_sid',0);
ini_set('session.use_cookies',1);
ini_set('session.cookie_path','/');
ini_set('session.save_handler','user');
session_module_name('user');
session_set_save_handler(array($session,"open"),array($session,"close"),array($session,"read"),array($session,"write"),array($session,"destory"),array($session,"gc"));
session_start();
}
$_SESSION['QQ']="QQ";
echo $_SESSION['QQ'];
复制代码
数据库代码 db.php
复制代码
?php
class Database{
static $instance;
static $db;
static function getInstance(){
if(self::$instance){
return self::$instance;
}else{
return new Database();
}
}
public function __construct(){
self::$db = new PDO('mysql:host=localhost;dbname=session', 'root','');
}
public function getOne($sql){
$rs =self::$db-query($sql);
@$rs-setFetchMode(PDO::FETCH_ASSOC);//返回关联数组
$result = $rs - fetch();
return $result;
}
public function execute($sql){
$rs = self::$db-exec($sql);
return $rs;
}
}
//$data = Database::getInstance();
//var_dump($data);
复制代码
使用REDIS 存储SESSION
复制代码
?php
class SessionManager{
private $redis;
private $sessionSavePath;
private $sessionName;
private $sessionExpireTime = 30;
public function __construct(){
$this-redis = new Redis();
$this-redis-connect('127.0.0.1',6379); //连接redis
$retval = session_set_save_handler(
array($this,"open"),
array($this,"close"),
array($this,"read"),
array($this,"write"),
array($this,"destory"),
array($this,"gc")
);
session_start();
}
public function open($path,$name){
return true;
}
public function close(){
return true;
}
public function read($id){
$value = $this-redis-get($id);
if($value){
return $value;
}else{
return "";
}
}
public function write($id,$data){
if($this-redis-set($id,$data)){
$this-redis-expire($id,$this-sessionExpireTime);
//设置过期时间
return true;
}
return false;
}
public function destory($id){
if($this-redis-delete($id)){
return true;
}
return false;
}
public function gc($maxlifetime){
return true;
}
//析构函数
public function __destruct(){
session_write_close();
}
}
$re = new SessionManager();
$_SESSION['name'] = "qq";
echo $_SESSION['name'];
redis比memcached功能更多更强大,现在基本都是只用redis了.
利用redis的原子性可以给数据加锁
可以保存临时数据,比如短信验证码和session
可以用于实现简单的队列任务
可以实现排行榜功能
可以实现经纬度距离计算
........
当然不止这些,redis是一种key-value数据库,他的业务场景还可以自己扩展.
能不能加锁这个不知道，但是可以用监控watch 和事务结合起来用。因为watch的功能就是当它监控一个键的时候，如果这个键被修改了，那么它后面的事务就不会执行。
比如：
set key 1;
watch key
set key 2
mulit
set key 3
exec
get key ='2' //key在watch后被修改了，所以后面的事务没有执行
Session 和 Cookie 有什么关系
Cookie 也是由于 HTTP 无状态的特点而产生的技术。也被用于保存访问者的身份标示和一些数据。每次客户端发起 HTTP 请求时，会将 Cookie 数据加到 HTTP header 中，提交给服务端。这样服务端就可以根据 Cookie 的内容知道访问者的信息了。 可以说，Session 和 Cookie 做着相似的事情，只是 Session 是将数据保存在服务端，通过客户端提交来的 session_id 来获取对应的数据；而 Cookie 是将数据保存在客户端，每次发起请求时将数据提交给服务端的。
上面提到，session_id 可以通过 URL 或 cookie 来传递，由于 URL 的方式比 cookie 的方式更加不安全且使用不方便，所以一般是采用 cookie 来传递 session_id。
服务端生成 session_id，通过 HTTP 报文发送给客户端（比如浏览器），客户端收到后按指示创建保存着 session_id 的 cookie。cookie 是以 key/value 形式保存的，看上去大概就这个样子的：PHPSESSID=e4tqo2ajfbqqia9prm8t83b1f2。在 PHP 中，保存 session_id 的 cookie 名称默认叫作 PHPSESSID，这个名称可以通过 php.ini 中 session.name 来修改，也可以通过函数 session_name() 来修改。
为什么不推荐使用 PHP 自带的 files 型 Session 处理器
在 PHP 中，默认的 Session 处理器是 files，处理器可以用户自己实现（参见：自定义会话管理器）。我知道的成熟的 Session 处理器还有很多：Redis、Memcached、MongoDB……
为什么不推荐使用 PHP 自带的 files 类型处理器，PHP 官方手册中给出过这样一段 Note：
无论是通过调用函数 session_start() 手动开启会话， 还是使用配置项 session.auto_start 自动开启会话， 对于基于文件的会话数据保存（PHP 的默认行为）而言， 在会话开始的时候都会给会话数据文件加锁， 直到 PHP 脚本执行完毕或者显式调用 session_write_close() 来保存会话数据。 在此期间，其他脚本不可以访问同一个会话数据文件。
上述引用参见：Session 的基本用法
为了证明这段话，我们创建一下 2 个文件： 文件：session1.php
?php
session_start();
sleep(5);
var_dump($_SESSION);
?
文件：session2.php
?php
session_start();
var_dump($_SESSION);
?
在同一个浏览器中，先访问 ，然后在当前浏览器新的标签页立刻访问 。实验发现，session1.php 等了 5 秒钟才有输出，而 session2.php 也等到了将近 5 秒才有输出。而单独访问 session2.php 是秒开的。在一个浏览器中访问 session1.php，然后立刻在另外一个浏览器中访问 session2.php。结果是 session1.php 等待 5 秒钟有输出，而 session2.php 是秒开的。
分析一下造成这个现象的原因：上面例子中，默认使用 Cookie 来传递 session_id，而且 Cookie 的作用域是相同。这样，在同一个浏览器中访问这 2 个地址，提交给服务器的 session_id 就是相同的（这样才能标记访问者，这是我们期望的效果）。当访问 session1.php 时，PHP 根据提交的 session_id，在服务器保存 Session 文件的路径（默认为 /tmp，通过 php.ini 中的 session.save_path 或者函数 session_save_path() 来修改）中找到了对应的 Session 文件，并对其加锁。如果不显式调用 session_write_close()，那么直到当前 PHP 脚本执行完毕才会释放文件锁。如果在脚本中有比较耗时的操作（比如例子中的 sleep(5)），那么另一个持有相同 session_id 的请求由于文件被锁，所以只能被迫等待，于是就发生了请求阻塞的情况。
既然如此，在使用完 Session 后，立刻显示调用 session_write_close() 是不是就解决问题了哩？比如上面例子中，在 sleep(5) 前面调用 session_write_close()。
确实，这样 session2.php 就不会被 session1.php 所阻塞。但是，显示调用了 session_write_close() 就意味着将数据写到文件中并结束当前会话。那么，在后面代码中要使用 Session 时，必须重新调用 session_start()。
例如：
?php
session_start();
$_SESSION['name'] = 'Jing';
var_dump($_SESSION);
session_write_close();
sleep(5);
session_start();
$_SESSION['name'] = 'Mr.Jing';
var_dump($_SESSION);
?
官方给出的方案：
对于大量使用 Ajax 或者并发请求的网站而言，这可能是一个严重的问题。 解决这个问题最简单的做法是如果修改了会话中的变量， 那么应该尽快调用 session_write_close() 来保存会话数据并释放文件锁。 还有一种选择就是使用支持并发操作的会话保存管理器来替代文件会话保存管理器。
我推荐的方式是使用 Redis 作为 Session 的处理器。
拓展阅读：
为什么不能用 memcached 存储 Session
如何使用 Redis 作为 PHP Session handler
Session 数据是什么时候被删除的
这是一道经常被面试官问起的问题。
先看看官方手册中的说明：
session.gc_maxlifetime 指定过了多少秒之后数据就会被视为"垃圾"并被清除。 垃圾搜集可能会在 session 启动的时候开始（ 取决于 session.gc_probability 和 session.gc_divisor）。 session.gc_probability 与 session.gc_divisor 合起来用来管理 gc（garbage collection 垃圾回收）进程启动的概率。此概率用 gc_probability/gc_divisor 计算得来。例如 1/100 意味着在每个请求中有 1% 的概率启动 gc 进程。session.gc_probability 默认为 1，session.gc_divisor 默认为 100。
继续用我上面那个不太恰当的比方吧：如果我们把物品放在超市的储物箱中而不取走，过了很久（比如一个月），那么保安就要清理这些储物箱中的物品了。当然并不是超过期限了保安就一定会来清理，也许他懒，又或者他压根就没有想起来这件事情。
再看看两段手册的引用：
如果使用默认的基于文件的会话处理器，则文件系统必须保持跟踪访问时间（atime）。Windows FAT 文件系统不行，因此如果必须使用 FAT 文件系统或者其他不能跟踪 atime 的文件系统，那就不得不想别的办法来处理会话数据的垃圾回收。自 PHP 4.2.3 起用 mtime（修改时间）来代替了 atime。因此对于不能跟踪 atime 的文件系统也没问题了。
GC 的运行时机并不是精准的，带有一定的或然性，所以这个设置项并不能确保旧的会话数据被删除。某些会话存储处理模块不使用此设置项。
对于这种删除机制，我是存疑的。
比如 gc_probability/gc_divisor 设置得比较大，或者网站的请求量比较大，那么 GC 进程启动就会比较频繁。
还有，GC 进程启动后都需要遍历 Session 文件列表，对比文件的修改时间和服务端的当前时间，判断文件是否过期而决定是否删除文件。
这也是我觉得不应该使用 PHP 自带的 files 型 Session 处理器的原因。而 Redis 或 Memcached 天生就支持 key/value 过期机制的，用于作为会话处理器很合适。或者自己实现一个基于文件的处理器，当根据 session_id 获取对应的单个 Session 文件时判断文件是否过期。
为什么重启浏览器后 Session 数据就取不到了
session.cookie_lifetime 以秒数指定了发送到浏览器的 cookie 的生命周期。值为 0 表示"直到关闭浏览器"。默认为 0。
其实，并不是 Session 数据被删除（也有可能是，概率比较小，参见上一节）。只是关闭浏览器时，保存 session_id 的 Cookie 没有了。也就是你弄丢了打开超市储物箱的钥匙（session_id）。
同理，浏览器 Cookie 被手动清除或者其他软件清除也会造成这个结果。
为什么浏览器开着，我很久没有操作就被登出了
这个是称为“防呆”，为了保护用户账户安全的。
这个小节放进来，是因为这个功能的实现可能和 Session 的删除机制有关（之所以说是可能，是因为这个功能不一定要借住 Session 实现，用 Cookie 也同样可以实现）。 说简单一点，就是长时间没有操作，服务端的 Session 文件过期被删除了。
一个有意思的事情
在我试验的过程中，发现了小有意思的事情：我把 GC 启动的概率设置为 100%。如果只有一个访问者请求，该访问者即使过了很久（超过了过期时间）后才发起第二次请求，那么 Session 数据也还是存在的（'session.save_path' 目录下面的 Session 文件存在）。是的，明明就超过了过期时间，却没有被 GC 删除。这时，我用另外一个浏览器访问时（相对于另一个访问者），这次请求生成了新的 Session 文件，而上一个浏览器请求生成的那个 Session 文件终于没有了（之前那个 Session 文件在 'session.save_path' 目录下面的消失了）。
还有，发现 Session 文件被删除后，再次请求，还是会生成和之前文件名相同的 Session 文件（因为浏览器并没有关闭，再次请求发送的 session_id 是相同的，所以重新生成的 Session 文件的文件名还是一样的）。但是，我不理解的是：这个重新出现的文件的创建时间竟然是第一次的那个创建时间，难道它是从回收站中回来的？（确实，我做这个试验时是在 window 下进行的）
我猜测的原因是这样：当启动会话后，PHP 根据 session_id 找到并打开了对应的 Session 文件，然后才启动 GC 进程。GC 进程就只检查除了当前这个 Session 文件外的其他文件，发现过期的就干掉。所有，即使当前这个 Session 文件已经过期了，GC 也没有删除它。
我认为这个不合理的。
由于发生这种情况影响也不大（毕竟线上请求很多，当前请求的过期文件被其他请求唤起的 GC 干掉的可能性是比较大的） + 我没有信心去看 PHP 源代码 + 我并不在线上使用 PHP 自带的 files 型 Session 处理器。所以，这个问题我就没有深入研究了。请谅解。
?php
// 过期时间设置为 30 秒
ini_set('session.gc_maxlifetime', '30');
// GC 启动概率设置为 100%
ini_set('session.gc_probability', '100');
ini_set('session.gc_divisor', '100');
session_start();
$_SESSION['name'] = 'Jing';
var_dump($_SESSION);
?
方法：
修改 php.ini 的设置
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"
修改完之后，重启一下 php-fpm。
由于redis是单线程的且性能很快，所以比较适合做全局分布式锁。
基本流程就是在操作可能某个全局冲突资源的时候，使用一个全局唯一key来判断是否有其他线程占用了资源，如果有其他线程占用，则报错退出或者循环等待。如果没有其他线程占用，则就可以通过添加分布式锁来占用这个资源，然后再执行后续的任务，在任务执行完成之后，再释放分布式锁，其他线程就可以继续使用这个资源了。
那么通过redis加锁的动作是什么呢？
简单加锁命令：
命令是：setnx
内部的实现机制就是判断这个key位置是不是有数据，没有数据就设置成value返回，有数据就返回一个特殊数值。
但是这里有一个问题是，如果占用资源的线程错误退出了，没有来得及释放分布式锁，这个锁就被永远的占用了
改进版的加锁：
命令是：1. setnx 2. expire
添加分布式锁的同时，添加一个锁锁过期的时间。这样，当加锁线程退出之后，至少等一段时间之后，锁是有机会释放掉的。
这里有一个小问题是，这两个命令是分开执行的，不是原子操作。那么就存在理论上来说，第一个命令执行完之后，就出现错误，来不及执行expire命令的可能，一种办法是自己写lua脚本，可以实现多条命令的原子化执行。一种办法是引用一些开源库。在2.8版本之后，redis为了解决这个问题，提供了官方版的解法，就是命令：set key value nx expireTimeNum ex，将上述两个命令合并成了一个命令。
有了过期时间之后解决了一部分问题，但是也有可能出现锁都过期了，但是中间执行的任务还没有结束，第一个线程还在执行了，第二个线程已经拿到锁开始执行了，那么这时候第一个线程如果执行完成之后，那么就会将第二个线程的锁释放掉了。第二个线程释放锁的时候，要不然出错，要不然是释放的其他线程的锁，这样也会和预期不符。
如果单纯地要解决这个问题的话，可以在设置value的时候使用一个随机数，释放锁的时候，先判断这个随机数是否一致，如果一致再删除锁，否则就退出。但是判断value和删除key也不是一个原子操作，这时候就需要使用lua脚本了。
上面的方案依然不能解决超时释放的问题，依然违背分布式锁的初衷。怎么办了？
解题思路是另外启动一个线程，它的任务就是每隔一段时间判断一下如果发现当前线程的任务快过期了还没有完成，则定期给当前线程的锁续个期。
有个开源库解决了这个问题，它大概率会比你实现得更好一些。这个库就是redisson，非常好记，就是redis的儿子son，连起来就是reidsson，虽然可能不是亲的，但是也足够了。
这个库里面有一个组件是watchdog，直译过来就是看门狗，它的作用就是每隔一段时间判断的。
再继续思考，还有一个更极端的问题是，redis如果是单节点的，它宕机了；或者是主备节点的，但是备份节点还没有来得及同步主节点的数据，主节点拿到锁之后，在同步数据之前就马上宕机了，则也有可能出现锁不住的问题。如果认为这是一个问题，想要解决这个问题，这个问题怎么解决了？
思路是在加锁的时候多加锁几台redis服务器，通常情况下redis部署的时候是2n+1台，那么在加锁的时候需要保证过半数服务器加锁成功了，也就是说n+1台服务器。这时候除非整个集群都不可用了，则这个安全性将大幅度提升。
这个问题也有开源库解决了，就是redis红锁。
下一个问题是分布式锁可以重入么？
如果想要实现可重入的分布式锁的话，需要在设置value的时候加上线程信息和加锁次数的信息。但是这是简单的思路，如果加上过期时间等问题之后，可重入锁就可能比较复杂了。
