离线下载
PDF版 ePub版

极客学院团队出品 · 更新于 2017-11-22 17:00:56

常见问题

部署

  • 有什么为 nsqd 推荐的拓扑结构?

    强烈推荐 nsqd生产消息的服务一起运行。

    nsqd 是一个相对轻量的进程,它能很好和其他进程协同运行。

    这个模式有利于结构化消息流为一个消费问题,而不是一个生产问题。

    另一个好处是它能将来自服务端的内容形成有效的独立,分享,简仓(silo)的数据。

    注意: 这并不是必须得要求,它只是能让事情简单些(参见下面的问题)。

  • 为什么不能用 nsqlookupd 来查询生产的内容给谁?

    NSQ 提升了消费端的发现模型,减轻了前期的配置负载(需要告诉所有消费者去那里找他们要的内容)。

    然而,它并没有提供任何方法来解决发布端将内容发布给谁。这是鸡和蛋的问题,在发布前并不存在内容。

    通过使用 nsqd ,你可以避开这个问题(你的服务只是简单的将内容发布给本地的 nsqd),并且允许 NSQ 实时发现系统正常运行。

  • 我只是想在某个节点上将 nsqd 作为一个工作队列来使用,有没有合适的例子?

    是的,nsqd 可以很好的单独运行。

    nsqlookupd 非常有利于大型分布式环境。

  • 我需要运行多少个 nsqlookupd ?

    依赖于集群的大小,nsqd 的节点数量,消费者,和你希望的容错能力。

    3 个或 5 个就可以非常好的服务于百级别的主机和千级的消费者。

    nsqlookupd 节点不需要回答查询。集群里的元数据是最终一致的。

发布

  • 是否需要客户端库来发布消息?

    不需要!使用 HTTP 节点来发布消息就好(/pub/mpub)。它简单,容易,在任意一个开发环境都可用。

    绝大多数人使用 HTTP 来发布 NSQ 部署。

  • 为什么强制客户端响应 TCP 协议 PUBMPUB 命令?

    我们相信 NSQ 操作的默认模式必须安全优先,并且我们希望协议简单并完整。

  • 什么时候 PUBMPUB 会失败?

    1. 话题(topic)的名字没有正确格式化(长度限制)。参见topic and channel name spec
    2. 消息过大(具体限制参见 nsqd 的参数)。
    3. 中间的话题(topic)被删除。
    4. nsqd 被清除。
    5. 发布的时候客户端产生连接失败

      (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)的第一个 PUBSUB ,将会在 nsqd 上创建一个话题(topic)。话题(topic)的元数据将会传播给 nsqlookupd 的配置。其他的读者将会通过周期性的查询 nsqlookupd 发现这个话题(topic)。

  • NSQ 能操作 RPC 吗?

    是的,有这个可能性, 但是 NSQ 并不是为它设计的。

    我们想发布一些文档说明它是如何结构化的,如果你感兴趣,可以来帮我们。

特定的 pynsq

  • 为什么强制我使用 Tornado?

    pynsq 初始设计的时候,就聚焦于消费端的库,并且 NSQ 协议和 Python 的异步架构非常类似(尤其和 NSQ 的面向推送协议)。

    Tornado 的 API 非常简单并且执行合理。

  • Tornado IOLoop 是否必须发布?

    不,nsqd 为了发布简单,暴露了 HTPP 端(/pub/mpub) 。

    不必担心 HTTP 的过载。同时,/mpub 通过批量发布,减少了 HTTP 的过载。

  • 那么什么时候使用 Writer?

    当高性能,低负载优先级比较高的时候。

    Writer 使用 TCP 协议里的 PUBMPUB 命令, 它们比 HTTP 负载更低。

  • 如果我就想”启动并忘记“将会发生什么(我能容忍消息丢失!)?

    使用 Writer 并且不给发布的方法指定回调。

    注意: 仅在简单的客户端代码有效, pynsq 场景必须处理 nsqd 的消息(比如,做这些事情不会导致性能提高)。

特别感谢 Dustin Oprea (@DustinOprea) 开始了这篇常见问题。

上一篇: 特性和担保 下一篇: 性能