ZMQ通信模型及基本服务实现

Zmq是一个简单好用的传输组件，使得socket变成更加简洁、高效、高性能。

一.zmq，云计算时代最好的通讯库

援引自看过的一篇介绍：

为什么说ZeroMQ是云计算时代最好的通讯库呢？我们从ZeroMQ的特性来分析吧：
1.The socket library that acts as a concurrency framework.
开起来像是并行开发框架的socket库。
为什么一个通讯的库不提供socket的风格，反而看起来像是一个并行的库？
云计算不就是分布式计算嘛！
并行、多核、分布式，让计算能力不断的被扩展扩展，让数据不断地被分区分区，强大的计算能力就是这样堆出来的。并发是目前云计算这个世界的主题，所以ZMQ提供了一个并发的库，正式我们最最需要的。
如同广告所讲：客户要的不是一英寸的钻头，而是一英寸的洞。
我们要的不是通讯，而是分布式并行计算。
2. Carries messages across inproc, IPC, TCP, and multicast.
提供进程内、进程间、机器间和广播方式的消息通讯。
可以说ZMQ提供了一种强大的复杂环境适应能力。
作为一个通讯库，可能我们觉得进程内通讯和进程间通讯不是重要的。
然而，提供这些功能，使得ZMQ能够在特定的场景下提供特定的解决方案。且通讯的配置相当的简单：inproc://, ipc://, tcp://这三个通讯方案简单地在字符串中指定即可。开发者可以很容易开发出可运维的应用程序，在不同的场景下，可以仅修改配置文件来适应复杂的部署环境。
3.Connect N-to-N via fanout, pubsub, pipeline, request-reply.
在多对多的网络环境中提供多对一，发布/订阅(one-to-many)，管道(one-to-one)，请求/响应等模型。
模式，还是模式。（对于fanout这个词，我没完全理解，我觉得在网络通讯中，应该就是多对一这样的场景）
天天做网络的开发的人，可能会觉得通讯就那么三板斧，经典的模式不断在重复，可是我们仍然在具体的问题上反复写着类似的代码。
而ZMQ提供的不仅仅是这个：ZMQ就像一堆水管的转接头，在复杂的自来水供水系统中，ZMQ在每个关节灵活地适配，像水管一样接起来，把数据分开或是合并。
例如，先把数据按照pub/sub模式分发给多个服务器，每个服务器上的进程在进程内用inproc，将请求分布到多个线程上处理，如果有特别的需要，还可以把数据用ipc方式转发给同一机器上的其他进程。而完成这一切复杂的工作仅需要少少的代码。
4. Fast enough for clustered products and supercomputing.
对服务器群集和超级计算来将都足够快了
超级计算都能做，你还想干啥？
5. Asynch I/O for scalable multicore message-passing apps.
对可扩展的多核消息传递应用程序提供异步I/O支持。
在ZMQ的inproc://模式中，库提供了线程安全的消息分发机制，可以简单地把请求分发给多线程处理。
6. Large and active open source community.
拥有超大并且活跃的开源社区
记住，你不是一个人在战斗！不是……
7. 20+ languages including C, C++, Java, .NET, Python.
有超过20种以上的开发语言绑定，诸如C, C++, Java, .NET, Python
8. Most OSes including Linux, Windows, OS X.
还支持绝大多数的操作系统，例如Linux, Windows, OS X
9. LGPL free software with full commercial support.
这是最重要的，不要钱，但也可以提供商业支持。

另，PostRank的创始人兼CTO，为ZeroMQ写了个简介如下：

