Faruk Akgul：zeromq——use Zeromq And Learn How To Apply Different Message Patterns@2013

根據提供的資料，以下是關於 ZeroMQ 的主要論點及其詳細解釋：

ZeroMQ (ØMQ) 是一個高效率的異步訊息傳遞函式庫，旨在讓開發者更容易設計複雜的分布式和並發應用程式。它被社群譽為「裝上類固醇的通訊端」，結合了高階抽象的易用性與低階協定的速度和靈活性。與傳統的訊息佇列系統（如 ActiveMQ, WebSphereMQ, RabbitMQ）不同，ZeroMQ 並非一個現成的訊息伺服器或代理程式 (broker)，而是一個函式庫，提供了建構自己的訊息佇列系統所需的基本組件。這使其設計具有無代理程式 (brokerless) 的特性，應用程式可以直接相互通訊，而無需經過一個中央節點，這通常能帶來更高的效能和更簡單的部署架構。

核心概念與 ZeroMQ 的不同之處：

1. 訊息佇列與異步通訊： ZeroMQ 基於訊息佇列的概念，強調異步通訊。在同步系統中，任務按順序處理，一個任務必須完成後才能開始下一個。多執行緒雖然能實現並行，但執行緒由作業系統管理，上下文切換成本高。ZeroMQ 透過異步 I/O (AIO) 和內部佇列，允許程式在等待 I/O 時繼續執行其他任務，從而提高效率。訊息佇列確保了即使在資源不足或對方未準備好時，訊息也能被暫存並最終送達，實現了解耦。
2. 通訊端 (Sockets)： ZeroMQ 提供了一系列特殊的通訊端類型，這些通訊端是 ZeroMQ 的核心構件。不同於傳統的 TCP 通訊端是同步、一對一、處理位元組流的，ZeroMQ 通訊端是異步的、多對多（儘管可以配置成一對一、一對多或多對一），並且處理的是訊息（具有固定長度的二進位對象）。ZeroMQ 通訊端在背景處理連接建立、重連、斷開和訊息傳輸，並使用內部佇列來管理進出的訊息。開發者只需呼叫 zmq_send() 和 zmq_recv() 等高階函數來傳送和接收完整的訊息。
3. 無代理程式設計： 這是 ZeroMQ 最突出的特點之一。傳統 MQ 需要一個中央代理程式來路由和管理訊息。ZeroMQ 則讓節點直接連接，由 ZeroMQ 函式庫在應用程式內部處理訊息路由。這種設計減少了單點故障的風險（雖然引入了應用程式間直接依賴連接），並通常能實現更低的延遲和更高的吞吐量。
4. 上下文 (Context)： 所有 ZeroMQ 通訊端都隸屬於一個上下文 (zmq_ctx_new())。上下文負責管理 ZeroMQ 內部的所有資源，包括 I/O 線程。上下文是執行緒安全的，可以在多個執行緒間共享，但通訊端本身不是執行緒安全的，每個通訊端只能在創建它的執行緒中使用。應用程式結束前必須銷毀上下文 (zmq_ctx_destroy())，這會等待所有內部通訊端關閉後才釋放資源。

ZeroMQ 的主要訊息傳遞模式：

ZeroMQ 提供了多種內建的訊息傳遞模式，這些模式由不同的通訊端類型實現：

1. 請求-回覆模式 (Request-Reply, REQ/REP)： 這是最簡單的模式，用於一對一的服務互動。客戶端 (REQ) 發送請求，伺服器 (REP) 發送回覆。這種模式是同步的，即客戶端發送請求後必須等待回覆才能發送下一個請求，伺服器接收請求後必須發送回覆才能接收下一個請求。REQ 通訊端使用循環式 (round-robin) 策略分發請求到連接的伺服器，接收回覆時使用最後一個回覆的對等端 (last-peer) 策略。REP 通訊端接收請求時使用公平佇列 (fair-queue) 策略（通常以循環式實現），發送回覆時使用最後一個回覆的對等端策略。
2. 發布-訂閱模式 (Publish-Subscribe, PUB/SUB)： 這是一種一對多的廣播模式。發布者 (PUB) 發送訊息，所有已連接並已訂閱的訂閱者 (SUB) 會收到訊息。發布者對訂閱者的存在或狀態一無所知，也不會為未連接或運行緩慢的訂閱者保留訊息。SUB 通訊端必須使用 ZMQ_SUBSCRIBE 選項設定一個或多個訂閱過濾器，只接收以過濾字串開頭的訊息。過濾是在訂閱者端進行的，這意味著訊息雖然發布了，但只有匹配的會被接收。SUB 通訊端不能發送訊息，PUB 通訊端不能接收訊息。
3. 管線模式 (Pipeline, PUSH/PULL)： 用於在多個階段之間傳輸數據，形成處理管線。通常用於實現分而治之或負載均衡。推送端 (PUSH) 將訊息發送給一系列拉取端 (PULL)，使用循環式負載均衡策略。拉取端 (PULL) 從一系列推送端接收訊息，使用公平佇列策略。PUSH 通訊端不會丟棄訊息，如果沒有可用的 PULL 端或其佇列已滿，PUSH 操作會阻塞。PULL 通訊端不能發送訊息。

進階概念與應用：

