Laravel怎么处理并发请求_Laravel在高并发下的数据库锁优化【方案】

DB::transaction() 高并发卡住主因是默认隔离级别下更新同行触发行锁且锁持续至提交，导致阻塞或死锁；应精简事务、显式加锁、原子更新、合理设超时，并按场景选悲观/乐观锁。

为什么 DB::transaction() 在高并发下会卡住甚至超时

不是事务本身慢，而是默认的数据库隔离级别（如 mysql 的 REPEATABLE READ）在更新同一行时会触发行级锁，并且锁会持续到事务提交。如果多个请求同时执行 DB::transaction() 并试图更新同一条记录（比如库存扣减），后到的请求就会被阻塞，直到前一个事务释放锁——这直接导致响应延迟甚至 IlluminatedatabaseQueryException: SQLSTATE[HY000]: General Error: 1205 Deadlock found。

实操建议：

• 避免在事务中做耗时操作（如 http 请求、文件读写、循环计算），只保留必要 DB 操作
• 把 select ... for UPDATE 放在事务最开始，且尽量缩小 WHERE 条件范围（比如用主键而非模糊查询）
• 设置合理事务超时：MySQL 可调 innodb_lock_wait_timeout（默认 50 秒），laravel 中可通过 DB::connection()->getPdo()->setAttribute(pdo::ATTR_TIMEOUT, 5) 控制连接级超时（注意这不是锁等待超时）
• 用 DB::select('SELECT * FROM products WHERE id = ? FOR UPDATE', [$id]) 显式加锁比 Product::lockForUpdate()->find($id) 更可控，后者可能因 Eloquent 的 lazy loading 触发额外查询而延长锁持有时间

用 DB::update() 原生更新代替 Model->save() 避免 N+1 锁竞争

当多个请求并发更新同一商品库存，若都走 $product = Product::find($id); $product->stock--; $product->save();，每个请求都会先 SELECT 再 UPDATE，中间有时间窗口，且 Eloquent 会加载整行再改——这不仅放大锁范围，还可能因模型事件、访问器等引入不可控延迟。

更安全的做法是原子性更新：

DB::update('UPDATE products SET stock = stock - 1 WHERE id = ? AND stock >= 1', [$id]);

这个语句自带条件检查和原子扣减，失败时返回 0 行影响，无需加锁也无竞态。适用场景：简单字段变更、带前置条件的更新（如“余额足够才扣款”）。

注意点：

• 不能触发 Eloquent 的 updating 或 updated 事件，需自行处理日志或通知
• 无法自动填充 updated_at，得显式写入：SET updated_at = NOW(), stock = stock - 1
• 若需返回影响行数做业务判断，用 DB::affectingStatement() 替代 DB::update()（后者不抛异常但也不返回值）

乐观锁方案：用 version 字段 + WHERE version = ? 实现无阻塞重试

适合读多写少、冲突概率低的场景（如文章阅读量、用户积分）。核心思路是不锁行，靠版本号检测并发修改，失败后由应用层决定是否重试。

示例结构：

Schema::table('users', function (Blueprint $table) {     $table->integer('version')->default(0); });

更新逻辑：

$user = User::where('id', $id)->first(); $affected = DB::update(     'UPDATE users SET points = points + ?, version = version + 1 WHERE id = ? AND version = ?',     [$amount, $id, $user->version] ); if ($affected === 0) {     // 版本已变，有人抢先更新了，可重试或返回错误 }

优势明显：无数据库锁、响应快、扩展性好；但要注意：

• 每次更新必须包含 version = version + 1 和 WHERE version = ? 成对出现
• 重试逻辑不能无限循环，建议加最大重试次数（如 3 次）和指数退避
• 不适用于强一致性要求极高的场景（如银行转账），此时仍需悲观锁兜底

Laravel 自带的 Cache::lock() 不适合数据库行锁场景

很多人第一反应是用 Laravel 的分布式锁（Cache::lock('stock_'.$id)->get(...)），但它解决的是「应用层协调」，不是「数据库一致性」。它能防止两个请求同时进入扣库存逻辑，但一旦锁释放、SQL 执行前发生主从延迟或缓存穿透，依然可能双写。

真正该用它的场合是：

• 防止重复提交（如支付回调幂等校验）
• 控制后台命令并发（php artisan schedule:run 多实例防重复）
• 配合数据库操作做二次保险，例如：先抢锁 → 再查库存 → 再扣减 → 最后释放锁

但别把它当成数据库锁的替代品。它不感知事务状态，也不保证 SQL 执行顺序，单纯依赖缓存服务（redis）的可靠性。

真正难的从来不是加锁，而是判断哪条数据值得锁、锁多久、谁来承担锁失败后的业务补偿。这些没法靠框架自动解决，得结合业务语义一层层压测验证。