go - NSQ 重新队列半消息

Question

我有一个类型为 int64 的 Ids 数组，这是我要发布的 Nsq 消息。

nsqMsg := st{
    Action  :     "insert",
    Ids     :     Ids
    GID     :     Gids
}

msg, err := json.Marshal(nsqMsg)
if err != nil {
    log.Println(err)
    return err
}
err = nsqProducer.Publish(TOPIC-NAME, msg)
if err != nil {
    log.Println(err)
    return err
}

在我的消费者中，我一个一个地获取每个 ID，并根据我的 ID 从我的数据存储中获取信息。

因此，在获取时可能会出现我的 CreateObject 方法返回错误的情况，因此我通过重新排队消息(给出错误)来处理这种情况，因此可以重试。

for i := 0; i < len(data.Ids); i++ {

    Object, err := X.CreateObject(data.Ids[i)
        if err != nil {
            requeueMsgData = append(requeueMsgData, data.Ids[i])
            continue
        }
        DataList = append(DataList, Object)
    }

    if len(requeueMsgData) > 0 {
        msg, err := json.Marshal(requeueMsgData)
        if err != nil {
            log.Println(err)
            return err
        }
        message.Body = msg
        message.Requeue(60 * time.Second)
        log.Println("error while creating Object", err)
        return n
}

那么，这是正确的做法吗？他们在这种情况下有什么缺点吗？是不是再发一次比较好？

Answer 1

一些队列(如 Kafka)支持确认，其中出队的项目不会从队列中删除，直到消费者实际确认成功收到该项目。

这种模式的好处是，如果消费者在消费之后但在确认之前死亡，该元素将自动重新排队。您的模型的缺点是在这种情况下元素可能会丢失。

确认模型的风险在于元素现在可能会被双重消耗。消费者尝试消费有副作用(如增加计数器或改变数据库)但不承认，因此重试可能不会产生预期的结果。 (请注意，通读 nsq 文档，即使您不重新排队数据也不能保证重试，因此无论如何您的代码都可能不得不对此进行防御)。

如果您想更深入地了解这一点，您应该研究“恰好一次”与“最多一次”处理的主题。

通读 nsq 文档，似乎不支持确认，因此如果您必须使用 nsq，这可能是您的最佳选择。