1. 多通訊端操作 (zmq_poll)： 在實際應用中，程式常常需要同時處理來自多個 ZeroMQ 通訊端或標準文件描述符 (如標準輸入) 的事件。zmq_poll() 提供了類似於 select() 或 poll() 的機制，可以監聽多個 zmq_pollitem_t 結構體中指定的通訊端或文件描述符，並在事件發生時返回，避免了阻塞在單個 zmq_recv() 呼叫上。
2. 多部分訊息 (Multi-part Messages)： ZeroMQ 支援將一個邏輯訊息分割成多個獨立的訊息幀 (message frames) 傳輸。傳送方在傳送除最後一個幀之外的所有幀時，需要設定 ZMQ_SNDMORE 旗標。接收方可以通過檢查 ZMQ_RCVMORE 通訊端選項來判斷當前接收到的幀是否是多部分訊息的最後一個。客戶端會原子性地接收整個多部分訊息，要嘛全收到，要嘛全沒收到。
3. 高水位標誌 (High Water Mark, HWM)： HWM 設定了 ZeroMQ 內部佇列（針對每個連接）能容納的最大訊息數量。這是控制記憶體使用和防止程式因發送過快而崩潰的重要機制。在 ZeroMQ 3.x 中，預設 HWM 為 1000，而在 2.x 中為無限。當達到 HWM 時，不同通訊端類型的行為不同：例如，REQ/REP 會阻塞發送操作，而 PUB 會丟棄訊息。
4. 可靠性： ZeroMQ 作為一個函式庫，其核心設計傾向於速度和靈活性，本身並不提供端到端的訊息傳送「保證」。傳統 MQ 的可靠性通常依賴於代理程式的持久化和確認機制。在 ZeroMQ 中實現可靠性需要應用程式層面的設計。例如，REQ/REP 可以通過重試機制實現一定程度的可靠性。PUB/SUB 本身是不可靠的（訂閱者可能錯過訊息），實現可靠發布訂閱通常需要引入雙向通訊模式（如 DEALER/ROUTER）來讓訂閱者與發布者互動或確認接收。心跳機制也常用於偵測對等方的存活狀態。
5. 慢速訂閱者問題 (Slow Subscribers)： 在 PUB/SUB 模式中，如果發布者的生產速度快於訂閱者的處理速度，就可能導致問題。ZeroMQ 內部會為每個慢速訂閱者積累訊息，直到達到 HWM，之後的訊息會被丟棄（TCP 傳輸）或在傳輸層處理（如 PGM）。應用程式需要感知到這種情況，例如透過監測延遲或在偵測到速度跟不上時自行中止（稱為「自殺蝸牛」模式）。
6. 多執行緒應用程式： 雖然 ZeroMQ 上下文是執行緒安全的，但通訊端不是。這意味著不能在一個執行緒中創建通訊端並在另一個執行緒中使用。典型的多執行緒 ZeroMQ 模式是在主執行緒創建上下文，然後每個工作執行緒創建自己的通訊端，並使用內部進程通訊 (INPROC) 傳輸來連接執行緒間的通訊端。
7. 訊號處理： 應用程式需要正確處理終止訊號（如 SIGINT 或 SIGTERM），以便優雅地關閉 ZeroMQ 資源（通訊端、上下文），避免記憶體洩漏或數據丢失。直接呼叫 zmq_ctx_destroy() 時，如果還有通訊端未關閉或佇列中有未發送的訊息，它會阻塞。

CZMQ 函式庫：

對於 C 語言開發者，CZMQ 是一個高階的 ZeroMQ 綁定函式庫，它在 ZeroMQ API 之上提供了一個更簡單、更安全的抽象層。CZMQ 旨在：

• 減少 ZeroMQ 2.x 和 3.x 之間的差異。
• 提供更方便的函式，例如處理字串 (zstr_send, zstr_recv 會處理空字元結尾)、多部分訊息 (zmsg)、檔案 (zfile)、雜湊表 (zhash) 和列表 (zlist)。
• 提供 zctx_t，自動處理上下文的創建與銷毀，並整合訊號處理，使得在收到 SIGINT 或 SIGTERM 時，阻塞的 ZeroMQ 呼叫（如 zstr_recv 或 zloop_start）能夠返回，允許程式進行清理。
• 提供 zloop_t，一個事件驅動的反應器模式實現，基於 zmq_poll，用於處理多個通訊端事件。

記憶體管理與偵錯：

在 C 語言中開發 ZeroMQ 應用程式需要特別注意記憶體管理。開發者必須確保在不再需要通訊端、訊息（特別是 zmq_msg_t）和上下文時，呼叫對應的清理函數 (zmq_close, zmq_msg_close, zmq_ctx_destroy) 來釋放資源，否則會導致記憶體洩漏。zmq_ctx_destroy() 會等待所有相關通訊端關閉，而 zmq_close() 會等待待處理的訊息發送完畢。像 Valgrind 這樣的工具在 Linux 上對於偵測記憶體洩漏非常有幫助，但使用時可能需要為 ZeroMQ 的內部行為設定抑制規則。

總之，ZeroMQ 是一個強大而靈活的函式庫，提供了構建高性能分布式系統所需的基本構件和通訊模式。理解其異步特性、無代理程式設計以及不同通訊端類型的工作原理，對於有效利用 ZeroMQ 至關重要。