1）Request()和Publish()之间的不同
Publish()发送一条消息到gnatsd，是使用它的地址作为一个subject，而gnatsd交付消息给所有注册了此subject的订阅者。可选地是，你还可以发送带reply subject的消息到gnatsd，这种方式为订阅者提供了接收消息并返回一条消息给发布者的方法。
Request()是一个简单方便的API，它提供了一个伪同步的方式，使用了超时timeout设置。它创建了一个收件箱（收件箱是一种subject类型，对请求者唯一），订阅subject，然后发布你的请求消息（消息带reply地址）设置为收件箱的subject，然后等待响应，或者超时取消。
可以。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
“排队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
NATS强制服务器和客户端在建立连接设置时限制消息的尺寸。目前这个限制是1MB。
8）Subject的数量限制目前，NATS允许的最大Subject数量为2^32，这在未来可能会改变。目前的实现使用了自定义的HashMap，以后会采用Go语言的数据结构来实现。