NSQ 源碼閱讀(一) 相關概念理解

NSQ是由知名短連接服務商bitly用Go語言開發的實時消息處理系統，具備高性能、高可靠、無視單點故障等優勢，是一個很是不錯的新興的消息隊列解決方案。

相關概念

提到消息隊列，咱們先看一下消息隊列的相關概念。
如下主要參考 消息隊列設計精要，我提取一些我認爲重要的要點

1. 當你須要使用消息隊列時，首先須要考慮它的必要性。可使用mq的場景有不少，最經常使用的幾種，是作業務解耦/最終一致性/廣播/錯峯流控等。反之，若是須要強一致性，關注業務邏輯的處理結果，則RPC顯得更爲合適。

2. 解耦是消息隊列要解決的最本質問題。所謂解耦，簡單點講就是一個事務，只關心核心的流程。而須要依賴其餘系統但不那麼重要的事情，有通知便可，無需等待結果。換句話說，基於消息的模型，關心的是「通知」，而非「處理」。

3. 關於強一致性和最終一致性
   強一致性：系統中的某個數據被成功更新後，後續任何對該數據的讀取操做都將獲得更新後的值。
   最終一致性指的是兩個系統的狀態保持一致，要麼都成功，要麼都失敗。固然有個時間限制，理論上越快越好，但實際上在各類異常的狀況下，可能會有必定延遲達到最終一致狀態，但最後兩個系統的狀態是同樣的。

4. 咱們來看看若是須要數據落地的狀況下各類存儲子系統的選擇。理論上，從速度來看，文件系統>分佈式KV（持久化）>分佈式文件系統>數據庫，而可靠性卻截然相反。

5. 市面上的消息隊列定義了一堆讓人暈頭轉向的名詞，如JMS 規範中的Topic/Queue，Kafka裏面的Topic/Partition/ConsumerGroup，RabbitMQ裏面的 Exchange等等。拋開現象看本質，無外乎是單播與廣播的區別。所謂單播，就是點到點；而廣播，是一點對多點。固然，對於互聯網的大部分應用來講，組間廣播、組內單播是最多見的情形。

nsq關注點

1. 如何實現消息的廣播，單播等

2. 通訊協議

3. 如何保證消息不丟失？存儲

4. 如何儘量減少消息重複，如何處理消息重複？

5. 服務發現

6. 如何消除單點故障？

nsq 文檔

對於nsq的基本介紹這裏不作搬運了，可參考官方文檔，網上也有很多介紹nsq的文章