Workerman通过将Session数据存储至Redis实现分布式会话共享，避免传统PHP-FPM依赖文件存储和请求生命周期的局限；因其常驻内存、多进程隔离特性，直接使用$_SESSION会导致会话数据无法跨进程共享，故需借助外部统一存储。具体实现为：客户端通过Cookie传递Session ID，各Worker进程据此从Redis读取并更新序列化后的会话数据，确保任意进程均可访问最新状态。关键步骤包括引入Redis客户端、生成唯一SID、封装Session类进行存取与销毁操作，并设置合理TTL。进阶优化涵盖Redis集群高可用、Session数据精简、滑动过期策略、并发写入控制（如乐观锁）、跨域Cookie处理（SameSite=None+Secure）及心跳机制维持长连接Session活性，全面提升分布式环境下会话管理的性能与可靠性。
Workerman在处理会话共享，特别是分布式Session时，与传统PHP-FPM模式有着本质的区别。简单来说，Workerman要实现会话共享，尤其是跨进程或跨服务器的分布式Session，核心策略就是将Session数据剥离出Workerman进程本身，统一存储到一个外部的、所有Workerman实例都能访问的持久化存储中，其中Redis是目前最推荐和常用的方案。
直接使用外部存储，如Redis，来统一管理所有客户端的会话数据。当客户端连接到任何一个Workerman进程时，该进程都通过一个唯一的会话ID（通常通过Cookie传递）去Redis中存取对应的会话信息。这确保了无论客户端的请求被哪个Worker进程处理，都能访问到同一份最新的会话状态。
在我看来，理解Workerman与传统PHP应用在Session处理上的差异，是解决问题的起点。传统PHP应用，比如基于Apache/Nginx + PHP-FPM的架构，其生命周期是“请求-响应”式的。每次HTTP请求进来，PHP-FPM会启动一个PHP进程（或复用一个），执行脚本，然后进程退出或等待下一个请求。在这个短暂的生命周期里，
session_start()函数会根据配置（通常是文件或Redis/Memcached）加载Session数据到
$_SESSION全局变量，请求结束后再将
$_SESSION的数据写回存储。这种模式下，Session的管理是与请求生命周期紧密绑定的。
然而，Workerman是常驻内存的，它构建的是长连接服务。一个Workerman进程启动后，会一直运行，可能会处理成千上万个客户端的连接和请求。每个Worker进程都有自己独立的内存空间，它们之间默认是隔离的。这意味着，如果你在一个Worker进程中直接操作
$_SESSION，这个变量的数据只存在于当前这个进程的内存中。如果同一个客户端的下一个请求，因为负载均衡或其他原因，被分配到了另一个Worker进程处理，那么新进程是无法获取到上一个进程中
$_SESSION的数据的。这就像两个人各自写了一本日记，对方是无法直接读到你的日记内容的。文件Session的性能瓶颈和并发写入问题，在Workerman这种高并发场景下更是不可接受的。因此，传统的Session机制在这里就显得力不从心了。
要让Workerman实现会话共享，尤其是在分布式场景下，将Session数据外置到Redis是一个既成熟又高效的方案。这背后的核心思想是：Workerman进程不再直接持有Session数据，而是通过一个唯一的Session ID（SID）作为“钥匙”，去Redis这个“公共储物柜”里存取对应的会话信息。
具体的实现步骤和一些考量点：
php-redis扩展或者
webman/redis-session等Composer包。这是与Redis进行通信的基础。
Set-Cookie发送给客户端。客户端浏览器会保存这个Cookie，并在后续的每次请求中自动带上它。
onMessage或
onConnect回调中，从客户端请求的Cookie中解析出SID。如果Cookie中没有SID（说明是新用户），则重复上述生成和设置Cookie的步骤。
serialize或JSON编码）后的字符串。获取后，反序列化成PHP数组或对象，供当前请求使用。
一个简化的伪代码思路：
400-7654-355 // 假设你已经有了Redis客户端实例 $redisClient
// 假设你已经从客户端请求中获取到了当前的Session ID $currentSid
class MySession {
protected $redis;
protected $sid;
protected $data = [];
protected $isLoaded = false;
protected $hasChanged = false;
public function __construct($redis, $sid) {
$this->redis = $redis;
$this->sid = $sid;
}
protected function load() {
if ($this->isLoaded) {
return;
}
$rawData = $this->redis->get("session:".$this->sid);
if ($rawData) {
$this->data = unserialize($rawDat
a); // 或者 json_decode
} else {
$this->data = [];
}
$this->isLoaded = true;
}
public function get(string $key, $default = null) {
$this->load();
return $this->data[$key] ?? $default;
}
public function set(string $key, $value) {
$this->load();
if (($this->data[$key] ?? null) !== $value) { // 简单判断是否真正改变
$this->data[$key] = $value;
$this->hasChanged = true;
}
}
public function save(int $ttl = 3600) { // 默认1小时过期
if (!$this->hasChanged && $this->isLoaded) { // 如果数据没变，且已经加载过，可以只刷新过期时间
$this->redis->expire("session:".$this->sid, $ttl);
return;
}
$this->redis->set("session:".$this->sid, serialize($this->data), $ttl);
$this->hasChanged = false;
}
public function destroy() {
$this->redis->del("session:".$this->sid);
$this->data = [];
$this->hasChanged = false;
// 别忘了通知客户端清除Cookie
}
}
// 在Workerman的onMessage或onWebSocketMessage回调中：
// $sid = $request->cookie('PHPSESSID') ?? generate_new_sid(); // 假设$request是Workerman的请求对象
// if (!$request->cookie('PHPSESSID')) {
// // 首次请求，需要设置Cookie给客户端
// $response->withCookie(new Cookie('PHPSESSID', $sid, time() + 3600)); // 举例
// }
// $session = new MySession($redisClient, $sid);
// $userId = $session->get('user_id');
// if (!$userId) {
// $session->set('user_id', 123);
// }
// // ... 处理业务逻辑 ...
// $session->save(); // 确保在请求结束时保存Session关键考量点：
serialize/
unserialize是PHP原生的，但可能与其他语言不兼容。JSON (
json_encode/
json_decode) 更通用，但对某些复杂PHP对象可能不适用。根据实际需求选择。
MULTI/
EXEC）或Lua脚本，以保证操作的原子性。但对于大部分Web Session场景，简单覆盖通常是可接受的。
当你的Workerman应用规模逐渐扩大，涉及到多台服务器部署，或者需要处理极高并发时，分布式Session的优化和可能遇到的挑战就会浮现出来。这不仅仅是把数据扔到Redis那么简单，还需要考虑更深层次的设计。
SETNX（Set if Not Exists）命令或
RedLock算法实现分布式锁。在修改Session前先获取锁，修改完成后释放锁。但这会引入额外的性能开销和死锁风险，通常只在对数据一致性要求极高的特定场景下考虑。
app.example.com，Workerman
ws.example.com），浏览器默认会阻止跨域Cookie的发送。
SameSiteCookie属性： 现代浏览器对
SameSite=Lax或
Strict有更严格的限制。你可能需要将
SameSite设置为
None并同时使用
Secure属性（要求HTTPS），或者考虑不完全依赖Cookie，而是通过自定义HTTP头部或WebSocket消息传递SID。
这些进阶的考量和优化，都要求我们对Workerman的运行机制、Redis的特性以及分布式系统的挑战有更深入的理解。没有一劳永逸的方案，选择哪种策略，往往是根据你的业务场景、性能要求和可接受的复杂性来权衡的。
a); // 或者 json_decode
} else {
$this->data = [];
}
$this->isLoaded = true;
}
public function get(string $key, $default = null) {
$this->load();
return $this->data[$key] ?? $default;
}
public function set(string $key, $value) {
$this->load();
if (($this->data[$key] ?? null) !== $value) { // 简单判断是否真正改变
$this->data[$key] = $value;
$this->hasChanged = true;
}
}
public function save(int $ttl = 3600) { // 默认1小时过期
if (!$this->hasChanged && $this->isLoaded) { // 如果数据没变，且已经加载过，可以只刷新过期时间
$this->redis->expire("session:".$this->sid, $ttl);
return;
}
$this->redis->set("session:".$this->sid, serialize($this->data), $ttl);
$this->hasChanged = false;
}
public function destroy() {
$this->redis->del("session:".$this->sid);
$this->data = [];
$this->hasChanged = false;
// 别忘了通知客户端清除Cookie
}
}
// 在Workerman的onMessage或onWebSocketMessage回调中：
// $sid = $request->cookie('PHPSESSID') ?? generate_new_sid(); // 假设$request是Workerman的请求对象
// if (!$request->cookie('PHPSESSID')) {
// // 首次请求，需要设置Cookie给客户端
// $response->withCookie(new Cookie('PHPSESSID', $sid, time() + 3600)); // 举例
// }
// $session = new MySession($redisClient, $sid);
// $userId = $session->get('user_id');
// if (!$userId) {
// $session->set('user_id', 123);
// }
// // ... 处理业务逻辑 ...
// $session->save(); // 确保在请求结束时保存Session
