這個文檔描述了一些 NSQ 模式，解決不同的問題。

免責申明: 已經(jīng)有一些明顯的技術(shù)建議，但是這個文檔通常會忽略，深層的個人選擇合適工具的細節(jié)，獲取軟件安裝到生產(chǎn)環(huán)境，管理服務(wù)在哪里運行，服務(wù)配置，并管理運行進程 (daemontools ，supervisord，init.d等等)。

指標收集

無論你編譯的是哪個類型的 Web 服務(wù)，多數(shù)情況下你會想收集各種指標，來了解你的基礎(chǔ)架構(gòu)，你的用戶，你的業(yè)務(wù)。

對于 Web 服務(wù)，多數(shù)指標是由 HTTP 請求事件產(chǎn)生的，比如 API。本地的方法可能會結(jié)構(gòu)化這個異步操作，通過 API 請求直接寫到你的指標系統(tǒng)。

http://wiki.jikexueyuan.com/project/nsq-guide/images/tumblr_mf74kh5r4P1qj3yp2.png" alt="naive approach" />

• 當你的指標系統(tǒng)下降的時候會發(fā)生什么？
• 你的 API 請求是否掛起和/或失?。?/li>
• 你如何處理增長 API 請求挑戰(zhàn)？

解決這些問題的一個方法是設(shè)法異步寫入到你的指標系統(tǒng)，就是說，將數(shù)據(jù)放到本地隊列中，并通過其他進程寫到你的下行系統(tǒng)（消費這個隊列）。這個獨立操作讓系統(tǒng)更加健壯，容錯性更強。在 bitly，我們使用 NSQ 完成這個目標。

NSQ 有話題（topic)和通道（channel)兩個概念。假設(shè)將話題當做消息的唯一流（如同我們的 API 事件流）。假設(shè)，將通道當做這個消息流的指定消費者集合的拷貝。話題和通道都是獨立隊列。這些特性允許 NSQ 支持多播（話題拷貝每個消息到 N 通道）并且分發(fā)消息投遞（通道平分它的消息到 N 個消費）。

更多細節(jié)參考design doc 和 slides from our Golang NYC talk,尤其 slides 19 through 33 描述了話題（topic)和通道（channel)的細節(jié)。

http://wiki.jikexueyuan.com/project/nsq-guide/images/tumblr_mf74ktpfpP1qj3yp2.png" alt="architecture with NSQ" />

完整的 NSQ 比較簡單，注意兩點：

1. 在 API 應(yīng)用所運行的主機上，運行 nsqd 實例。
2. 更新你的 API 應(yīng)用，寫到本地 nsqd 實例隊列事件，而不是寫到指標系統(tǒng)。能夠容易的內(nèi)審和操作流，我們通常將數(shù)據(jù)格式化為 line-oriented JSON。寫到 nsqd 可以簡單的執(zhí)行一個 HTTP post 請求到 /put 端點。
3. 用 client libraries 在你的語言創(chuàng)建一個消費者。這個"工作者"將會訂閱數(shù)據(jù)流，并會處理事件，寫到你的指標系統(tǒng)。它也能運行在主機上，運行你的 API 應(yīng)用和 nsqd。

這有一個使用官方Python client library 寫的例子：

除了解耦之外，通過使用我們官方的客戶端庫，當消息處理錯誤的時候，消費者可以優(yōu)雅的降級。我們的庫有 2 個關(guān)鍵特性：

1. 重試 - 當你的消息處理函數(shù)返回失敗，這個消息將會以 REQ (re-queue) 命令形式發(fā)送給 nsqd 。同時，如果在時間窗里消息還沒被響應(yīng)，nsqd 將會自動將消息超時（并重新隊列）。這兩個特性對于消息投遞保障非常關(guān)鍵。
2. Backoff指數(shù) - 當消息處理失敗，讀取庫將會延遲附加信息的收據(jù)，放大建立在 # 連續(xù)的失敗指數(shù)。當讀取者處于 backoff 狀態(tài)，并且開始處理成功，直到為 0 時，會發(fā)生相反序列.

從概念上來說，這兩個特性允許系統(tǒng)優(yōu)雅的自動響應(yīng)下行失敗。

持久化

好，現(xiàn)在你可以應(yīng)付你的指標系統(tǒng)因為沒有數(shù)據(jù)并且沒有 degraded 的 API 服務(wù)到其他端點，導(dǎo)致的不可用。你也可以通過從同一個通道（channel）添加更多的工作實例給消費者，放大這個流系統(tǒng)的水平線。

但是，提前想清楚所有的 API 事件的指標，也不太可能。

