基于Redis实现微服务间预订任务结果收发的方案咨询

核心痛点梳理 #

用Redis List做任务队列时，控制台服务无法主动获取预订结果，只能依赖低效轮询，且缺乏可靠的消息追溯机制。

不推荐Pub/Sub的原因 #

Pub/Sub是无持久化的广播模式，完全不匹配你的业务场景：

• 控制台服务若临时离线，结果消息会直接丢失，无法找回；
• 无消息确认和消费进度追踪，异常场景下无法确认结果是否已处理；
• 消息是一次性的，无法回溯历史结果用于问题排查。

推荐Redis Stream方案 #

Stream是Redis专为消息队列/事件流设计的特性，完美适配你的需求，具体实现流程如下：

1. 任务下发（控制台服务） #

向名为hotel_booking_tasks的Stream写入任务消息，每个消息必须携带唯一request_id（用于关联请求与结果），示例命令：

XADD hotel_booking_tasks * request_id "req_12345" user_id "u_67890" hotel_id "h_101" check_in "2024-05-20" check_out "2024-05-22" room_type "double"

*表示让Redis自动生成唯一消息ID，也可自定义，但推荐用Redis生成的ID保证全局唯一性。

2. 任务处理（预订服务） #

预订服务作为消费组的消费者，从Stream读取并处理任务：

• 先创建消费组（仅需执行一次）：

  XGROUP CREATE hotel_booking_tasks booking_group $ MKSTREAM
  

  $表示从最新消息开始消费，MKSTREAM表示若Stream不存在则自动创建。
• 消费任务：

  XREADGROUP GROUP booking_group consumer_1 COUNT 1 BLOCK 0 STREAMS hotel_booking_tasks >
  

  >表示读取消费组中未被消费的消息，BLOCK 0表示阻塞等待新消息。
• 处理完成后，写入结果到结果Stream，并确认任务消息（避免重复消费）：
  写入结果到hotel_booking_results：

  XADD hotel_booking_results * request_id "req_12345" status "success" message "预订成功，订单号：order_777"
  

  确认任务消息：

  XACK hotel_booking_tasks booking_group "1620000000000-0"
  

  其中1620000000000-0是任务消息的ID。

3. 获取结果（控制台服务） #

控制台服务有两种可靠的结果获取方式：

• 阻塞等待模式：发送任务后，直接阻塞读取结果Stream中对应request_id的消息，示例：

  XREAD BLOCK 30000 STREAMS hotel_booking_results 0
  

  客户端拿到消息后，过滤出与自身请求request_id匹配的结果，拿到后返回给用户；若超过30秒（30000毫秒）未获取结果，可返回超时提示，后续支持用户主动查询。
• 主动查询模式：若为异步场景，控制台服务记录request_id并提供查询接口，通过XRANGE或XREVRANGE从结果Stream中检索对应消息：

  XRANGE hotel_booking_results - + MATCH request_id=req_12345
  

Stream方案的核心优势 #

• 持久化：所有消息存储在Redis中，即使服务重启，也能找回未处理任务和历史结果；
• 消费组机制：支持多个预订服务实例同时消费，避免重复处理任务，还能追踪每个消费者的消费进度；
• 消息确认：仅调用XACK后，消息才会被标记为已消费，防止异常场景下的重复处理；
• 可追溯性：随时可查询历史任务和结果，方便问题排查。

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