PHP session_set_save_handler 如何接入 Redis 并处理并发写入

把 PHP session 放到 Redis，关键不在于把 $_SESSION 转成 JSON，而是遵守 PHP handler 的回调契约：read() 返回原样的序列化字符串，write() 保存 PHP 传来的字符串；同一 session ID 的并发请求还要有锁，否则两个请求读到同一份旧快照，后写入的请求会覆盖前一个更新。

实用方案是：在 read() 中用 Redis SET lock:{id} token NX EX seconds 获取带租期的锁，在 write() 中使用带 TTL 的 SET 保存会话，在 close() 中用 Lua 脚本比较 token 后删除锁。Redis 负责键过期，PHP 的 gc() 只保留接口职责。

先把 Redis 键和 PHP 回调对上

PHP 会在会话启动时调用 open() 和 read()，把 read() 返回的字符串解码后填入 $_SESSION；请求结束或主动调用 session_write_close() 时，再把当前会话编码后交给 write()，随后调用 close()。因此 Redis 中的值应保持 PHP 选择的序列化格式，不要在 handler 里擅自改成数组。

一个可落地的 Redis handler 最小骨架

下面示例使用 Predis，重点放在回调职责和锁边界。生产代码还应把连接异常转成明确日志，并为 Redis 不可用时决定“拒绝请求”还是降级到其他存储。

id = $id;
        $this->token = bin2hex(random_bytes(16));
        $lockKey = "lock:{$id}";
        $locked = $this->redis->set($lockKey, $this->token, 'EX', $this->lockTtl, 'NX');
        if ($locked !== 'OK') {
            return false; // 也可以按业务改成短暂重试后报错。
        }
        return $this->redis->get("session:{$id}") ?? '';
    }

    public function write(string $id, string $data): bool
    {
        // EX 让 Redis 自动回收长时间未访问的会话数据。
        return (bool) $this->redis->set("session:{$id}", $data, 'EX', $this->ttl);
    }

    public function close(): bool
    {
        // 只有 token 仍匹配时才删除，避免误删后来请求持有的锁。
        $script = 'if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end';
        $this->redis->eval($script, 1, "lock:{$this->id}", $this->token);
        return true;
    }

    public function destroy(string $id): bool
    {
        // 注销时同时移除会话数据；锁由 close 的 token 校验负责释放。
        return (bool) $this->redis->del(["session:{$id}"]);
    }

    public function gc(int $max_lifetime): int|false
    {
        // 数据键已经带 TTL，Redis 不需要 PHP 扫描全库。
        return 0;
    }
}

$handler = new RedisSessionHandler(new \Predis\Client('tcp://127.0.0.1:6379'));
// 第二个参数让 PHP 在请求结束时注册 session_write_close()。
session_set_save_handler($handler, true);
session_start();

并发写入要靠租约锁而不是一个简单的 SET

只给会话数据设置 TTL，解决的是“多久过期”，并没有解决“谁可以修改”。请求 A 和请求 B 若同时读取 session:{id}，各自改动后再写回，最后一次写入仍会覆盖另一份数据。

SET ... NX EX 把“仅在锁不存在时写入”和“设置租期”放在一次 Redis 命令里。拿锁成功的请求把随机 token 留在 lock:{id}，释放时用 Lua 原子比较 token 并删除；这样即使锁已经超时、后来请求拿到了新锁，旧请求也不会把新锁删掉。

过期、长请求和上线检查

把 session.gc_maxlifetime 作为数据 TTL 的参考值，但不要把它误解为 Redis 的自动配置。本文示例使用固定 1800 秒，实际项目应让两者有清晰的配置来源。锁 TTL 则要大于正常最长请求时间；如果上传、导出等请求可能超过锁租期，应增加续租机制，或者在进入慢操作前先调用 session_write_close()，缩短会话锁持有时间。

上线前至少检查四项：Redis 断开时 handler 是否返回失败；read() 失败后是否避免继续写脏数据；destroy() 是否只删除当前会话；以及重复请求是否确实使用同一个 session cookie。不要在 close() 里直接执行 DEL lock:{id}，这会把已经超时后被新请求重建的锁一起删掉。

相关问题

为什么 read 要返回空字符串而不是 null？

PHP handler 需要收到原样的编码数据；新会话没有数据时返回空字符串最稳妥，失败场景才使用 false 并配合日志或重试策略。

gc 回调还需要扫描 Redis 吗？

如果每个会话键都设置了 TTL，通常不需要全库扫描。保留回调并返回实际处理数量或 0，让 Redis 负责过期删除。

锁拿不到时应该一直等待吗？

不建议无限等待。可设置短暂重试上限，超过后返回明确错误；锁租期足够且业务允许时，也可以把等待策略写入配置。