thinkphp6稳扛万级并发需redis分布式锁+数据库事务+消息队列+swoole协程四者协同：redis锁防重复提交并自动续期，数据库事务配合行锁保障库存与分佣原子性，消息队列异步解耦支付与分佣，swoole协程提升锁与事务性能。
ThinkPHP6 处理 1 万级并发，单靠数据库行锁或文件锁远远不够，必须组合使用Redis 分布式锁 + 数据库事务 + 消息队列异步落库，三者缺一不可。核心目标不是“抢到锁就完事”，而是确保关键操作（如秒杀下单、推客关系绑定、库存扣减）在高并发下不超卖、不分佣错乱、不丢单。
Redis 分布式锁：防重复提交与抢占临界资源
TP6 自带 Cache 支持 Redis，但原生 Cache::lock() 在极端并发下存在锁续期失败、死锁残留风险。推荐手写可重入、带自动续期的 RedLock 变体：
- 使用
SET key random_value NX PX 10000命令实现原子加锁，value 用唯一请求 ID 防止误删 - 加锁成功后，启动协程/定时器每 3 秒续期一次（避免业务处理超时导致锁提前释放）
- 解锁时严格比对 value，只删自己设的锁，避免误删他人锁
示例代码（放在 app/common/Util.php）：
// 尝试获取分布式锁，超时 5 秒，自动续期
public static function tryLock(string $key, int $expire = 10, int $timeout = 5): ?string
{
$redis = Cache::store('redis')->getHandler();
$value = uniqid('', true);
$end = microtime(true) + $timeout;
while (microtime(true) if ($redis->set($key, $value, ['nx', 'px' => $expire * 1000])) {
// 启动后台续期（需配合 Swoole Task 或独立守护进程）
self::startRenewal($key, $value, $expire);
return $value;
}
usleep(10000);
}
return null;
}
// 安全解锁
public static function unlock(string $key, string $value): bool
{
$redis = Cache::store('redis')->getHandler();
$script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
return $redis->eval($script, [$key], [$value]) === 1;
}
```
数据库事务 + 行锁：保障库存与分佣原子性
Redis 锁只管“谁先来”，真正扣库存、记分佣、写订单必须落到数据库。InnoDB 行锁 + 显式事务是底线：
- 用
lock(true)强制走 SELECT ... FOR UPDATE，锁住具体商品行，而非整张表 - 所有关联操作（查库存 → 扣库存 → 写订单 → 记推客关系 → 发放佣金）必须包裹在同一个事务中
- 一旦任意一步失败，立刻 rollback，避免状态撕裂
关键伪代码：
Db::startTrans();
try {
// 1. 加锁查商品（必须带主键条件）
$goods = Goods::where('id', $goodsId)->lock(true)->findOrEmpty();
if (!$goods || $goods->stock throw new Exception('库存不足');
}
// 2. 扣库存（乐观锁 or 直接 update）
if (false === $goods->save(['stock' => $goods->stock - 1])) {
throw new Exception('库存扣减失败');
}
// 3. 创建订单、绑定推客、生成分佣记录（全部在此事务内）
Order::create([...]);
Commission::create([...]);
Db::commit();
} catch (Exception $e) {
Db::rollback();
Log::error('并发下单失败: ' . $e->getMessage());
throw $e;
}
```
消息队列兜底：解耦支付回调与分佣计算
用户支付成功后，回调接口不能同步执行复杂分佣逻辑（易超时、易失败）。必须把“确认支付”和“发佣金”彻底拆开：
- 支付回调仅做三件事：校验签名、更新订单状态为“已支付”、投递一条 MQ 消息（含 order_id）
- 消费者进程（常驻 CLI）监听队列，拿到消息后查订单、查推客关系、计算各级佣金、写入分佣表
- 失败消息进入延迟重试队列（如 1min、5min、30min），避免因 DB 临时抖动导致佣金丢失
使用 think-queue + Redis 驱动示例：
```php// 回调中投递
Queue::push('app\job\HandleCommission', ['order_id' => $orderId]);
// app/job/HandleCommission.php
class HandleCommission implements JobInterface
{
public function fire(Job $job, $data)
{
$orderId = $data['order_id'];
try {
// 查订单、算佣金、写表...
CommissionService::calcAndSave($orderId);
$job->delete(); // 成功则删除
} catch (Exception $e) {
// 失败则延迟重试（最多3次）
if ($job->attempts() $job->release(60); // 1分钟后重试
} else {
$job->delete(); // 彻底放弃，人工介入
Log::error("佣金处理失败超限: {$orderId}");
}
}
}
}
```
Swoole 协程增强：让锁和事务更轻量
纯 PHP-FPM 模式下，每个请求独占一个进程，Redis 锁和 MySQL 连接开销大。升级为 Swoole HTTP Server 后：
- 协程内共享 Redis 连接池，锁操作毫秒级完成，无 TCP 握手损耗
- MySQL 连接可复用，事务开启/提交速度提升 3 倍以上
- 配合
think-swoole扩展，无需改业务代码即可启用协程化
配置要点（swoole_http.php）：
$http = $app->make('swoole.http', [
'host' => '0.0.0.0',
'port' => 9501,
'options' => [
'worker_num' => 8,
'task_worker_num' => 4,
'max_request' => 10000,
'dispatch_mode' => 3, // 3=争抢模式，适合高并发
],
]);
```
不复杂但容易忽略：锁的粒度要细（按商品 ID，不是全局锁）、事务要短（只包真正需要原子的操作）、队列要持久化（Redis 设置 RDB+AOF）、Swoole 要配连接池。四者协同，才能稳扛万级并发。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
