部署

• 有什么為 nsqd 推薦的拓?fù)浣Y(jié)構(gòu)?

  強(qiáng)烈推薦 nsqd 和生產(chǎn)消息的服務(wù)一起運(yùn)行。

  nsqd 是一個(gè)相對輕量的進(jìn)程，它能很好和其他進(jìn)程協(xié)同運(yùn)行。

  這個(gè)模式有利于結(jié)構(gòu)化消息流為一個(gè)消費(fèi)問題，而不是一個(gè)生產(chǎn)問題。

  另一個(gè)好處是它能將來自服務(wù)端的內(nèi)容形成有效的獨(dú)立，分享，簡倉（silo）的數(shù)據(jù)。

  注意: 這并不是必須得要求，它只是能讓事情簡單些（參見下面的問題）。

• 為什么不能用 nsqlookupd 來查詢生產(chǎn)的內(nèi)容給誰?

  NSQ 提升了消費(fèi)端的發(fā)現(xiàn)模型，減輕了前期的配置負(fù)載（需要告訴所有消費(fèi)者去那里找他們要的內(nèi)容）。

  然而，它并沒有提供任何方法來解決發(fā)布端將內(nèi)容發(fā)布給誰。這是雞和蛋的問題，在發(fā)布前并不存在內(nèi)容。

  通過使用 nsqd ，你可以避開這個(gè)問題（你的服務(wù)只是簡單的將內(nèi)容發(fā)布給本地的 nsqd），并且允許 NSQ 實(shí)時(shí)發(fā)現(xiàn)系統(tǒng)正常運(yùn)行。

• 我只是想在某個(gè)節(jié)點(diǎn)上將 nsqd 作為一個(gè)工作隊(duì)列來使用，有沒有合適的例子?

  是的，nsqd 可以很好的單獨(dú)運(yùn)行。

  nsqlookupd 非常有利于大型分布式環(huán)境。

• 我需要運(yùn)行多少個(gè) nsqlookupd ?

  依賴于集群的大小，nsqd 的節(jié)點(diǎn)數(shù)量，消費(fèi)者，和你希望的容錯(cuò)能力。

  3 個(gè)或 5 個(gè)就可以非常好的服務(wù)于百級別的主機(jī)和千級的消費(fèi)者。

  nsqlookupd 節(jié)點(diǎn)不需要回答查詢。集群里的元數(shù)據(jù)是最終一致的。

發(fā)布

• 是否需要客戶端庫來發(fā)布消息?

  不需要！使用 HTTP 節(jié)點(diǎn)來發(fā)布消息就好（/pub 和 /mpub）。它簡單，容易，在任意一個(gè)開發(fā)環(huán)境都可用。

  絕大多數(shù)人使用 HTTP 來發(fā)布 NSQ 部署。

• 為什么強(qiáng)制客戶端響應(yīng) TCP 協(xié)議 PUB 和 MPUB 命令?

  我們相信 NSQ 操作的默認(rèn)模式必須安全優(yōu)先，并且我們希望協(xié)議簡單并完整。

• 什么時(shí)候 PUB 或 MPUB 會失敗?

  1. 話題（topic）的名字沒有正確格式化（長度限制）。參見topic and channel name spec。
  2. 消息過大(具體限制參見 nsqd 的參數(shù))。
  3. 中間的話題（topic）被刪除。
  4. nsqd 被清除。

  5. 發(fā)布的時(shí)候客戶端產(chǎn)生連接失敗

     (1) 和 (2) 是開發(fā)錯(cuò)誤。(3) 和 (4) 很少見， (5) 是基于 TCP 協(xié)議都會遇到的問題。

• 如何避免之前 (3) 出現(xiàn)的問題?

  刪除話題（topic）是少見的操作。如果你想刪除一個(gè)話題（topic），需要精確計(jì)算時(shí)間，確保刪除后有充足的時(shí)間，發(fā)布的話題（topic）不會被執(zhí)行。

設(shè)計(jì)和理論

• 如何命名話題（topic）和通道（channel）？

  話題（topic）名需要描述在流中的數(shù)據(jù)。

  通道（channel）名需要描述消費(fèi)者的工作類型。

  例如, 好的話題（topic）名 編碼（encode）, 解碼（decode）, api_請求（api_request）,頁面_視圖 。好的通道（channel）名歸檔（archive）, 分析_增長（analytics_increment）,垃圾_分析（spam_analysis）。

• 一個(gè) nsqd 最多能支持多少個(gè)話題（topic）和通道（channel）?

  沒有內(nèi)置的限制。它僅和 nsqd 所在的服務(wù)端的內(nèi)存，CPU 限制有關(guān)（每個(gè)客戶端 CPU 使用率已經(jīng)大為改進(jìn)了issue #236）。

• 如何為集群聲明一個(gè)新的話題（topic）?

  話題（topic）的第一個(gè) PUB 或 SUB ，將會在 nsqd 上創(chuàng)建一個(gè)話題（topic）。話題（topic）的元數(shù)據(jù)將會傳播給 nsqlookupd 的配置。其他的讀者將會通過周期性的查詢 nsqlookupd 發(fā)現(xiàn)這個(gè)話題（topic）。

• NSQ 能操作 RPC 嗎?

  是的，有這個(gè)可能性, 但是 NSQ 并不是為它設(shè)計(jì)的。

  我們想發(fā)布一些文檔說明它是如何結(jié)構(gòu)化的，如果你感興趣，可以來幫我們。

特定的 pynsq

• 為什么強(qiáng)制我使用 Tornado?

  pynsq 初始設(shè)計(jì)的時(shí)候，就聚焦于消費(fèi)端的庫，并且 NSQ 協(xié)議和 Python 的異步架構(gòu)非常類似（尤其和 NSQ 的面向推送協(xié)議）。

  Tornado 的 API 非常簡單并且執(zhí)行合理。

• Tornado IOLoop 是否必須發(fā)布?

  不，nsqd 為了發(fā)布簡單，暴露了 HTPP 端(/pub 和 /mpub) 。

  不必?fù)?dān)心 HTTP 的過載。同時(shí)，/mpub 通過批量發(fā)布，減少了 HTTP 的過載。

• 那么什么時(shí)候使用 Writer?

  當(dāng)高性能，低負(fù)載優(yōu)先級比較高的時(shí)候。

  Writer 使用 TCP 協(xié)議里的 PUB 和 MPUB 命令， 它們比 HTTP 負(fù)載更低。

• 如果我就想”啟動并忘記“將會發(fā)生什么(我能容忍消息丟失!)?

  使用 Writer 并且不給發(fā)布的方法指定回調(diào)。

  注意: 僅在簡單的客戶端代碼有效， pynsq 場景必須處理 nsqd 的消息（比如，做這些事情不會導(dǎo)致性能提高）。

特別感謝 Dustin Oprea (@DustinOprea) 開始了這篇常見問題。