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