本文探讨了在php与mysql应用中，多并发请求导致数据库出现竞态条件，造成多个默认卡片的问题。我们将分析问题根源，并重点介绍如何利用数据库事务确保数据更新的原子性与一致性，从而有效避免此类数据不一致性。文章还将提及其他并发控制策略，以提供全面的解决方案。
在现代Web应用中，处理用户并发请求是常见的场景。然而，如果不加以适当的并发控制，这些并发请求可能导致数据不一致，即所谓的“竞态条件”（Race Condition）。一个典型的例子是，在一个用户拥有多张卡片，且其中一张必须被设为默认卡片的系统中，当用户同时发起多个请求来更改默认卡片时，可能最终导致出现多张默认卡片，这显然违背了业务逻辑。
假设我们有一个cards表，其中包含id、user_id和is_default字段。is_default字段为布尔值，表示该卡片是否为默认卡片。业务规则规定，每个用户只能有一张默认卡片。
以下是初始表结构示例：
| id | user_id | is_default |
|---|---|---|
| 1 | 50 | 0 |
| 2 | 50 | 1 |
当用户ID为50的用户同时发起两个请求，分别将卡片1和卡片2设为默认时，问题便会浮现：
立即学习“PHP免费学习笔记（深入）”；
在没有并发控制的情况下，后端代码可能如下所示：
use App\Models\Card;
use Illuminate\Http\Request;
public function setAsDefault(Request $request, $id)
{
// 步骤1: 将该用户所有卡片设为非默认
Card::where('user_id', $request->user()->id)->update(['is_default' => false]);
// 步骤2: 将指定卡片设为默认
Card::where([
'id' => $id,
'user_id' => $request->user()->id
])->update(['is_default' => true]);
return ['status' => true];
}当两个请求几乎同时执行时，可能发生以下时序：
最终结果是卡片1和卡片2都被设为默认，导致数据不一致：
| id | user_id | is_default |
|---|---|---|
| 1 | 50 | 1 |
| 2 | 50 | 1 |
问题在于，这两步数据库操作（先清空所有默认，再设置新的默认）并非原子性的。在多个请求并发执行时，它们会交错进行，从而破坏了操作的完整性。
解决这类竞态条件最有效且常用的方法是使用数据库事务（Transactions）。事务确保一组数据库操作要么全部成功提交，要么全部失败回滚，从而保证了操作的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），即ACID特性。
在Laravel框架中，我们可以很方便地使用DB::transaction方法来定义事务块。将上述两步更新操作包裹在一个事务中，可以确保它们作为一个单一的、不可分割的逻辑单元执行。
use App\Models\Card;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\DB; // 引入DB门面
public function setAsDefault(Request $request, $id)
{
try {
DB::transaction(function() use ($request, $id) {
// 步骤1: 将该用户所有卡片设为非默认
Card::where('user_id', $request->user()->id)
->update(['is_default' => false]);
// 步骤2: 将指定卡片设为默认
Card::where([
'id' => $id,
'user_id' => $request->user()->id
])->update(['is_default' => true]);
});
return ['status' => true];
} catch (\Exception $e) {
// 事务失败，回滚
// 记录错误或返回失败信息
return ['status' => false, 'message' => $e->getMessage()];
}
}工作原理：
当第一个请求进入事务块时，它会锁定相关的资源（或在某些隔离级别下，通过其他机制保证隔离）。在事务提交之前，其他并发请求将无法看到或修改该事务正在操作的数据，或者它们会被阻塞，直到第一个事务完成。这样，无论多少个请求同时尝试设置默认卡片，数据库系统都会确保这些操作串行化地执行，从而避免了中间状态的暴露和数据不一致。
例如，如果请求A先进入事务并开始执行，请求B在几乎同时到达时，它会等待请求A的事务完成。一旦请求A的事务提交，卡片1被设为默认，而所有其他卡片（包括卡片2）都被设为非默认。此时，请求B的事务开始执行，它会首先将所有卡片（包括卡片1）设为非默认，然后再将卡片2设为默认。最终，只有卡片2是默认卡片，保证了数据的一致性。
除了数据库事务，还有其他一些方法可以在特定场景下辅助解决并发问题，但它们通常不能完全替代事务在数据一致性方面的作用。
悲观锁（Pessimistic Locking） 悲观锁是一种在读取数据时就加锁的策略，防止其他事务修改或读取相同数据，直到当前事务完成。在某些复杂的业务逻辑中，如果需要先查询数据再进行更新，并且希望在查询阶段就阻止其他事务修改，悲观锁会很有用。
例如，在Laravel中，可以使用sharedLock()（共享锁，允许其他事务读取但不能写入）或lockForUpdate()（排他锁，阻止其他事务读取和写入）方法：
DB::transaction(function () use ($request, $id) {
// 获取当前用户的所有卡片并加排他锁
// 这会阻塞其他尝试修改这些卡片的事务
$cards = Card::where('user_id', $request->user()->id)
->lockForUpdate()
->get();
foreach ($cards as $card) {
$card->is_default = false;
$card->save();
}
$targetCard = Card::find($id);
if ($targetCard && $targetCard->user_id == $request->user()->id) {
$targetCard->is_default = true;
$targetCard->save();
}
});这种方式在某些情况下比直接的update操作更细粒度，但也会增加数据库的锁竞争，可能影响并发性能。对于本例中的简单update操作，数据库事务本身通常已足够，因为UPDATE语句在执行时，数据库自身会处理必要的行锁。
速率限制（Rate Limiting） 速率限制是一种在应用层限制用户或IP地址在特定时间段内发起请求数量的策略。它不能直接解决数据库层面的竞态条件，但可以从源头减少并发请求的数量，从而降低竞态条件发生的概率。
在Laravel中，可以通过路由中间件轻松实现速率限制：
// 在 routes/api.php 中
Route::middleware('throttle:60,1')->group(function () {
Route::patch('/cards/{id}/default', [CardController::class, 'setAsDefault']);
});这表示该路由每分钟最多允许60个请求。虽然速率限制有助于防止滥用和减轻服务器压力，但它并不能保证数据的一致性，如果两个请求在允许的速率限制内几乎同时到达，竞态条件仍然可能发生。因此，速率限制应作为辅助手段，与数据库事务结合使用。
处理多并发更新中的竞态条件是构建健壮应用的关键。对于涉及多个相互依赖的数据库操作，并且需要确保这些操作要么全部成功、要么全部失败的场景，数据库事务是首选且最可靠的解决方案。
核心要点：
通过恰当地应用数据库事务，我们可以有效地防止因并发操作导致的数据不一致问题，确保应用程序的数据完整性和可靠性。
以上就是PHP与MySQL多并发更新中的竞态条件：解决默认卡片设置问题的详细内容，更多请关注php中文网其它相关文章！
PHP怎么学习？PHP怎么入门？PHP在哪学？PHP怎么学才快？不用担心，这里为大家提供了PHP速学教程(入门到精通)，有需要的小伙伴保存下载就能学习啦！
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
152
收藏
