有什么为 nsqd 推荐的拓扑结构?
强烈推荐 nsqd 和生产消息的服务一起运行。
nsqd 是一个相对轻量的进程，它能很好和其他进程协同运行。
这个模式有利于结构化消息流为一个消费问题，而不是一个生产问题。
另一个好处是它能将来自服务端的内容形成有效的独立，分享，简仓（silo）的数据。
注意: 这并不是必须得要求，它只是能让事情简单些（参见下面的问题）。
为什么不能用 nsqlookupd 来查询生产的内容给谁?
NSQ 提升了消费端的发现模型，减轻了前期的配置负载（需要告诉所有消费者去那里找他们要的内容）。
然而，它并没有提供任何方法来解决发布端将内容发布给谁。这是鸡和蛋的问题，在发布前并不存在内容。
通过使用 nsqd ，你可以避开这个问题（你的服务只是简单的将内容发布给本地的 nsqd），并且允许 NSQ 实时发现系统正常运行。
我只是想在某个节点上将 nsqd 作为一个工作队列来使用，有没有合适的例子?
是的，nsqd 可以很好的单独运行。
nsqlookupd 非常有利于大型分布式环境。
我需要运行多少个 nsqlookupd ?
依赖于集群的大小，nsqd 的节点数量，消费者，和你希望的容错能力。
3 个或 5 个就可以非常好的服务于百级别的主机和千级的消费者。
nsqlookupd 节点不需要回答查询。集群里的元数据是最终一致的。
是否需要客户端库来发布消息?
不需要！使用 HTTP 节点来发布消息就好（/pub 和 /mpub）。它简单，容易，在任意一个开发环境都可用。
绝大多数人使用 HTTP 来发布 NSQ 部署。
为什么强制客户端响应 TCP 协议 PUB 和 MPUB 命令?
我们相信 NSQ 操作的默认模式必须安全优先，并且我们希望协议简单并完整。
什么时候 PUB 或 MPUB 会失败?
nsqd 的参数)。
nsqd 被清除。
发布的时候客户端产生连接失败
(1) 和 (2) 是开发错误。(3) 和 (4) 很少见， (5) 是基于 TCP 协议都会遇到的问题。
如何避免之前 (3) 出现的问题?
删除话题（topic）是少见的操作。如果你想删除一个话题（topic），需要精确计算时间，确保删除后有充足的时间，发布的话题（topic）不会被执行。
如何命名话题（topic）和通道（channel）？
话题（topic）名需要描述在流中的数据。
通道（channel）名需要描述消费者的工作类型。
例如, 好的话题（topic）名 编码（encode）, 解码（decode）, api_请求（api_request）,页面_视图 。好的通道（channel）名归档（archive）, 分析_增长（analytics_increment）,垃圾_分析（spam_analysis）。
一个 nsqd 最多能支持多少个话题（topic）和通道（channel）?
没有内置的限制。它仅和 nsqd 所在的服务端的内存，CPU 限制有关（每个客户端 CPU 使用率已经大为改进了issue #236）。
如何为集群声明一个新的话题（topic）?
话题（topic）的第一个 PUB 或 SUB ，将会在 nsqd 上创建一个话题（topic）。话题（topic）的元数据将会传播给nsqlookupd 的配置。其他的读者将会通过周期性的查询 nsqlookupd 发现这个话题（topic）。
NSQ 能操作 RPC 吗?
是的，有这个可能性, 但是 NSQ 并不是为它设计的。
我们想发布一些文档说明它是如何结构化的，如果你感兴趣，可以来帮我们。
为什么强制我使用 Tornado?
pynsq 初始设计的时候，就聚焦于消费端的库，并且 NSQ 协议和 Python 的异步架构非常类似（尤其和 NSQ 的面向推送协议）。
Tornado 的 API 非常简单并且执行合理。
Tornado IOLoop 是否必须发布?
不，nsqd 为了发布简单，暴露了 HTPP 端(/pub 和 /mpub) 。
不必担心 HTTP 的过载。同时，/mpub 通过批量发布，减少了 HTTP 的过载。
那么什么时候使用 Writer?
当高性能，低负载优先级比较高的时候。
Writer 使用 TCP 协议里的 PUB 和 MPUB 命令， 它们比 HTTP 负载更低。
如果我就想”启动并忘记“将会发生什么(我能容忍消息丢失!)?
使用 Writer 并且不给发布的方法指定回调。
注意: 仅在简单的客户端代码有效， pynsq 场景必须处理 nsqd 的消息（比如，做这些事情不会导致性能提高）。
