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中，无法执行此操作，因为它在内存中处理消息，并且不将所有历史消息持久化到磁盘。要使用历史记录，我们需要在使用完消息后保留带有配置的时间窗口的消息
-
接收到的消息是无序的
在某些情况下，我们需要确保将所有消息按顺序从一个系统传输到另一个系统，以使两个系统最终保持一致，即使存在某些异常情况(网络故障或崩溃)。为此，信息的持久性是一个前提，除此之外，我们还需要确保生产者和消费者都在我们的控制之下。
参数资料：