3. 任务队列核心模型：生产者-消费者模型、任务序列化与反序列化、任务唯一ID生成

异步任务队列的本质是解耦任务的提交与执行。本章围绕三个核心支柱展开：生产者-消费者模型定义了任务流转的架构；序列化与反序列化决定了任务数据如何在网络与存储中存活；唯一ID生成则保证了每个任务的可追踪性与幂等性。这三者共同构成了RedisDB异步任务领域的基础边界。

3.1 生产者-消费者模型

在RedisDB中，生产者-消费者模型通过List或Stream数据结构实现。生产者将任务推入队列，消费者从队列中取出并执行。该模型的核心优势在于：生产速率与消费速率可以独立调节，系统通过队列长度实现背压（Backpressure）感知。

3.1.1 模型角色与职责

3.1.2 基于Redis Stream的生产-消费流程

Redis Stream相比List提供了更丰富的消费者组、消息确认和回溯能力，是生产级任务队列的首选。以下是一个典型的生产-消费流程：

// 生产者：添加任务到Stream
XADD task_queue * task_type "data_sync" payload "{...}" priority 5

// 消费者组：创建消费者组（仅首次）
XGROUP CREATE task_queue data_workers $ MKSTREAM

// 消费者：读取未确认的任务
XREADGROUP GROUP data_workers worker_1 COUNT 1 BLOCK 5000 STREAMS task_queue >

// 消费者：处理完成后确认
XACK task_queue data_workers 1700000000000-0

3.2 任务序列化与反序列化

任务在生产者内存中是一个对象，在Redis中是一段字节流，在消费者内存中再次变回对象。序列化与反序列化决定了这个转换过程的效率、兼容性和安全性。

3.2.1 序列化格式对比

3.2.2 任务序列化结构设计

一个标准化的任务序列化结构应包含元数据与负载两部分：

{
  "task_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "type": "data_sync",
  "version": 1,
  "created_at": 1700000000000,
  "retry_count": 0,
  "max_retries": 3,
  "timeout_ms": 30000,
  "payload": {
    "source_db": "mysql-01",
    "target_db": "redis-02",
    "table": "users",
    "sync_mode": "incremental"
  }
}

3.3 任务唯一ID生成

每个任务必须拥有全局唯一的ID，用于去重、追踪、日志关联和幂等性保证。ID生成策略需要在性能、有序性和分布式友好之间取得平衡。

3.3.1 常见ID生成方案对比

3.3.2 推荐方案：基于Snowflake的任务ID

Snowflake算法生成64位整数ID，结构如下：

| 1 bit 符号位 | 41 bit 时间戳 | 10 bit 工作机器ID | 12 bit 序列号 |
|--------------|---------------|-------------------|---------------|
| 0            | 1700000000000 | 101               | 1             |

在RedisDB任务队列中，我们推荐使用ULID作为任务ID，因为它兼具时间有序性和随机性，且无需依赖任何外部服务：

// ULID示例：01ARZ3NDEKTSV4RRFFQ69G5FAV
// 前10字符：时间戳（毫秒级，Crockford Base32编码）
// 后16字符：随机数

// Python生成示例
import ulid
task_id = str(ulid.new())  # "01ARZ3NDEKTSV4RRFFQ69G5FAV"

3.4 三者协同：任务完整生命周期

生产者-消费者模型、序列化与唯一ID在任务队列中协同工作，形成一个完整的任务生命周期：

1. 生成ID：生产者调用ULID生成器创建task_id。
2. 序列化：将任务对象（含ID、类型、负载）序列化为JSON或MessagePack字节流。
3. 入队：通过XADD将序列化后的任务推入Redis Stream。
4. 消费：消费者通过XREADGROUP拉取任务，反序列化为内存对象。
5. 执行与确认：执行任务逻辑，成功后调用XACK确认；失败则根据retry_count决定重试或转入死信队列。
6. 幂等保证：消费者根据task_id记录已处理任务，确保同一任务不会被重复执行。