所有网络交互所使用的API实际上是Berkeley套接字(BSD) 。这个源自1980年代早期的协议是TCP/IP协议的最原始实现。而且可以说，在当今各操作系统中，它是受到最广泛支持的API，也是这些操作系统的核心组件之一。人们对BSD套接字的了解较多的是点对点的连接。点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等。一旦你解决了以上所有问题，你就进入应用协议层（如HTTP）的世界了，这里需要的是组帧、缓存和处理逻辑等。换言之，编写高性能网络协议的应用程序一点儿也不复杂。
如果我们能对各种套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，这不是件很好的事情吗？这正是ZeroMQ（ØMQ/ZMQ）网络库的由来：“它提供一些跨多种传输协议（如进程内通讯、IPC、TCP和广播）的套接字供你使用。你可使用多种方式实现N对N的套接字连接，譬如：扇出、发布订阅、任务分发以及请求响应。”ZeroMQ网站解释：
ØMQ是网络栈中新的一层，它是个可伸缩层，分散在分布式系统间。因此，它可支持任意大的应用程序。ØMQ不是简单的点对点交互，相反，它定义了分布式系统的全局拓扑。ØMQ应用程序没有锁，可并行运行。此外，它可在多个线程、内核和主机盒之间弹性伸缩

• ZeroMQ交互是面向消息的。它将人们每天为应用程序周而复始地进行的例行消息处理封装起来。这意味着如果当客户端套接字发送一条150KB大小的消息时，服务端套接字无需显式处理任何缓存（buffer）或组帧，即能接接收到一条完整而相同的消息。
• ZeroMQ套接字与传输协议无关：对于任何协议，只有单一且统一的发送消息和接收消息API。缺省情况下支持进程内通讯、IPC、广播和TCP。此外，协议间切换非常简单，仅需更改连接字符串的前缀即可。
• ZeroMQ套接字能感知路由和网络拓扑。因为我们不再需要显示地管理点对点的连接状态——在上面我们已经看到，所有这些都已经由ZeroMQ库封装好——所以单个ZeroMQ套接字可以绑定两个独立的端口并监听他们的入站请求消息；也可使用一个API调用向两个独立的套接字发送数据。

缺省情况下，ZeroMQ中所有的交互都是异步的。这种异步处理模型使得ZeroMQ能够将建立连接、销毁连接、重新连接的过程封装起来，同时又能实现消息传输延迟的最小化：非阻塞的含义是，应用中一般的消息处理都是并行进行的，如消息的发送、传输以及（在发送端或接收端）排队。当然，你也可以控制ZeroMQ的排队行为，只需要设定内存范围即可，甚至你还可以为每个套接字设定交换区域。所以，如果需要的话，你完全可以模拟阻塞式API，但是异步I/O是缺省的行为。

二.介绍

zmq通信场景：

• 线程之间进程内（inproc）
• 进程之间（ipc）
• 机器之间（tcp）

zmq通信模型：

• 请求-回复(Request-reply)。分为ZMQ_REQ、ZMQ_REP、ZMQ_DEALER、ZMQ_ROUTER

就是一般的C/S架构中,client与server之间一问一答的通信模式,比如最经典的echo服务.需要注意的是,client发送一个request,server必须有一个回应.

• 发布-订阅(Publish-subscribe)。分为ZMQ_PUB、ZMQ_SUB

server端作为publish端,而任何连接到服务端的client都会成为subscribe端.也就是说,server端会把当前的所有需要publish出去的消息全部发送到当前连接上去的client上.

• 管道(Pipeline)。分为ZMQ_PUSH、ZMQ_PULL

server端作为push端,而client端作为pull端.如果有多个client端同时连接到这个server,则服务器会在内部做一个负载均衡,采用平均分配的算法,将所有的消息均衡发布到client端上.

• 对立对(Exclusive pair)。分为ZMQ_PAIR

要注意的是，发布订阅模型和管道（也叫推拉）模式中，无论是server端还是client端在启动时都是不知道client实际数量的,
这就意味着,一个使用zeromq搭建的服务,可以进行”热更新”.

考虑如下一种场景.一个server端做为一组服务器集群最上层的一个proxy,起到负载均衡的作用,将请求按照它下面对应服务器集群依次派发到不同的client端进行处理.某个时刻可能处理的机器只有2台,而随着负载越来越大,可能需要3台机器了,这个时候如果使用zeromq的push-pull搭建的proxy端,则可以不用对之前搭建的server,client端进行停机,只需要新启动一个client连接上去,proxy层就会自动根据当前的机器分配平均派发任务了.cool.