神器篇之ZeroMQ<一>初识ZeroMQ

//

Email: admin@ofssln.com

QQ：285125896

欢迎一起交流，学习。

云计算时代最好的通讯库，没有之一。

还在学socket编程吗？还在研究为什么epoll比select更好吗？
噢，不必了！
在复杂的云计算环境中，我们面临的难题远比这个复杂得多。任何一个简单的问题放之大数据下，都是难题。低廉的服务器构建一个高可用且具备伸缩能力的云计算环境；计算节点的热插拔；大并发；负载均衡等。

1.为什么说ZeroMQ是云计算时代最好的通讯库呢？我们从ZeroMQ的特性来分析吧：

1.1.The socket library that acts as a concurrency framework.

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

2.我们怎么来学习ZeroMQ呢？

ZMQ希望用户在编写应用程序方面，更加关心消息通信而不是socket连接。在内部已经使用异步方式帮用户处理好了网络IO读写以及数据成帧，使得用户在处理的时候只需要关注消息本身。 ZMQ所支持的消息传输模型有很多种，比如push-pull,pub-sub,request-reply以及exclusive-pair,应该可以涵盖应用层面所有的消息通讯方式。同时ZMQ本身可以底层允许选择不同的通信协议， 比如tcp,ipc(进程间通信),inproc(线程间通信).

2.1首先阅读一下manual.然后看看guide里面包括很多设计细节和使用细节东西。最后可以阅读一下API reference.关于Background方面的内容也有一些whitepapers可以参考。

http://www.zeromq.org/intro:read-the-manual
http://zguide.zeromq.org/page:all
http://api.zeromq.org/2-1:_start
http://www.zeromq.org/whitepapers:multithreading-magic

2.2 ZMQ总结了几种消息通信模型可以覆盖所有的应用程序，分别是下面这几种：
Exclusive-Pair
Publish-Subscribe
Push-Pull
Request-Reply

我们会在后面仔细讨论每一种消息通信模型。

使用ZMQ之后的话不像我们所认识一样的server必须在client之前启动。在ZMQ下面的话client完全可以在server之前启动。一旦连接顺序并不按照我们所想象的那样工作的话，连接顺序是无关的时候，那么客户端和服务端这两个概念就非常模糊了。我们必须重新考虑什么是server,什么是client.ZMQ给出一个非常实际的答案。我们将socket嵌入到网络拓扑的时候，server应该是网络结构中稳定的部分，而client应该是网络结构中比较易变的部分。

2.3Example

首先我们看看ZMQ的使用情况。我们以简单的Request-Reply消息模型为例。所谓Request-Reply模型就是client发送一个消息然后等待回应，而server接收到消息然后立刻回复。 这是一个lockstep的过程，就是说中途不能够切换做另外的事情，比如client发送消息之后