分布式消息队列nsq -- 概述

Posted 2021-04-26 花田半亩勤耕耘

使用nsq已经有两个年头，基于其构建了组里的海量日志收集系统，日均收集日志压缩几十T+,秒级处理时延。协助过许多组外其他的同学使用。开源消息队列网上已有很多，比如Kafka、RabbitMQ等，非常成熟，文档详尽，相比之下nsq文档就贫乏许多，现在我们来一起揭开其神秘的面纱。

nsq(https://github.com/nsqio/nsq)是由golang开发的一个简单的分布式消息队列，简单、分布式是其最主要的基因，在后续的使用过程中就会深深体会到。其提供三个组件以及一些便利的工具。三个组件分别为nsqd、nsqlookupd、nsqadmin。简单来说：nsqd是消息实际存储组件、nsqlookupd提供服务注册与发现的功能，nsqadmin提供一个简单的监控与管理页面。

一个简单的使用拓扑如上图所示，nsqd启动的时候需要向nsqlookupd注册自己，以便后续消费者能够发现并消费其上数据；为了高可用性，一般会向多个nsqloopd注册自己，每个lookupd相互独立，对每个lookupd来说，向其注册的所有nsqd为一个集群，这种设计模式，使得使用者可以非常灵活的组织自己的nsqd集群；nsq官方提供的建议是nsqd与生产者部署在同一台机器上面，生产者往本机nsqd去写数据，生产中经验，不要跨机房生产数据，以免影响服务质量；消费者消费数据的时候会轮询的询问配置的所有lookupd，然后与对应的nsqd建立连接，之后由nsqd主动的推送数据；nsqadmin提供给用户一个简单的监控与管理页面。

nsq的主要有三个核心概念，topic、channel、message。下面以nsqd为例来简单介绍下，nsqd被设计用来同时处理多个数据流，每个数据流通过topic来区分，比如业务A的数据可以取名叫Business-A、业务B的数据可以取名为Business-B，生产者根据其所属业务类型，向对应topic发送数据即可。nsqd的数据流使用tcp协议来传输，根据自己的私有协议将数据流解析为一个个消息，每次都是发送或接受一个消息，一个message除了包含消息体外，还有nsqd host、重传次数等信息。还有一个重要的概念是channel，虽然名字与golang中的channel相同，而且实现也是基于此，两者却不是同一个概念，也很容易让人迷惑，如下图，一个topic可以有多个channel，每个channel所消费的是该topic上面的全量数据，一个channel可以被一个或者多个consumer订阅，当多个consumer订阅一个channel的时候，这组consumers消费数据的总和才是该topic上的全量数据。channel上面的消息会随机发送给订阅该channel的consumers中的一个，因此，当数据量突然变大，数据堆积严重的时候，可以方便的增加consumer；数据量少的时候减少consumer的数量，轻松实现扩容/缩容。

特点

1、简单灵活、无依赖、门槛低

nsq协议简单，概念少，没有依赖，使用时只需下载官方提供的二进制包，几条命令即可运行起来一个nsq集群，使用门槛非常低，符合个golang程序设计的理念。

2、分布式、去中心化、没有单点故障，能够方便的扩容与缩容

其简单设计美学与分布式的设计理念，使得使用者可以非常自由灵活的组建nsqd集群、根据业务运行状况，方便的进行扩容/缩容，轻松支持海量数据。

3、消息是无序、至少交付一次，需要消费者保证幂等性

4、消息可以存储在内存与磁盘

nsq可以通过参数限制内存中消息数目，超过该数目的数据会落磁盘，当出现这种情况，就说明该增加消费机器了，合理调整内存消息数与consumer数目，使数据不落磁盘，会极大提高系统性能。

5、提供简单的监控与管理工具，能够实时了解集群状态

6、没有复制

因为简单，放弃了部分可用性，nsq没有实现复制的功能，当一台nsqd机器宕机时，其在内存中还未刷新到磁盘的数据会丢失。

nsq适用于大数据、消息无序、允许少量数据丢失的情景。长期以来使用nsq的经验来看，nsq程序非常稳定，其简单与分布式的设计理念，也让我们受益良多，虽然仍有些许缺陷，但都可以通过其他技术方案来解决，希望以后nsq能越来越完善。