部署

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

發(fā)布

• 是否需要客戶(hù)端庫(kù)來(lái)發(fā)布消息?

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

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

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

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

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

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

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

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

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

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

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

• 如何命名話(huà)題（topic）和通道（channel）？

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

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

  例如, 好的話(huà)題（topic）名 編碼（encode）, 解碼（decode）, api_請(qǐng)求（api_request）,頁(yè)面_視圖 。好的通道（channel）名歸檔（archive）, 分析_增長(zhǎng)（analytics_increment）,垃圾_分析（spam_analysis）。

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

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

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

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

• NSQ 能操作 RPC 嗎?

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

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

特定的 pynsq

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

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

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

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

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

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

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

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

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

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

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

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

特別感謝 Dustin Oprea (@DustinOprea) 開(kāi)始了這篇常見(jiàn)問(wèn)題。