NSQ(7)-nsq存在的问题

nsq存在的缺陷

  • 部署的难度

    ​ nsq提供了一种消费者端进行服务发现的模型,所以无需告诉消费者去哪寻找对于的主题(Topic)在哪个nsqd实例上。

    ​ 然而,它并没有提供一种方案去解决一个生产者应该把消息发布到哪个nsqd实例上的问题,虽然nsqd推荐一个生产者对于部署一个nsqd实例,来实现product:nsqd= 1:1 的部署方案,但是在具体生产环境下,随着服务数量的增长,这种部署方案很难去实施,所以需要一个协调器去平衡所有创建的主题(Topic),使之满足product:nsqd=n:m(n >= m),然后通知所有生产者,它们应该把消息发布到哪个nsqd实例上。

  • 消息丢失的问题

    ​ nsq 是基于内存的MQ,它把消息存在Golang 的channel中,仅仅会在消息达到该 messageChan 的最大存储数量时,才会进行持久化到磁盘的操作,或者在正常退出时进行消息的持久化,比如对 nsqd 进行重启操作时。

    ​ 然而,如果遇到程序崩溃或者不可预期的机器异常关机时,消息就会丢失。

  • 追踪消息状态困难

    ​ 由于nsq的消息是保存在内存中的,在消费之后被清空,很难去找出一个消息是否已经到达了 nsqd,另外,消费的消息状态(inflight or timeout or finished)也是完全不知道的。

  • 无法消费历史消息

    ​ 在某些情况下,我们需要重新处理一些历史记录消息,以便在升级消息处理程序之后可以修复错误。在原始NSQ中,无法执行此操作,因为它在内存中处理消息,并且不将所有历史消息持久化到磁盘。要使用历史记录,我们需要在使用完消息后保留带有配置的时间窗口的消息

  • 接收到的消息是无序的

    ​ 在某些情况下,我们需要确保将所有消息按顺序从一个系统传输到另一个系统,以使两个系统最终保持一致,即使存在某些异常情况(网络故障或崩溃)。为此,信息的持久性是一个前提,除此之外,我们还需要确保生产者和消费者都在我们的控制之下。

参数资料:

https://tech.youzan.com/tag/nsq/

posted on 2021-03-11 14:09  爱笑的张飞  阅读(593)  评论(0编辑  收藏  举报

导航