共计 1529 个字符，预计需要花费 4 分钟才能阅读完成。
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 语言的数据结构来实现。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-10/136418.htm
