Kafka & NSQ

Posted 2023-04-28

参考技术A kafka struct
kafka & consumer group 2
kafka group 3

图中说明一个consumer 可以消费多个partition （一般配置的partition有10个）
但是一个partition 只能连接一个consumer
Consumer 可以认为是消费者服务的实例

多个consumer可以组成一个组，每个消息只能被组中的一个consumer消费，
（所以一个partition对应的在同一个组中对应的consumer只有一个）
如果一个消息可以被多个consumer消费的话，那么这些consumer必须在不同的组。
（正如图3 中的两个不同颜色的线 虽然是同一个内容的消息 但是去往不同的组）
一个partition，只能被消费组里的一个消费者消费，但是可以同时被多个消费组消费

每个主题有多个分区，不同的消费者处理不同的分区，所以Kafka不仅保证了消息的有序性，也做到了消费者的负载均衡。

因为经常说到partition可以用于负载均衡 一个消息只会进入其中一个partition
自己的实验也证实了这种猜测

Kafka 的生产者和消费者相对于服务端而言都是客户端，生产者客户端发布消息到服务端的指定主题， 会指定消息所属的分区。生产者发布消息时根据消息是否有键， 采用不同的分区策略。消息没有键时，通过轮询方式进行客户端负载均衡消息有键时，根据分区语义确保相同键的消息总是发送到同一个分区。

nsqd and channel. GIF

https://cdn-images-1.medium.com/max/1600/1*rlL7_0y1aBuvA7jU7E4lig.png

对于发往Topic的消息，nsqd向该Topic下的所有Channel投递消息，而同一个Channel只投递一次
Channel下如果存在多个消费者，则随机选择一个消费者做投递。这种投递方式可以被用作消费者负载均衡。

at-least-one模式，至少发送一次，
time-out重传，因此consumer可能会接收重复数据。

会监听两个端口：
http: 4161 客户端用它来发现和管理。
tcp: 4160 nsqd 用它来广播

会监听两个端口：
http: 4151
tcp: 4150

nsqd 是一个守护进程，负责接收，排队，投递消息给客户端。

监听一个端口
http:4171

一个POST请求
curl -d 'hello world 1' ' http://127.0.0.1:4151/put?topic=test'

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

使用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能越来越完善。