nats服务器状态未启用,消息系统NATS常见的几个问题

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的数量限制