消息系统NATS常见的几个问题

前端之家收集整理的这篇文章主要介绍了消息系统NATS常见的几个问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

消息系统NATS常见的几个问题

作者:chszs,未经博主允许不得转载。经许可的转载需注明作者和博客主页:http://blog.csdn.net/chszs

1)Request()和Publish()之间的不同

Publish()发送一条消息到gnatsd,是使用它的地址作为一个subject,而gnatsd交付消息给所有注册了此subject的订阅者。可选地是,你还可以发送带reply subject的消息到gnatsd,这种方式为订阅者提供了接收消息并返回一条消息给发布者的方法
Request()是一个简单方便的API,它提供了一个伪同步的方式,使用了超时timeout设置。它创建了一个收件箱(收件箱是一种subject类型,对请求者唯一),订阅subject,然后发布你的请求消息(消息带reply地址)设置为收件箱的subject,然后等待响应,或者超时取消。

2)多个订阅者可以接收一个请求吗?

可以。NATS是一个发布/订阅系统,它还有分布式队列的基础,这基于每一个订阅者。当你发布一条消息时,在请求的开始,每一个订阅者都会收到消息。如果订阅者形成了一个队列组,那么NATS将会随机选择一个订阅者来接收消息。要注意,请求者不知道也没法控制这个消息。

3)怎样监控NATS集群

有三个选择。
* nats-top
https://github.com/nats-io/nats-top
类似于top的监控工具
* natsboard
https://github.com/cmfatih/natsboard
* nats-mon
https://github.com/repejota/nats-mon

4)NATS是否做了排队?是否做了负载均衡?

“排队Queueding”这个术语在不同的上下文有不同的意思,必须仔细区分其用法。NATS实现了不支持持久化的分布式队列——通过订阅者的队列组(Queue Group)实现的。订阅者队列组提供了消息交付形式的负载均衡,Subject订阅既可以是“个体”订阅,又可以是队列组订阅。在创建订阅时,选择加入一个队列组,通过提供一个可选的队列组名。对于个体的Subject订阅,gnatsd会尝试交付该Subject后续的每一条消息副本给每一个订阅者。而对于队列组的订阅,gnatsd会尝试交付该Subject后续的每一条消息给组中的任意一个订阅者,这个选择是随机的。分布式队列的这种交付形式是实时执行 的,iaoxi不会持久化到二级存储中。此外,交付基于兴趣图(interest graph)——即订阅,所以它不是发布者的操作,而是完全受gnatsd的控制。

5)可以列出现有的NATS集群的Subject吗?

NATS维护并不断实时更新兴趣图(包括Subject和Subject的订阅者),这个兴趣图是动态的,会随着发布者和订阅者的不断往复会变化。如果要决定手机这个信息,可以间接地在任意时间点上获取监控点的/connz和/routez的信息。

6)NATS支持Subject的通配符吗?

支持。有效的通配符如下:
圆点“.”是token的分隔符;星号“*”是token的通配符。比如:
foo.* 匹配 foo.bar、foo.baz,但是不匹配 foo.bar.baz
大于符号“>”是一个完整的通配符匹配。比如:
foo.> 匹配 foo.bar、foo.baz、foo.bar.baz、foo.bar.1

7)NATS是否限制了消息的尺寸

NATS强制服务器和客户端在建立连接设置时限制消息的尺寸。目前这个限制是1MB。

8)Subject的数量限制

目前,NATS允许的最大Subject数量为2^32,这在未来可能会改变。目前的实现使用了自定义的HashMap,以后会采用Go语言的数据结构来实现。

猜你在找的Go相关文章