并发请求冲突在后端系统中几乎无法回避。以电商库存扣减为例，用户点击下单按钮后，服务端需要读取当前库存、判断是否充足、然后执行扣减更新。如果两个请求同时到达，它们可能都读到了库存为 10，并都判断可以扣减，随后各自写入 9，最终库存只减少 1，却卖出了两件商品。问题不在于业务逻辑写错，而在于“读-判断-写”这三步不是一个原子操作，多个执行流可以交错进入临界区。
要解决这类问题，常见手段包括请求队列和锁机制。请求队列通过将并发操作排队，强制请求一个一个处理；锁机制则通过互斥标记阻止多个请求同时修改共享数据。两者并非替代关系，很多时候需要配合使用。下面从根源、实现方式到组合方案展开说明。
一、并发请求冲突的根源与典型表现
并发冲突的根源在于共享资源的非原子修改。所谓原子性，是指一组操作要么全部完成，要么全部不执行，中间状态对外不可见。当两个请求同时读取相同的数据，并基于旧值做出修改，后提交的请求会覆盖先提交的结果，这种现象称为丢失更新。除了丢失更新，常见的并发问题还包括脏读、不可重复读和幻读，不过在业务层面最直观的表现是超卖、重复扣款和数据错乱。
下面是一段没有并发控制的库存扣减伪代码：
def deduct_stock(product_id, quantity):
# 读取当前库存
stock = db.query("SELECT stock FROM products WHERE id = ?", product_id)
# 判断库存是否充足
if stock >= quantity:
# 扣减库存
db.execute("UPDATE products SET stock = stock - ? WHERE id = ?", quantity, product_id)
return True
return False
这段代码在单线程下没有问题，但如果两个线程同时执行，它们可能都通过了判断。假设初始库存为 10，两个请求都购买 1 件。请求 A 读到 stock=10，请求 B 也读到 stock=10；A 更新 stock=9，B 更新 stock=9，结果库存仅减少 1 件，但系统记录了两笔成功订单。这就是典型的竞态条件。
类似的问题还出现在账户转账、优惠券领取、活动报名等场景。并非所有并发都需要加锁，例如只读接口、日志写入等可以在无锁环境下运行。但对于修改共享资源的接口，必须通过某种机制保证数据一致性。
二、请求队列如何将并发操作串行化
请求队列的思路比较直接：不让所有请求同时进入处理逻辑，而是先把它们放入一个队列，由消费者按顺序取出并执行。这样原本并行的请求被强制转换为串行操作，对共享资源的修改自然有了先后顺序，也就避免了竞态条件。队列可以基于进程内数据结构实现，比如 Python 的 queue 模块、Java 的 BlockingQueue；也可以基于 Redis 列表或消息中间件，比如 RabbitMQ、Kafka。
以 Redis 列表为例，生产者将请求参数 LPUSH 到队列，消费者用 BRPOP 阻塞获取并逐个处理。这种方式的优点是实现简单，峰值流量被队列缓冲后，后端处理压力变得平滑。但队列并非银弹，它会引入额外的延迟，并且如果消费者处理速度跟不上生产速度，队列长度会不断增长，最终可能导致消息积压甚至内存耗尽。因此，请求队列通常用于短时间的高并发写入场景，例如秒杀请求排队、日志异步落盘。
下面是一个使用 Redis 列表做请求排队的简化示例：
import redis
import json
r = redis.Redis(host='127.0.0.1', port=6379)
def enqueue_order(order):
# 将订单请求推入队列
r.lpush('order_queue', json.dumps(order))
def worker():
while True:
# 阻塞式弹出，超时设为 5 秒
item = r.brpop('order_queue', timeout=5)
if item is None:
continue
order = json.loads(item[1])
# 串行处理订单，执行库存扣减等操作
process_order(order)
上面的 worker 是单消费者，如果处理逻辑耗时较长，队列会越来越长。可以启动多个消费者并行消费，但需要注意并行消费又可能引入并发冲突。因此，多消费者场景下通常需要配合锁机制或分片队列，让同一个资源 ID 的请求始终落到同一个消费者上，既提高吞吐又避免竞争。
三、锁机制的类型与实现细节
锁机制的核心是互斥，同一时刻只允许一个执行流进入临界区。根据加锁的层次和策略，可以分为数据库锁、进程内锁和分布式锁。数据库锁又分为悲观锁和乐观锁。悲观锁假设冲突一定会发生，读取数据时就加锁，例如 SELECT ... FOR UPDATE；乐观锁假设冲突概率低，更新时校验版本号或时间戳，失败则重试。
悲观锁的优点是实现直观、一致性强，缺点是持有锁期间会阻塞其他事务，容易造成锁等待甚至死锁。乐观锁不会阻塞读取，但需要业务层处理更新失败的重试，适合并发冲突不高的场景。下面是一段乐观锁的 SQL 示例，通过版本号保证只有一个请求能成功更新库存：
UPDATE products SET stock = stock - 1, version = version + 1 WHERE id = 1001 AND stock >= 1 AND version = 5;
这条语句执行后，如果受影响行数为 0，说明版本号已经变化，需要重新读取并重试。乐观锁的优势在于不会长时间占用数据库锁，但对热点数据频繁重试会浪费 CPU 和数据库连接。悲观锁更适合强一致性和冲突频繁的场景，比如账户余额转账。
在分布式系统中，多个服务实例可能同时操作同一个资源，单机锁无法生效，这时需要分布式锁。常见的实现基于 Redis，利用 SET 命令的 NX 和 PX 参数实现原子加锁，并通过 Lua 脚本保证解锁的原子性。下面是一个 Redis 分布式锁示例：
import redis
import uuid
import time
r = redis.Redis(host='127.0.0.1', port=6379)
def acquire_lock(lock_name, expire_seconds=10):
token = uuid.uuid4().hex
# NX 表示不存在才设置，PX 设置过期时间
result = r.set(lock_name, token, nx=True, px=expire_seconds * 1000)
if result:
return token
return None
def release_lock(lock_name, token):
# 使用 Lua 脚本保证判断和删除是原子操作
lua = """
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
end
"""
r.eval(lua, 1, lock_name, token)
使用分布式锁时，必须给锁设置过期时间，防止进程崩溃后锁永远无法释放。解锁时要校验 token，避免误删其他请求的锁。Redis 官方推荐的 Redlock 算法进一步提高了可用性，但也会带来额外的复杂度和延迟。实际项目中，如果对一致性要求极高，可以考虑 ZooKeeper 或 etcd 的分布式锁，它们的强一致性和临时节点机制能有效避免锁丢失问题。
四、队列与锁的组合方案及避坑指南
请求队列和锁机制并不冲突，甚至可以组合使用。一种常见做法是：请求先进入队列，由消费者取出后获取分布式锁，再执行核心业务逻辑。队列负责削峰和串行化，锁负责保证分布式环境下的互斥。这样可以避免请求直接竞争锁导致的大量等待，同时利用队列缓冲高峰流量。另一种做法是按资源 ID 做分片队列，每个分片由固定的消费者处理，这样在消费者内部无需加锁即可保证顺序。
但在组合使用时要特别注意几个问题。第一是幂等性，队列消费和锁重试都可能造成重复执行，接口必须支持幂等，例如通过唯一请求号或数据库唯一约束去重。第二是锁粒度，不要锁住整个接口，尽量只锁住需要保护的资源，例如以用户 ID 或订单 ID 作为锁的名称，而不是一个全局锁。第三是锁超时和业务执行时长的关系，如果业务处理时间超过锁的过期时间，锁会自动释放，其他请求可能进入临界区，造成并发冲突。此时可以使用看门狗机制自动续期，或者将锁的过期时间设置为业务执行时间的上限。
还有一个容易忽视的问题是死锁。如果多个请求同时获取多个锁，但获取顺序不一致，就可能互相等待。避免死锁的方法是规定所有请求必须按相同顺序加锁，或者使用带超时的锁获取方式，获取不到立即释放已持有的锁并重试。对于请求队列，如果消费者在处理过程中发生异常导致消息丢失，队列也可能成为数据丢失的源头。因此，消息中间件需要开启手动确认机制，只有业务处理成功后才确认消费，否则重新入队。
总的来说，解决并发请求冲突没有一招通吃的方案。请求队列适合削峰填谷、降低数据库压力；锁机制适合保证修改操作的原子性和互斥性。实际开发中，应结合并发量、一致性要求和系统架构，选择队列、锁或两者组合的策略，并做好幂等、超时和死锁防护，才能构建稳定可靠的后端服务。