高性能消息中間件 nsq 解析-介紹

隨著互聯網技術在各行各業的應用高速普及與發展，各層應用之間調用關系越來越復雜，架構、開發、運維成本越來越高，高內聚、低耦合、可擴展、高可用已成為了行業需求。

一提到消息隊列 MQ(Message Queue)，我們會想到很多應用場景，比如消息通知、用戶積分增減、抽獎中獎等，可以看出來 MQ 的作用有：流程異步化、代碼解耦合、流量削峰、高可用、高吞吐量、廣播分發，達到數據的最終一致性，滿足具體的業務場景需求。

Nsq 是用 Go 語言開發的輕量級的分布式消息隊列，適合小型項目使用、用來學習消息隊列實現原理，對于學習 Go channel的原理和用法，以及如何用 Go 語言來寫分布式是一個很不錯的入門項目。

Nsq 模塊介紹

NSQ 最初是由 bitly 公司開源出來的一款簡單易用的分布式消息中間件，它可用于大規模系統中的實時消息服務，并且每天能夠處理數億級別的消息。

NSQ 具有如下特性：

分布式： 它提供了分布式的、去中心化且沒有單點故障的拓撲結構，穩定的消息傳輸發布保障，能夠具有高容錯和高可用特性。

易于擴展： 它支持水平擴展，沒有中心化的消息代理（ Broker ），內置的發現服務讓集群中增加節點非常容易。

運維方便： 它非常容易配置和部署，靈活性高。

高度集成： 現在已經有官方的 Golang、Python 和 JavaScript 客戶端，社區也有了其他各個語言的客戶端庫方便接入，自定義客戶端也非常容易。

首先看下 NSQ 的項目結構：

核心包為：nsqd、nsqadmin 和 nsqlookupd。apps 包中存放了各個入口方法。

nsqd： nsqd 是一個守護進程，負責接收（生產者 producer ）、排隊（最小堆實現）、投遞（消費者 consumer ）消息給客戶端。它可以獨立運行，不過通常它是由 nsqlookupd 實例所在集群配置的。

nsqlookupd： nsqlookupd 是守護進程負責管理拓撲信息。客戶端通過查詢 nsqlookupd 來發現指定話題（ topic ）的生產者，并且 nsqd 節點廣播話題（topic）和通道（ channel ）信息。有兩個接口： TCP 接口， nsqd 用它來廣播。 HTTP 接口，客戶端用它來發現和管理。

nsqadmin： nsqadmin 是一套 WEB UI，用來匯集集群的實時統計，并執行不同的管理任務。

除此之外，圖中還涉及到一些基本的概念：

Topic：一個 topic 就是程序發布消息的一個邏輯鍵，當程序第一次發布消息時就會創建 topic。

Channels： channel 與消費者相關，是消費者之間的負載均衡， channel 在某種意義上來說是一個“隊列”。每當一個發布者發送一條消息到一個 topic，消息會被復制到所有消費者連接的 channel 上，消費者通過這個特殊的 channel 讀取消息，實際上，在消費者第一次訂閱時就會創建 channel。 Channel 會將消息進行排列，如果沒有消費者讀取消息，消息首先會在內存中排隊，當量太大時就會被保存到磁盤中。

Messages：消息構成了我們數據流的中堅力量，消費者可以選擇結束消息，表明它們正在被正常處理，或者重新將他們排隊待到后面再進行處理。每個消息包含傳遞嘗試的次數，當消息傳遞超過一定的閥值次數時，我們應該放棄這些消息，或者作為額外消息進行處理。

常用工具類：

nsq_to _file：消費指定的話題（topic）/通道（channel），并寫到文件中，有選擇的滾動和/或壓縮文件。

nsq_to _http：消費指定的話題（topic）/通道（channel）和執行 HTTP requests (GET/POST) 到指定的端點。

nsq_to _nsq：消費者指定的話題/通道和重發布消息到目的地 nsqd 通過 TCP。

小結

本文主要介紹 nsq 的模塊、特性及其組成部分。nsq 專門為分布式、集群化而生，在處理 SPOF(single point of failure, 單點故障)、高可用、最終一致性方面很有優勢。

Serverless 架構就不要服務器了？

微服務架構中使用 ELK 進行日志采集以及統一處理

沒有 try-catch，該如何處理 Go 錯誤異常？

Go 分布式 架構設計

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。