如何在Asynq中高效传递客户端依赖？

我完全理解你的困惑——Asynq的文档确实在任务内部依赖传递这块讲得不够具体，刚上手的时候很容易卡壳，尤其是你已经习惯了用依赖注入（DI）在GraphQL resolver里传递数据库、Redis这类客户端的情况下。

结合你的场景，我推荐几种实用的方案，都是Go生态里比较常用的依赖传递方式，和你现有代码的风格也能保持一致：

方案一：自定义Worker结构体注入依赖（最推荐） #

这是最符合Go依赖注入习惯的方式，本质是把你的客户端依赖封装到一个Worker结构体里，然后让任务处理器作为该结构体的方法，这样就能直接在方法里访问依赖了。

具体步骤： #

1. 定义一个包含你的客户端依赖的Worker结构体：

// 假设你的services.Clients已经定义了Db、Redis等字段
type TaskWorker struct {
    Clients *services.Clients
    // 还可以加其他你需要的服务依赖
}

2. 给Worker结构体编写任务处理器方法，方法签名要符合Asynq的HandlerFunc要求：

func (w *TaskWorker) ProcessUserNotification(ctx context.Context, task *asynq.Task) error {
    // 直接通过w.Clients访问数据库、Redis等客户端
    userID, err := strconv.Atoi(string(task.Payload()))
    if err != nil {
        return fmt.Errorf("invalid user ID in payload: %v", err)
    }

    // 示例：用Db客户端查询用户信息
    var userEmail string
    err = w.Clients.Db.QueryRowContext(ctx, "SELECT email FROM users WHERE id = ?", userID).Scan(&userEmail)
    if err != nil {
        return fmt.Errorf("failed to fetch user: %v", err)
    }

    // 示例：用Redis客户端记录任务日志
    _, err = w.Clients.Redis.Set(ctx, fmt.Sprintf("task:notif:%d", userID), "sent", 24*time.Hour).Result()
    if err != nil {
        return fmt.Errorf("failed to log task: %v", err)
    }

    // 这里写你的任务核心逻辑
    return nil
}

3. 在main函数里初始化Worker并注册到Asynq的ServeMux：

func main() {
    // 初始化你的各种客户端（和你现有代码一致）
    dbClient, err := sql.Open("postgres", "your-dsn")
    if err != nil {
        log.Fatal(err)
    }
    defer dbClient.Close()

    redisClient := redis.NewClient(&redis.Options{Addr: "localhost:6379"})
    if err := redisClient.Ping().Err(); err != nil {
        log.Fatal(err)
    }

    clients := services.Clients{
        Db:    dbClient,
        Redis: redisClient,
        // 其他客户端...
    }

    // 初始化Worker，注入依赖
    worker := &TaskWorker{Clients: &clients}

    // 启动Asynq服务器
    asynqSrv := asynq.NewServer(
        asynq.RedisClientOpt{Addr: "localhost:6379"},
        asynq.Config{Concurrency: 10},
    )

    mux := asynq.NewServeMux()
    // 注册任务处理器：把Worker的方法绑定到对应的任务类型
    mux.HandleFunc("task:user_notification", worker.ProcessUserNotification)

    // 启动Asynq服务
    if err := asynqSrv.Run(mux); err != nil {
        log.Fatalf("Failed to start Asynq server: %v", err)
    }
}

这种方式的好处是：

• 依赖关系清晰，一眼就能看到任务需要哪些客户端
• 单元测试方便：你可以轻松构造一个带有mock客户端的Worker实例来测试任务逻辑
• 和你现有GraphQL resolver的DI模式完全一致，代码风格统一

方案二：用Asynq中间件注入依赖到Context #

如果你需要给多个任务处理器共享依赖，也可以通过自定义中间件把依赖注入到每个任务的Context中。不过要注意，Context更适合传递请求级别的临时值，全局依赖还是优先用方案一。

具体实现： #

1. 编写一个注入依赖的中间件：

// 定义一个类型安全的Context key，避免和其他库的key冲突
type contextKey string

const clientsKey contextKey = "clients"

func InjectClientsMiddleware(clients *services.Clients) func(next asynq.Handler) asynq.Handler {
    return func(next asynq.Handler) asynq.Handler {
        return asynq.HandlerFunc(func(ctx context.Context, task *asynq.Task) error {
            // 把依赖注入到Context
            ctx = context.WithValue(ctx, clientsKey, clients)
            // 调用下一个处理器
            return next.ProcessTask(ctx, task)
        })
    }
}

2. 在注册处理器时使用中间件，并在处理器中取出依赖：

mux := asynq.NewServeMux()
// 注册中间件
mux.Use(InjectClientsMiddleware(&clients))

// 任务处理器中取出依赖
mux.HandleFunc("task:data_sync", func(ctx context.Context, task *asynq.Task) error {
    // 类型断言取出Clients，注意要处理断言失败的情况
    clients, ok := ctx.Value(clientsKey).(*services.Clients)
    if !ok {
        return fmt.Errorf("failed to get clients from context")
    }

    // 使用clients做操作
    _, err := clients.Db.ExecContext(ctx, "UPDATE sync_log SET status = 'done' WHERE task_id = ?", task.ID())
    return err
})

方案三：全局变量（不推荐） #

虽然很多人图省事会把客户端依赖设为全局变量，但这种方式弊端很多：

• 单元测试困难，无法轻松替换为mock客户端
• 代码耦合度高，后续维护和扩展麻烦
• 如果客户端不是线程安全的，还可能引发并发问题

除非你的项目非常简单，否则不建议用这种方式。

总结一下，方案一的自定义Worker结构体注入依赖是最适合你的场景的，既符合Go的设计哲学，又能和你现有的依赖注入模式无缝衔接。

备注：内容来源于stack exchange，提问作者Laurent