使用Redis实现Node.js中并发受限的资源访问队列

本文探讨了在Node.js应用中高效管理并发受限且具有时间限制的资源访问问题。针对传统内存队列在处理长时资源占用时面临的阻塞和HTTP超时挑战，文章提出并详细阐述了基于Redis的“即发即忘”与轮询策略。该方案通过Redis集中管理资源持有者和等待队列，有效解耦了请求与资源分配，提升了系统可伸缩性与用户体验，是解决此类复杂并发控制场景的专业级实践。

Node.js中并发受限资源访问的挑战

在构建Node.js应用程序时，经常会遇到需要管理对有限资源的并发访问场景。特别是在资源具有以下特性时，传统的内存队列或简单的并发库可能会面临挑战：

1. 独占性： 资源在某一时刻只能被一个用户或进程持有。
2. 时间限制： 资源被持有后，会在一定时间后自动释放，或可被手动释放。
3. 异构资源并发： 系统中存在多种类型的资源，不同类型的资源可以独立分配，互不影响，但同类型资源仍需排队。
4. 长时持有： 资源持有时间可能较长（例如60秒），如果将此等待时间直接绑定到HTTP请求-响应周期，将导致连接长时间阻塞，影响系统吞吐量和用户体验，甚至触发HTTP超时。

例如，一个应用允许用户请求“标题A”或“标题B”两种虚拟资源。每个标题一次只能被一个用户持有60秒。如果用户1请求标题A，用户2请求标题A，用户3请求标题B，理想的分配顺序应是用户1获得A，用户3立即获得B，用户2则等待用户1释放A。然而，若采用基于p-queue等库的内存队列方案，通常会出现全局阻塞，即使用户3请求的是不同标题，也可能需要等待用户1的60秒持有期结束，这违背了异构资源并发的初衷。

基于Redis的解耦式资源管理策略

为有效解决上述问题，一种更专业且具伸缩性的方法是采用基于Redis的“即发即忘”（Fire-and-Forget）与轮询（Polling）策略。该方案将资源分配和状态管理从即时请求-响应循环中彻底解耦，利用Redis的高性能和持久化特性来集中维护资源锁和等待队列。

核心思想

1. 解耦请求与持有： 当用户请求资源时，Node.js服务器立即响应请求已成功接收，不等待资源实际分配。
2. Redis作为状态中心： 使用Redis作为唯一的、可靠的状态存储，管理哪个用户当前持有哪个资源，以及哪些用户正在等待特定资源。
3. 客户端轮询机制： 用户客户端在请求发出后，通过定期轮询服务器来查询其资源请求的最新状态。

架构概览

• 客户端 (Client): 用户界面，负责发起资源请求和周期性地向服务器轮询资源状态。
• Node.js 服务端 (Node.js Server): 接收客户端请求和轮询请求，其主要职责是与Redis交互，更新和查询资源状态，并向客户端返回相应信息。
• Redis 数据库 (Redis Database): 存储核心业务逻辑所需的状态数据，包括：
  • 资源持有者信息： 记录哪个用户当前持有哪个标题，并设置过期时间。
  • 等待队列： 维护每个标题的等待用户队列，确保公平分配。

关键组件与实现细节

1. 资源持有者管理

对于每个可独占的资源（例如“标题A”），在Redis中创建一个键来存储当前持有该资源的用户ID，并为其设置一个过期时间（TTL）。

AISEO

AI创作对SEO友好的文案和文章

56

查看详情

• Redis键名示例: resource:{resource_type}:current_holder (如 title:A:current_holder)
• Redis值示例: user_id_X
• 过期时间: 60 秒（通过SETEX命令或SET key value EX seconds实现）

当此键过期时，即表示资源已被自动释放。

2. 等待队列

为每种资源类型维护一个Redis列表（List），作为该资源的等待队列。列表中的元素是等待该资源的用户ID。

• Redis键名示例: resource:{resource_type}:waiting_queue (如 title:A:waiting_queue)
• 入队操作: 当用户请求资源时，将其ID添加到列表的末尾 (RPUSH)。
• 出队操作: 当资源可用时，从列表的头部取出下一个用户ID (LPOP)。

3. 请求处理流程 (Fire-and-Forget)

当用户首次请求一个标题（例如通过HTTP POST请求）时：

1. Node.js服务器接收到请求。
2. 将请求用户ID添加到对应标题的Redis等待队列中（RPUSH title:A:waiting_queue user_id_Y）。
3. 立即向客户端

以上就是使用Redis实现Node.js中并发受限的资源访问队列的详细内容，更多请关注php中文网其它相关文章！