是否有數(shù)據(jù)流系統(tǒng)的 log，能滿足未來任何操作？日志會很容易導(dǎo)致冗余備份，可以把它作為 downstream 系統(tǒng)發(fā)生災(zāi)難時的 "plan z"。但是，你會希望消費者來完成消息數(shù)據(jù)的備份？也許不是，因為這是整個 "separation of concerns" 的事情。

歸檔 NSQ 話題（topic）非常常見，所以我們建了一個工具，nsq_to_file（使用 NSQ 打包），你可用它來完成。

記住，在 NSQ 中，每個話題（topic）的通道（channel）是獨立的，并且接收所有消息的拷貝。你可以利用這個特性，來完成流的歸檔。實際上，這意味著如果你的指標系統(tǒng)已經(jīng)有這些問題，并且 metrics 通道得到支持，它就不會影響到獨立的 archive 通道，你將會持久化消息到磁盤。

所以，添加一個 nsq_to_file 實例到同一個主機，并且使用命令行如下：

/usr/local/bin/nsq_to_file --nsqd-tcp-address=127.0.0.1:4150 --topic=api_requests --channel=archive

http://wiki.jikexueyuan.com/project/nsq-guide/images/tumblr_mf74l5RqlZ1qj3yp2.png" alt="archiving the stream" />

分布式系統(tǒng)

可能你已經(jīng)注意到了，目前系統(tǒng)還沒有超出單機，這是明顯的錯誤。

不幸的是，要建立一個分布式系統(tǒng)很難。幸運的是，NSQ 可以幫助你。底下的改變演示了 NSQ 如何減輕建立分布式系統(tǒng)的痛苦，以及如何完成高可用性和容錯。

假設(shè)這個事件流非常重要。你希望能容忍主機錯誤，并保證消息最終能到歸檔，所以你增加了另一個主機。

http://wiki.jikexueyuan.com/project/nsq-guide/images/tumblr_mf74lmYhZa1qj3yp2.png" alt="adding a second host" />

假設(shè)你已經(jīng)在這兩個主機間負載平衡，這樣你就可以容忍單個主機錯誤。

現(xiàn)在，我們覺的持久化處理，壓縮，傳輸這些日志會影響性能。如何切割這些責任到這些主機上，讓它們擁有更高的 IO 能力？

http://wiki.jikexueyuan.com/project/nsq-guide/images/tumblr_mf74m0JHMi1qj3yp2.png" alt="separate archive hosts" />

這個拓撲結(jié)構(gòu)和配置可以容易放大到雙位主機，但是你仍然手工管理這些服務(wù)配置。尤其對于每個消費者，這個創(chuàng)建過程很難從代碼上確定 nsqd 實例在哪里。你真正希望的是配置能進化，并且在 NSQ 集群的狀態(tài)基礎(chǔ)上運行時可訪問。這是我們建立 nsqlookupd 的目的。

nsqlookupd 是一個守護進程記錄并傳播 NSQ 集群運行時候的狀態(tài)。nsqd 實例維護 TPC 連接的持久化來 nsqlookupd，并且推送狀態(tài)變化。具體來說，nsqd 將自己注冊為某個話題（topic）的生產(chǎn)者，以及所有它知道的通道（channel）。它允許消費者查詢 nsqlookupd，來確定誰是感興趣的話題（topic）的生產(chǎn)者。久而久之，他們將會知道新的生產(chǎn)者的存在，并能路由失敗。

你需要做的改變僅僅是，nsqlookupd 時指出存在的 nsqd 和消費者實例（每個人都知道 nsqlookupd 實例在哪里，但是消費者不會明確的知道生產(chǎn)者在哪里，反之亦然）?，F(xiàn)在拓撲結(jié)構(gòu)如下：

http://wiki.jikexueyuan.com/project/nsq-guide/images/tumblr_inline_mf8sfr2sp41qj3yp2.png" alt="adding nsqlookupd" />

乍一看，這個圖變復(fù)雜了。這圖具有誤導(dǎo)性，整個圖節(jié)點變多了，導(dǎo)致很難直接通訊。因為 nsqlookupd 能作為文件夾服務(wù)，你能高效的把生產(chǎn)者和消費者解耦。依賴于已有的流添加一個下行服務(wù)非常簡單，只需指定你感興趣的話題（topic）（通過 nsqlookupd 可以找到生產(chǎn)者）。

如何保證查找數(shù)據(jù)的可用性和一致性？nsqlookupd 并不會占用大量資源，并且能很容易和其他服務(wù)器在一起工作。同時 nsqlookupd 實例不需要調(diào)整，或者和其他組合。消費者通常只需要一個 nsqlookupd（它們將會聯(lián)合它們所知的nsqlookupd 實例響應(yīng)）。這樣就很容易遷移到新的 nsqlookupd 組合中。