Swoole服务重启后数据丢失源于关键状态未持久化或连接池失效，需区分Session、事务、Table缓存或Task结果等丢失类型，通过日志定位问题，用Redis重建Session、启用MySQL连接健康检测、迁移Table数据至Redis、并采用任务队列+幂等机制保障Task可靠性。
当Swoole服务重启后出现数据丢失，说明关键状态未持久化或连接池失效导致事务中断、Session清空、内存表数据蒸发——这不是“重启本身”造成的，而是设计中缺少容错机制。
确认数据丢失范围与源头
先区分是哪类数据丢了：用户Session？数据库连接中的未提交事务？Swoole\Table里的运行时缓存？还是Task进程里未落库的中间结果？
查日志定位时间点：grep -i "worker exit\|task exit\|coroutine max" /var/log/swoole/error.log，重点看是否有 【manager进程退出】 或 task_worker_num 耗尽的报错。
若日志中出现 “PHP Warning: Swoole\Table::set(): table is full”，说明 swoole_table 容量不足，写入失败且无 fallback 机制，这部分数据必然丢失。
恢复已丢失的Session数据
方法一：从Redis重建Session（前提是你已用Redis存储）
登录Redis服务器，执行 keys "session:*" 查看存活Session键；若键存在但PHP端无法读取，检查是否设置了错误的 session_name 或 cookie domain 不匹配。
方法二：强制刷新客户端Session ID并回填关键字段
在请求入口处判断 $_SESSION 为空时，尝试从JWT token或数据库用户表中拉取用户基础信息，调用 session_regenerate_id(true) 生成新ID，再 setcookie() 同步到客户端。
【注意：不要直接 unserialize($_COOKIE['PHPSESSID']）来还原，该值已被加密且不可逆】
修复数据库连接池失效问题
第一步：确认MySQL是否真正重启过
执行 systemctl status mysqld 或 docker ps | grep mysql，若MySQL服务也重启了，Swoole协程客户端持有的旧连接句柄会全部失效。
第二步：启用连接健康检测与自动重建
在数据库操作前插入 ping 检测逻辑：if (!$mysql->connected || !$mysql->ping()) { $mysql = new Swoole\Coroutine\MySQL(); $mysql->connect($config); }。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
第三步：替换原有连接池实现
弃用基于固定数量连接的静态池，改用 Swoole\Runtime::enableCoroutine(true) + 每次按需 new Swoole\Coroutine\MySQL()，配合 try/catch 捕获连接异常并重试3次。
防止Swoole\Table数据丢失
① 立即停止向 table 写入非关键数据——它不持久、无备份、满容量即丢弃。
② 将高频读写状态迁移至 Redis：例如设备在线状态用 SET device:1001 online EX 60，用 EXPIRE 自动清理。
③ 若必须用 Table 存临时索引，启动时从 Redis 预热：$table->foreach(function ($key, $value) use ($redis) { $table->set($key, ['data' => $redis->get("cache:$key")]); });
【切勿在 worker_start 回调中执行耗时的 Redis 批量读取，会导致 worker 启动卡死】
重建Task进程未完成任务
方法1：启用任务队列兜底
所有发往 taskworker 的任务，先 push 到 Redis List（如 task:pending），再由 taskworker 消费成功后 LREM 删除；服务重启后，用定时器扫描 list 长度，对积压任务重新 dispatch。
方法2：记录任务指纹+幂等标记
每个任务携带唯一 trace_id，入库前先 SELECT COUNT(*) FROM task_log WHERE trace_id = ?；存在则跳过，不存在则 INSERT + 执行业务逻辑。
方法3：利用 MySQL binlog 或 Canal 监听变更，补偿缺失的异步动作。
