各位老铁，大家早上好！欢迎来到今天的“Swoole 共享内存实战”现场。我是你们的老朋友，一个在 PHP 和内存条之间反复横跳的编程专家。
今天我们不聊虚的，咱们聊聊如何让多个 PHP 进程像亲兄弟一样，共享同一个秘密，而且不需要写电子邮件互相通知。这就是 Swoole Table 的核心魅力——零拷贝的物理状态实时同步。
1. 痛点：PHP 进程间的“隔阂”
在传统 PHP（FPM 模式）下，我们的代码是“来一个请求，杀一个进程”。这导致了一个很尴尬的问题：如果进程 A 刚刚给用户发了一个红包，进程 B 就启动了，它不知道红包发没发，它只能重新查数据库。这不仅慢，还容易并发出两个红包（虽然数据库有锁，但那是在文件系统层面的锁，慢得像蜗牛）。
而当我们用 Swoole（常驻内存）开发时，一切都不一样了。我们的 PHP 进程会活很久，甚至好几年不重启。这时候，如果进程 A 想知道进程 B 里存了什么数据，怎么办？
如果用 Redis，那必须发个网络包，走一遍 TCP/IP 协议栈，还得序列化/反序列化。这就好比两个人在同一个房间，但中间隔了一道带加密玻璃的墙，还得喊话。这太慢了！
这时候，Swoole Table 登场了。它就像是一个巨大的、透明的、带锁的公共冰箱，放在房间中央。所有进程都能直接伸手进去拿东西，或者放东西。这叫什么？这就叫共享内存。
2. Swoole Table 是什么？
Swoole Table，本质上是基于内存映射技术实现的一种哈希表。
请记住几个关键词：
- 内存级：读写速度跟 CPU 缓存一个级别，纳秒级的。
- 进程级：所有 Worker 进程都能看到这张表。
- 轻量级：没有网络开销，没有序列化开销。
- 带锁：虽然快，但不是完全无序的，它内置了行锁机制。
3. 第一步：搭建你的“冰箱”
我们要创建一个 Table，首先得定义它的结构。你想存什么？是用户 ID？是分数？还是一段很长的 JSON 字符串？
看这段代码：
<?php
// 实例化 Table，必须指定内存大小，单位是字节
// 1024 * 1024 * 10 就是 10MB
$table = new SwooleTable(1024 * 1024 * 10);
// 定义列（字段）
// 第一列：uid，类型是整数
$table->column('uid', SwooleTable::TYPE_INT, 32);
// 第二列：money，类型是整数，最大值设为 10 位
$table->column('money', SwooleTable::TYPE_INT, 10);
// 第三列：info，类型是字符串，最大长度设为 64
$table->column('info', SwooleTable::TYPE_STRING, 64);
// 初始化表结构
$table->create();专家提示：这里有个坑，大家千万要记住。$table->create() 是必须的！很多人在 Swoole 4.x 以后忘记这一步，导致 create() 报错或者表结构不生效。另外，内存大小设置要大于你预估的 key 字符串的长度。如果你的 Key 是一个很长的 UUID，那你给的大小不够，程序直接就崩了。
4. 第二步：往冰箱里放东西
有了冰箱，我们得放数据。这就好比往系统表里插入一条用户记录。
// 设置键值对
// Key 是 'user_1001'
// Value 是数组 ['uid' => 1001, 'money' => 5000, 'info' => '土豪']
$table->set('user_1001', [
'uid' => 1001,
'money' => 5000,
'info' => '这是一个土豪玩家'
]);这时候，如果你在另一个进程里去读：
// 读取数据
var_dump($table->get('user_1001', 'money')); // 输出: int(5000)
var_dump($table->get('user_1001', 'info')); // 输出: string(12) "这是一个土豪玩家"看到了吗？零拷贝！ 没有网络，没有序列化。它就像是把你的手伸进了冰箱直接拿出了可乐。
5. 实战场景：实时在线排行榜（斗地主）
光说不练假把式。咱们来搞个斗地主游戏的在线排行榜。
场景是这样的：
- 有 4 个 Worker 进程在处理游戏逻辑。
- 有 1000 个玩家在游戏中。
- 我们需要实时显示所有玩家的分数，并且随着游戏进行，分数实时变化。
怎么用 Swoole Table 做？
设计表结构
// 假设我们要存 100 万个玩家的实时分数
$gameTable = new SwooleTable(1024 * 1024 * 50); // 50MB 内存，存 100 万条数据绰绰有余
$gameTable->column('uid', SwooleTable::TYPE_INT, 32);
$gameTable->column('score', SwooleTable::TYPE_INT, 10); // 分数
$gameTable->column('is_online', SwooleTable::TYPE_INT, 1); // 0=离线, 1=在线
$gameTable->column('room_id', SwooleTable::TYPE_INT, 8); // 所在房间
$gameTable->create();模拟玩家登录与下线
// 进程 A：处理登录逻辑
function handleLogin($uid) {
global $gameTable;
// 模拟查询数据库验证用户
// ... 数据库查询 ...
// 如果登录成功，写入内存表
$gameTable->set("user_{$uid}", [
'uid' => $uid,
'score' => 1000, // 初始分
'is_online' => 1,
'room_id' => 0
]);
echo "Player {$uid} logged in. Current online count: " . countOnline($gameTable) . "n";
}
// 进程 B：处理下线逻辑
function handleLogout($uid) {
global $gameTable;
// 删除该玩家数据
if ($gameTable->exist("user_{$uid}")) {
$gameTable->del("user_{$uid}");
echo "Player {$uid} logged out. Current online count: " . countOnline($gameTable) . "n";
}
}
// 辅助函数：统计在线人数（遍历内存表）
function countOnline($table) {
$count = 0;
foreach ($table as $row) {
if ($row['is_online'] == 1) {
$count++;
}
}
return $count;
}
// 演示
handleLogin(1001);
handleLogin(1002);
handleLogout(1001);6. 核心黑科技：原子操作
各位，这里有个大问题。如果玩家 A 打出了伤害，玩家 B 的血量需要减去 50。如果两个 Worker 进程同时操作同一条数据，会发生什么？
在传统的 MySQL 里，我们用事务。在 Redis 里，我们用 Lua 脚本。而在 Swoole Table 里，我们用原子递增/递减！
这比写锁快多了！它是利用 CPU 的原子指令做的。
想象一下，你正在数钱。你不能一只手数一张钞票，两只手同时数。原子操作就是规定，数钱这个动作必须一口气完成，中间不能被打断。
看代码：
// 玩家 A 被攻击，掉血 50
// 不管有多少个进程在处理这个逻辑，或者同时处理，下面的操作都是绝对安全的
$gameTable->incr("user_1002", 'score', -50);
// 等价于：$current_score = $gameTable->get("user_1002", 'score'); $gameTable->set("user_1002", ...);甚至更高级的用法，累加。
// 玩家 A 杀怪，获得经验值 +10
$gameTable->incr("user_1002", 'score', 10);重点：incr 方法可以传第二个参数和第三个参数，直接完成 value += delta 的操作，无需 get 再 set。这不仅减少了内存访问次数，更重要的是避免了竞态条件。
7. 深入理解：行锁机制
Swoole Table 内部其实是按“行”加锁的。
当你执行 $table->set('key', $value) 时，Swoole 会给这个 key 加一把锁。
- 如果进程 A 正在修改
user_1002的数据，进程 B 想读或者修改user_1002，进程 B 必须等待进程 A 释放锁。 - 如果进程 A 正在修改
user_1001，进程 B 修改user_1002，两者互不干扰，并发执行！
这就是为什么我们在写高并发逻辑时，推荐使用 incr 这种原子操作，而不是 get + set。因为 get -> set 之间有间隙，这个间隙里可能其他进程已经改了数据，导致覆盖。
8. 避坑指南：关于 Key 的长度
这是 Swoole Table 最让人头疼的地方。Key 必须是字符串，而且长度不能超过 Table 的大小（字节数）。
很多人会觉得困惑：“我定义了 10MB 的 Table，为什么我存一个 Key 叫 username123 就报错 Table memory is not enough？”
因为 Swoole Table 计算大小是基于字节长度的，不是字符串长度（字符数）。
strlen('username123') 等于 13 字节。13 字节看起来很小，但如果你有 1000 万个用户，每个 Key 平均 30 字节，总内存消耗就是 300MB。再加上 Value 的数据，10MB 的 Table 根本不够用。
所以，请务必使用有意义的、短小的 Key。
不要用 $_POST['username'] 作为 Key，那太长了。
要使用：uid, order_id, ip_hash。
如果你非要存用户名，请用 md5($username)，哪怕是 MD5 也要比长字符串省内存。
9. 复杂结构体与 JSON
有时候，我们不想在定义 Table 的时候把所有字段都列出来。比如，我们想存一个用户的装备列表。这个列表是动态的，而且很大（比如 2KB）。
Swoole Table 支持存字符串。我们可以把数据序列化成 JSON 存进去。
$complexTable = new SwooleTable(1024 * 1024 * 10);
$complexTable->column('data', SwooleTable::TYPE_STRING, 1024 * 10); // 10KB 的空间
$complexTable->create();
$equipment = [
'sword' => 'fire_sword',
'armor' => 'dragon_suit',
'potion' => 999
];
// 存入
$complexTable->set('player_1', [
'data' => json_encode($equipment)
]);
// 读取并解析
$jsonStr = $complexTable->get('player_1', 'data');
$equipment = json_decode($jsonStr, true);但是！ 这里有性能损耗。JSON 的 encode/decode 是非常慢的 CPU 操作。如果你追求极致性能（比如每秒百万级操作），请尽量避免把大对象存进 Table，或者只存引用 ID，去别的地方查详情。
Swoole Table 的强项是：存的是“热数据”。比如：在线状态、计分板、排队队列。
10. 进阶：分布式一致性
虽然 Swoole Table 解决了单机多进程的同步问题，但它解决不了多台服务器之间的同步问题。
如果你部署了 3 台服务器，每台服务器都有自己的 Swoole Table，服务器 A 里的进程 B 给用户加了一分，服务器 C 里的进程 B 是不知道的。
这就好比有三个人，手里各有一块手表。
- 本地同步：手表之间是同步的（Swoole Table）。
- 全局同步：三个人要确认现在几点，还是得看天上的太阳，或者打电话确认（Redis / MySQL）。
如果你非要实现跨服务器的状态同步，最经典的架构是：
- 本地 Table：存极热数据，供本机快速读写。
- 异步更新：每当你修改 Table 里的数据时，同时发一个 HTTP 请求（或消息队列）给 Redis/MySQL。
- 定时/触发回刷：每隔一段时间，或者当需要查询全局数据时，从 Redis/MySQL 把数据拉回到本地 Table，覆盖本地缓存。
11. 完整代码示例：一个简单的“抢红包”服务
来，我们来写一个能跑的抢红包程序。
逻辑：
- 用户 ID：1001 – 1005。
- 每个 Worker 进程都维护一个 Table，存着每个用户的剩余金额。
- Worker 进程模拟发送请求，给用户发钱。
<?php
// server.php
$server = new SwooleServer("0.0.0.0", 9501);
// 1. 初始化 Table
// 我们假设只有 5 个用户，但为了演示，我们设置大一点
$table = new SwooleTable(1024 * 1024); // 1MB
$table->column('remain', SwooleTable::TYPE_INT, 10); // 剩余金额
$table->column('has_taken', SwooleTable::TYPE_INT, 10); // 已领取人数
$table->create();
// 初始化数据：每个用户 100 块钱
for ($i = 1001; $i <= 1005; $i++) {
$table->set("user_{$i}", [
'remain' => 100,
'has_taken' => 0
]);
}
// 2. 监听连接
$server->on('Connect', function ($server, $fd) {
echo "Client #{$fd} connected.n";
});
// 3. 监听数据接收
$server->on('Receive', function ($server, $fd, $fromId, $data) use ($table) {
$user_id = (int)$data;
echo "Client #{$fd} wants to grab for user {$user_id}.n";
// 模拟抢红包逻辑
// 注意：这里使用了原子递增，非常安全！
$current_remain = $table->incr("user_{$user_id}", 'remain', -1);
$current_taken = $table->incr("user_{$user_id}", 'has_taken', 1);
if ($current_remain >= 0) {
$server->send($fd, "Success! User {$user_id} has taken {$current_taken} red packets. Remain: {$current_remain}.n");
} else {
// 回滚操作（如果扣减失败，这里可以简单处理，或者利用负数回滚）
// 在 Swoole Table 中，如果减到负数，通常需要特殊处理逻辑
// 为了演示简单，我们这里只报错
$server->send($fd, "Error: No more packets for user {$user_id}!n");
// 注意：真实场景可能需要 $table->decr ... 来回滚，或者使用事务逻辑
}
});
// 4. 启动服务
$server->start();在这个例子中，不管有多少客户端连接，也不管哪个 Worker 进程处理了请求，大家共享的是同一个 remain。这就是并发安全。
12. 持久化：防止数据像雾一样消失
共享内存有个致命弱点：重启进程，数据清零。
这就好比你们共享的公共冰箱，老板觉得太乱，直接把冰箱里的东西全倒垃圾桶了，然后明天再买新的。
为了解决这个问题，Swoole Table 提供了 save 和 load 方法。
// 崩溃前保存
$table->save('/tmp/game_data.table');
// 启动时加载
$table->load('/tmp/game_data.table');这会把内存中的数据序列化保存到硬盘上。但这会增加 I/O 开销。所以，通常的做法是：
- 高频修改的数据（如当前血量、金币）：存在内存，不保存。
- 低频修改/关键数据（如用户等级、未读消息数）：存在内存，并配合
save定时保存（比如每 60 秒）。
13. 性能测试与调优
最后，聊聊性能。
- 吞吐量：Swoole Table 的写入速度通常能达到几十万 QPS，取决于 CPU 核数。这比 Redis 的网络延迟要低几个数量级。
- 内存碎片：虽然哈希表是高效的，但如果你频繁
del（删除）很多 Key，会导致内存碎片。Swoole 在 4.5+ 版本中优化了内存管理，但尽量避免频繁的大规模删除操作。 - Hash 碰撞：如果 Key 太长且碰撞率太高，性能会下降。尽量保证 Key 的哈希分布均匀。
14. 总结
Swoole Table 是 PHP 开发者通往高性能领域的入场券。它让你告别了“为了读一个变量而去发个网络请求”的繁琐。
记住：
- 它是共享内存，速度极快。
- 它是进程级的，多个 Worker 共用。
- 它是有锁的，但是行锁，并发友好。
- 它不适合存超大数据，适合存热数据。
- Key 长度是内存杀手，请务必短小精悍。
好了，今天的讲座就到这里。如果你觉得这篇文章让你明白了如何让 PHP 进程“心连心”，请在评论区点赞。下次咱们聊聊 Swoole 的协程，那才是真正的“会呼吸的代码”。
（拍手下台）