NSQ分布式消息基础入门

本文已被阅读过 Posted by 陌无崖 on 2019-11-17

NSQ

介绍

NSQ是一个基于Go语言的分布式实时消息平台,可以大规模的运用于实时消息服务,每天可以处理数亿级别的消息,设计目标是为在分布式环境下运行的去中心化服务提供一个强大的基础架构。

NSQ核心组件

nsqlookupd

用于守护进程负责管理拓扑信息,它使用tcp(默认端口4160)管理nsqd服务,使用http(默认端口4161)管理nsqadmin服务。同时为客户端提供查询功能。

特点
1、具有唯一性,在一个Nsql服务中只有一个nsqlookupd服务。
2、去中心化,即使该组件崩溃,也不影响正常运行。
3、充当nsqd和naqadmin信息交互的中间件。
4、提供一个http查询服务,给客户端定时更新nsqd的地址目录。

nsqadmin

一套 WEB UI,用来汇集集群的实时统计,并执行不同的管理任务。

功能
1、提供一个对topic和channel统一管理的操作界面以及各种实时监控数据的展示。
2、展示所有message的数量。
3、能够在后台创建topic和channel。
4、nsqadmin的所有功能都必须依赖于nsqlookupd,nsqadmin只是向nsqlookupd传递用户操作并展示来自nsqlookupd的数据。

nsqd

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

功能或特性
1、对订阅了同一个topic,同一个channel的消费者使用负载均衡策略(不是轮询)
2、只要channel存在,即使没有该channel的消费者,也会将生产者的message缓存到队列中(注意消息的过期处理)
3、保证队列中的message至少会被消费一次,即使nsqd退出,也会将队列中的消息暂存磁盘上(结束进程等意外情况除外)。
4、限定内存占用,能够配置nsqd中每个channel队列在内存中缓存的message数量,一旦超出,message将被缓存到磁盘中。
5、topic,channel一旦建立,将会一直存在,要及时在管理台或者用代码清除无效的topic和channel,避免资源的浪费。

官方图展示:


## Nsq服务端与客户端的关系 ### 消费者 1、消费者直接连接nsqd,缺点是服务无法实现动态伸缩(可以自己实现)。
2、通过http查询nsqlookupd获取该nsqlookupd上的所有nsqd的连接地址。然后分别建立连接,这种方式是传统的轮询方式,属于官方推荐的做法。如下图:

生产者

生产者直接去nsqd去投递message

消息的生命周期

1、生产者往nsqd中发送消息,开启一个连接,发送一个带有topic和消息体的pun的命令到nsqd中
2、topic会对消息进行copy,发送至各个channel中
3、在channel中的每条消息都会被放进队列中,直到消息被worker消费掉,如果队列超出了内存的限制,消息则会被写进磁盘中
4、

Nsq安装

docker部署

docker-compose.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
version: '3'
services:
nsqlookupd:
image: nsqio/nsq
command: /nsqlookupd
ports:
- "4160"
- "4161"
nsqd:
image: nsqio/nsq
command: /nsqd --lookupd-tcp-address=nsqlookupd:4160
depends_on:
- nsqlookupd
ports:
- "4150"
- "4151"
nsqadmin:
image: nsqio/nsq
command: /nsqadmin --lookupd-http-address=nsqlookupd:4161
depends_on:
- nsqlookupd
ports:
- "4171"
1
docker-compose up -d

界面