Hyperf 的 Redis Session 默认不保证并发写入一致性，因 PHP Session 仅在脚本结束时批量写入，且 Redis Handler 的锁仅作用于 read() 阶段，write() 无全程锁定，导致多请求覆盖；解决方案包括手动加 RedisLock 或用 Redis 原生命令原子操作。
Hyperf 的 Redis Session 默认不保证并发写入一致性，直接改 $_SESSION 并不能实时落库，多个并发请求可能相互覆盖。 根本原因不是 Redis 慢，而是 PHP 的 Session 生命周期机制：数据只在脚本结束时批量 write() 一次，中间修改全在内存里。Redis Handler 虽然快，但没解决“多请求同时读-改-写同一 session ID”的竞态问题。
为什么 Redis Session 会丢数据
文件存储有隐式 flock 锁，强制串行；而 Redis Session Handler 默认开启的锁（通过 SETNX 或 Lua）只在 read() 阶段加，write() 时并不锁定整个生命周期。这意味着：
- 请求 A 读取 session → 得到
['count' => 5] - 请求 B 同时读取 → 也得到
['count' => 5] - A 改为
['count' => 6]，B 改为['count' => 7] - 两者先后
write()→ 后写的完全覆盖前写的，最终变成7，6丢失
这不是 bug，是设计使然 —— Redis Handler 优先性能和解耦，把并发控制交还给业务层。
用 RedisLock 手动包裹 session 写操作
不依赖框架自动锁，自己在关键写逻辑前后加分布式锁。适用于登录态更新、计数器累加、订单状态变更等需强一致的场景。
- 锁 key 建议带 session ID 和业务标识，例如
session:write:{$sessionId}:cart - 锁超时必须大于业务逻辑最大耗时，建议设为
30秒起，避免死锁 - 务必在
try/catch中释放锁，或用finally确保执行unlock() - 不要在锁内做远程调用（如 HTTP 请求），否则锁持有时间不可控
示例：
Session Handoff
下载
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
$lock = make(RedisLock::class);
$sessionId = $this->session->getId();
$lockKey = 'session:write:'.$sessionId.':profile';
if ($lock->lock($lockKey, 30)) {
try {
$data = $this->session->get('profile', []);
$data['last_active'] = time();
$data['visits'] = ($data['visits'] ?? 0) + 1;
$this->session->set('profile', $data);
// 不需要手动 write() —— Hyperf 会在响应结束时自动 flush
} finally {
$lock->unlock($lockKey);
}
} else {
throw new RuntimeException('Session write locked by another request');
}
更轻量的替代方案：用 Redis 原生命令原子更新
如果只是增/减/设置某个字段（比如访问次数、状态标记），没必要锁整个 session，直接绕过 $_SESSION，用 Redis 命令原地操作：
- 用
INCRBY替代$count++ - 用
HSET+HGETALL管理结构化字段，比序列化整个$_SESSION更可控 - 会话元数据（如
user_id、login_at）仍走 session，业务数据走独立 key
例如：
// 不要这样
$this->session->set('visits', ($this->session->get('visits', 0) + 1));
// 改成这样（key 命名带 session ID 隔离）
$redisKey = 'session_data:'.$this->session->getId().':stats';
$this->redis->hIncrBy($redisKey, 'visits', 1);
$this->redis->hSet($redisKey, 'last_action', time());
别忽略 session GC 和连接池配置
即使加了锁，底层 Redis 连接不稳定或 GC 频繁也会放大问题：
- 确认
config/autoload/redis.php中连接池min_connections≥ 并发峰值，避免抢连接超时导致锁失败 - 关闭
gc_probability相关配置（Hyperf Redis Handler 的gc()是空操作，但若误配了其他 handler 可能触发阻塞） - 所有 session 相关操作尽量在同一个协程上下文完成，避免跨协程共享
$session实例
真正难的不是加锁，而是判断哪部分数据必须强一致、哪部分可以最终一致。多数用户信息更新其实允许短暂延迟，硬上锁反而拖垮吞吐。先想清楚「这里到底能不能丢」，再决定要不要锁。
