多节点请求处理：如何让后到请求等待先到请求执行完成？

嘿，这个场景我之前做电商订单和用户余额系统时经常碰到，典型的后请求依赖前请求数据库修改结果的问题，整理了几个通用的实现思路，你可以结合自己的技术栈和业务场景来选择：

1. 基于业务标识的请求队列化 #

核心思路是给有依赖关系的请求打上同一个业务标识（比如用户ID、订单ID这类唯一关联的Key），然后为每个Key维护一个独立的请求队列。

• 具体操作：当请求进来时，先根据标识找到对应的队列，如果队列里有正在执行的请求，就把当前请求加入队列等待；只有当前面的请求完全执行完成（包括数据库事务提交），才会取出队列里的下一个请求执行。
• 简单伪代码示例（Python异步场景）：

  from collections import defaultdict
  import asyncio
  
  # 为每个业务Key维护一个队列
  request_queues = defaultdict(asyncio.Queue)
  
  async def process_request(request_data, business_key):
      queue = request_queues[business_key]
      await queue.put(request_data)
      
      try:
          # 只有当当前是队列第一个请求时才启动处理循环
          if queue.qsize() == 1:
              while not queue.empty():
                  current_data = queue.get()
                  # 执行数据库修改操作（包含事务提交）
                  await execute_db_modification(current_data)
                  queue.task_done()
      finally:
          # 确保请求从队列中移除
          await queue.get()
  

• 优势：精准控制同一业务维度的请求串行，不会影响其他无关请求的并行处理，性能损耗小。

2. 数据库层面的锁机制 #

利用数据库本身的锁能力来实现请求的串行等待，适合单实例或者数据库性能足够的场景：

• 行级排他锁：比如MySQL用SELECT ... FOR UPDATE、PostgreSQL用SELECT ... FOR NO KEY UPDATE，第一个请求在修改数据前先锁定目标行，第二个请求尝试访问同一行时会被阻塞，直到第一个请求提交事务释放锁。
• 乐观锁：给数据表添加一个version字段，第一个请求修改时带上当前版本号，修改成功后版本号自增；第二个请求发起时先获取最新版本号，只有版本号匹配才执行修改，不匹配则重试或等待后再尝试。
• 注意点：行级锁要注意事务隔离级别和超时设置，避免死锁；乐观锁更适合冲突频率较低的场景，冲突高时重试成本会上升。

3. 分布式锁（多实例集群场景） #

如果你的应用是多实例集群部署，单实例的队列或者数据库锁无法跨实例生效，这时候可以用分布式锁：

• 实现思路：请求进来时，先尝试获取对应业务标识的分布式锁（比如基于Redis的Redlock、ZooKeeper的分布式锁），获取到锁的请求才能执行数据库修改；没获取到锁的请求可以选择等待重试，或者根据业务需求直接返回“请稍后操作”。
• 关键注意事项：要设置合理的锁过期时间，避免请求异常导致锁一直无法释放；同时要考虑锁的可重入性，防止同一请求重复获取锁出现问题。

4. 事件驱动的异步处理 #

把请求处理拆分为“提交请求”和“依赖触发”两个环节，通过事件通知来实现串行：

• 具体操作：第一个请求提交后，触发一个异步任务去执行数据库修改；第二个请求进来时，先检查第一个请求的异步任务是否完成，如果未完成则订阅该任务的完成事件，等事件触发后再执行自身的逻辑。
• 比如用消息队列实现：第一个请求发送消息到队列，消费端执行修改后发送完成事件；第二个请求订阅该事件，收到事件后再执行自己的请求逻辑。
• 优势：能很好地解耦请求流程，适合高并发场景下的流量削峰，避免请求堆积在应用实例中。

内容的提问来源于stack exchange，提问作者pwnchaurasia