ZeroMQ：还在研究为什么epoll比select更好吗？

还在学socket编程吗？还在研究为什么epoll比select更好吗？

噢，不必了！

在复杂的云计算环境中，我们面临的难题远比这个复杂得多。

庞大的服务器集群作为计算云，对来来看或许只是一个简单的搜索框；而在云的内部，复杂的互联和海量的通讯，加之不稳定的网络环境，廉价服务器的低可用性——构建一个高可用性且具备伸缩能力的云计算的环境，不是那么容易的！

为什么说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.

这是最重要的，不要钱，但也可以提供商业支持。

注：

Fan out：数电里很重要的概念，“一逻辑门的输出需要驱动多个等效门的输入，称输出端接的需要驱动的等效门数为扇出F”。

扇出（fan-out）是定义单个逻辑门能够驱动的数字信号最大输入量的术语。