原文连接 http://www.aosabook.org/en/zeromq.htmlhtml
ZeroMQ 是一个消息系统,或者‘面向消息的中间件’。普遍应用于金融服务,游戏开发,嵌入式系统,学术研究和航空航天领域。服务器
消息系统基本上用于应用程序的即时消息传递,应用程序决定将事件传递给另外一个应用程序(或多个应用程序),将要发送的数据组装,点击‘发送’按钮,而后消息系统来处理剩余的问题网络
与及时消息不一样,消息系统没有GUI,假定在端点出现故障时没有人进行智能干预。所以,消息系统必须是容错的,并且比普通的及时消息要快的多 。架构
ZeroMQ最初被构想为股票交易中的超快速消息传递系统,因此重点是极端优化。该项目第一年是设计基准方法,试图定义尽量高效的体系结构。app
后来,大概是在第二年,重点转移到提供一个通用的系统,用于构建分布式应用程序和支持任意消息传递模式,多种传输机制,任意语言绑定等less
在第三年,重点是提升可用性和扁平化学习曲线。咱们采用了BSD套接字API,试图清理我的消息模式的语义等等。分布式
但愿本章能洞察以上三个目标是如何转化为ZeroMQ的架构的,并为那些正在解决一样问题的人提供一些建议。性能
Zero是有一个库,不是一个消息服务器。学习
咱们的主要关注点是性能:若是中间有一个服务器,每条消息将两次经过网络(发送者到代理,代理到接收者),包括延迟和吞吐量的损失。若是全部的消息都必须经过代理,在某些时候,必定会成为瓶颈。优化
其次是关于大规模部署:当部署跨越组织边界时,管理整个消息流的中心管理概念就再也不适用。任何公司都不肯意将控制权让与其余公司的服务器;有商业秘密,也有法律责任。实际的结果是,每一个公司都有一个消息服务器,用手写的网桥链接其余公司的消息系统。整个生态系统所以四分五裂,为每一家相关公司维护大量桥梁并不能使状况好转。为了解决这个问题,咱们须要一个彻底分布式的体系结构,即每一个组件均可能由不一样的业务实体管理。考虑到基于服务器的体系结构中的管理单元是服务器,咱们能够经过为每一个组件安装一个单独的服务器来解决这个问题。在这种状况下,咱们能够经过使服务器和组件共享相同的流程来进一步优化设计。咱们最终获得的是一个消息传递库。
当咱们知道如何在没有中央服务器的状况下进行消息传递时,MQ就开始了。从一开始,MQ就是一个库,而不是一个应用程序。
经验教训是,当启动一个新项目时,若是可能的话,您应该选择库设计。从一个库中经过一个简单的程序调用它很容易,可是,从一个现有的可执行文件中建立一个库几乎是不可能的。库为用户提供了更大的灵活性,同时也为他们节省了没必要要的管理工做。
全局变量在库中不能很好地发挥做用。一个库可能在这个过程当中加载好几回,但即便如此,也只有一组全局变量。下图显示了从两个不一样和独立的库中使用的ZeroMQ库。而后应用程序使用这两个库。
当出现这种状况时,这两个实例都会访问相同的变量,从而致使竞争条件、奇怪的失败和未定义的行为。
为了防止这个问题,ZeroMQ库没有全局变量。相反,库的使用者负责显式地建立全局状态。包含全局状态的对象称为上下文。虽然从用户的角度来看,上下文看起来相似于一个工做线程池,但从MQ的角度来看,它只是一个对象,用来存储咱们碰巧须要的任何全局状态。在上面的图片中,libA和libB都有本身的上下文。
这里的经验很明显:不要在库中使用全局状态。若是您这样作了,那么在同一进程中实例化两次库时,它可能会异常。