【3.工程開發】-mq-ZeroMQ/nanomsg

在流數據轉發時，須要消息轉發系統，總體文章見：https://segmentfault.com/a/11...。zmq其實更是一種網絡包，能夠應用於：N-M的網絡路由，發佈訂閱(低成本不用代理的狀況下，代理不能單點)。併發原子通訊（storm一個任務一個線程，線程間通訊，管道模式，無鎖隊列=》後來storm改用了netty）。簡單的消息隊列（隊列滿就不能發了），不保證可靠性。
官方：http://zguide.zeromq.org/page:all
就是個網路jar包，It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast.Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks.
併發ZeroMQ應用程序不須要鎖，信號量或其餘等待狀態。異步IO實現對隊列排隊和簡單處理。
由於它不是個獨立的中間件，講解關注點不用，終點說他的通訊模型，功能實現點。後面做者又再次基礎上開發了性能更好的nanomsg。

通信模式

只有三類：

• 請求迴應模型。
  由請求端發起請求，並等待迴應端迴應請求。從請求端來看，必定是一對對收發配對的；反之，在迴應端必定是發收對。請求端和迴應端均可以是 1:N 的模型。一般把 1 認爲是 server ，N 認爲是 Client 。ZeroMQ 能夠很好的支持路由功能（實現路由功能的組件叫做 Device），把 1:N 擴展爲 N:M （只須要加入若干路由節點）。從這個模型看，更底層的端點地址是對上層隱藏的。每一個請求都隱含有迴應地址，而應用則不關心它。
• 發佈訂閱模型。
  這個模型裏，發佈端是單向只發送數據的，且不關心是否把所有的信息都發送給訂閱端。若是發佈端開始發佈信息的時候，訂閱端還沒有鏈接上來，這些信息直接丟棄。不過一旦訂閱端鏈接上來，中間會保證沒有信息丟失。一樣，訂閱端則只負責接收，而不能反饋。若是發佈端和訂閱端須要交互（好比要確認訂閱者是否已經鏈接上），則使用額外的 socket 採用請求迴應模型知足這個需求。
• 管道模型。
  這個模型裏，管道是單向的，從 PUSH 端單向的向 PULL 端單向的推送數據流。

性能考慮

這裏講下爲了優化性能作的設計點，參考https://www.aosabook.org/en/z...
針對具備長期鏈接的方案而設計的，創建鏈接所花費的時間或處理鏈接錯誤所需的時間基本上是可有可無的

內存

小消息和大消息：複製，分配

batching

能夠根據隊列排隊狀況調節。TCP的Nagle's則能夠關閉。

併發模型 actor model

zmq的設計文檔解釋了爲何多線程同時listen處理消息搶鎖等比單線程還慢，所以採用actor model的形式，每一個線程之間無共享（與cpu core綁定），只用消息通訊，數據無共享隔離，每一個有本身的lisnten

在主線程建立zmq_listener或zmq_connector(accept後判斷模式)，經過Mail Box發消息的形式將其綁定到I/O線程，I/O線程把zmq_listener或zmq_connector添加到Poller中用以偵聽讀事件.

雖然無鎖等，但帶來了很大的難度，一個cpu一個工做worker,一個cpu處理不少connection，也須要徹底異步，須要事件驅動且不能阻塞好久，=》必定要用個狀態機，重要的是關閉，與reactor相似

All objects have to become, whether explicitly or implicitly, state machines. With hundreds or thousands of state machines running in parallel you have to take care of all the possible interactions between them and—most importantly—of the shutdown process.

It turns out that shutting down a fully asynchronous system in a clean way is a dauntingly complex task. Trying to shut down a thousand moving parts, some of them working, some idle, some in the process of being initiated, some of them already shutting down by themselves, is prone to all kinds of race conditions, resource leaks and similar. The shutdown subsystem is definitely the most complex part of ØMQ. A quick check of the bug tracker indicates that some 30--50% of reported bugs are related to shutdown in one way or another.

=>nanomsg

nanomsg和zmq是一個做者，他說鏈接和線程綁定是他作的最大的錯誤，所以nanomsg去掉了這個限制。
https://nanomsg.org/documenta...
支持新協議
鏈接與線程不是一對一（處理此鏈接的線程忙就不能響應和重連，nn_usock擁有原始socket。它引用nn_work，還定義了connecting, connected, accept, send, recv, stop等一系列任務。這些任務能夠在nn_work的線程中異步執行），鏈接線程安全
內ZeroMQ使用一種很簡單的Trie結構(topic前綴匹配，路由匹配等)存儲和匹配發布/訂閱服務。當訂閱數超過10000時，該結構很快就顯現出不合理之處了。nanomsg則使用一種稱爲「基數樹（radix tree，就是trie若是隻有一個節點就合併，一個節點上有多個字符）」的結構來存儲訂閱