NSQ 重排半消息队列

大家好，我们又见面了啊~本文《NSQ 重排半消息队列》的内容中将会涉及到等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

我有一个 ids 类型的数组，类型为 int64 这是我正在尝试发布的 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
}

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

解决方案

某些队列（如 Kafka）支持确认，在消费者实际确认成功收到该项目之前，出队的项目不会从队列中删除。

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

确认模型的风险是物品现在可能会被双重消耗。当消费者尝试进行具有副作用的消费（例如增加计数器或改变数据库）但不确认时，重试可能不会创建所需的结果。 （请注意，通读 nsq 文档，即使您不重新排队数据，也不能保证重试发生，因此您的代码可能必须对此进行防御）。

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

通读 nsq 文档，它看起来不支持确认，因此如果您有义务使用 nsq，这可能是您的最佳选择。

终于介绍完啦！小伙伴们，这篇关于《NSQ 重排半消息队列》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！