【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若是只有一个节点就合并，一个节点上有多个字符）”的结构来存储订阅