Swoole服务重启后数据丢失如何解决

当 Swoole 服务重启后出现数据丢失，先别急着拍桌子——这不是“重启”本身的锅，而是设计上缺少对关键状态的容错机制。比如用户 Session 凭空消失、数据库事务因连接池失效而中断、内存表里的缓存数据蒸发、Task 进程的中间结果没落库……这些问题的本质，都是持久化或连接健康检测没做到位。

## 确认数据丢失范围与源头 先搞清楚丢的是哪一类数据：用户 Session？数据库连接中未提交的事务？SwooleTable 里的运行时缓存？还是 Task 进程里未落库的中间结果？ 查日志定位时间点，这一步不能省： ```bash grep -i "worker exit|task exit|coroutine max" /var/log/swoole/error.log ``` 重点盯住 **【manager进程退出】** 或者 `task_worker_num` 耗尽的报错。如果日志中出现 `PHP Warning: SwooleTable::set(): table is full`，说明 SwooleTable 容量不够，写入失败且没有 fallback 机制——这部分数据必然是丢了的。 ## 恢复已丢失的Session数据 **方法一：从Redis重建Session** 前提是你已经用 Redis 存储 Session。登录 Redis 执行 `keys "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 检测逻辑： ```php if (!$mysql->connected || !$mysql->ping()) { $mysql = new Swoole\Coroutine\MySQL(); $mysql->connect($config); } ``` **第三步：替换原有连接池实现** 放弃那种固定数量连接的静态池。改用 `Swoole\Runtime::enableCoroutine(true)` + 每次按需 `new Swoole\Coroutine\MySQL()`，配合 `try/catch` 捕获连接异常并重试3次——这才是协程环境下的正确姿势。 ## 防止SwooleTable数据丢失 SwooleTable 是内存数据结构，不持久、无备份、满了就丢弃。所以： 1. 立即停止向 table 写入非关键数据。 2. 把高频读写状态迁移到 Redis，例如设备在线状态用 `SET device:1001 online EX 60`，利用 EXPIRE 自动清理。 3. 如果必须用 Table 存临时索引，启动时从 Redis 预热： ```php $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 监听变更，补偿缺失的异步动作。** 这一层可以作为保底手段——当上游重试也来不及的时候，从数据库日志里找回丢失的操作。