Dae*_*ker 4 messaging message-queue zeromq pyzmq
我正在寻找根据BSD或MIT许可证发布的ZeroMQ的Python 2.7替代品.我正在寻找支持请求 - 回复和pub-sub消息传递模式的东西.如有必要,我可以自己序列化数据.我发现Twisted来自Twisted Matrix Labs,但似乎需要一个阻塞事件循环,即reactor.run().我需要一个将在后台运行的库,让我的应用程序检查某些事件的消息.还有其他选择吗？
nanomsg一个ZeroMQ妹妹,尝试 - 同样的父亲,同样的美丽REQ/REP- 允许构建无状态服务集群以处理用户请求PUB/SUB- 将消息分发给大量感兴趣的订阅者https://github.com/tonysimpson/nanomsg-python (推荐)
https://github.com/sdiehl/pynanomsg
(截至2014/11 v0.5-beta状态 - 礼貌nanomsg.org >>> a-click-thru to the original HyperDoc )
许可
nanomsg库是MIT许可的.这意味着,与ZeroMQ不同,您可以修改源代码并在不同的许可下重新发布它,作为专有产品等.有关许可的更多推理可以在这里找到.
POSIX合规性
ZeroMQ API虽然以BSD套接字API为模型,但与API完全不匹配.nanomsg旨在完全符合POSIX标准.
套接字表示为int,而不是void指针.在ZeroMQ中已知的上下文在nanomsg中不存在.这意味着更简单的API(可以在一个步骤中创建套接字)以及在单个进程中使用库在不同模块之间进行通信的可能性(考虑使用不同语言实现的插件彼此对话).可以在这里找到更多的讨论.发送和接收功能(nn_send,nn_sendmsg,nn_recv和nn_recvmsg)完全匹配POSIX语法和语义.
实施语言
该库是用C而不是C++实现的.
从用户的角度来看,这意味着不依赖于C++运行时(libstdc ++或类似),这在受约束和嵌入式环境中可能很方便.从nanomsg开发人员的角度来看,它让生活更轻松.由于使用了侵入式容器而不是C++ STL容器,因此内存分配的数量大大减少.上述内容还意味着更少的内存碎片,更少的缓存未命中等.有关C与C++主题的更多讨论可以在这里和这里找到.
可插拔传输和协议
在ZeroMQ有对新的传输封堵没有正式的API(认为的WebSockets,DCCP,SCTP)和新的协议(同行REQ/REP,PUB/SUB等等),因此没有添加新的传输,因为2008年没有新的协议,有的已经实施.正式的内部传输API(参见transport.h和protocol.h)旨在缓解问题,并作为创建和试验新传输和协议的基础.
请注意,这两个API仍然是新的,并且可能会在将来进行一些调整,以使它们可用于各种场景.
nanomsg实现了一个新的SURVEY协议.想法是向多个对等体发送消息("调查")并等待所有对等体的响应.有关详细信息,请查看此处的文章.还看这里.在金融服务中,使用"从任何人向其他人传递消息"这种消息传递是很常见的.为了解决这个用例,BUS在nanomsg中实现了一个新的协议.在这里查看详细信息.
线程模型
我在ZeroMQ中所做的一个重大建筑错误就是它的线程模型.每个单独的对象都由一个线程专门管理.这适用于工作线程处理的异步对象,但是,它会成为用户线程管理的对象的麻烦.线程可用于在任意时间跨度(例如一小时)内进行不相关的工作,并且在此期间由其管理的对象完全卡住.一些不幸的后果是:无法在REQ/REP协议中实现请求重新发送,PUB/SUB在应用程序执行其他工作时未应用订阅等等.在nanomsg中,对象没有紧密地绑定到特定线程,因此不存在这些问题.
REQZeroMQ中的socket无法在真实环境中真正使用,因为如果由于服务故障或类似原因而丢失消息,它们会卡住.用户必须改为使用XREQ并重新执行请求.使用nanomsg,re-try功能内置于REQsocket中.在nanomsg,都REQ和REP支持取消正在进行的处理.只需发送新请求而无需等待回复(在REQ套接字的情况下)或获取新请求而不回复前一个请求(在REP套接字的情况下).在ZeroMQ中,由于其线程模型,bind-first-then-connect-second场景不适用于inproc传输.它以nanomsg固定.出于类似原因,自动重新连接不适用于ZeroMQ中的inproc传输.这个问题也在nanomsg中得到修复.最后,nanomsg试图使nanomsg套接线具有线程安全性.虽然仍然不鼓励并行使用多个线程中的单个套接字,但ZeroMQ套接字在这种情况下随机失败的方式被证明是痛苦的并且难以调试.
国家机器
nanomsg库内部的内部交互被建模为一组状态机.目标是避免在ZeroMQ中看到的难以理解的关闭机制,从而使库的开发更容易.
IOCP支持
ZeroMQ中一个长期存在的问题是内部它甚至在Windows平台上使用BSD套接字API,它是二等公民.相应地,使用IOCP将需要对代码库进行大量重写,因此,尽管进行了多次尝试,但从未实现过.IOCP应该具有更好的性能特征,更重要的是,它允许使用额外的传输机制,例如NamedPipes,这些机制无法通过BSD套接字API访问.出于这些原因,nanomsg在Windows平台上内部使用IOCP.
电平触发轮询
ZeroMQ的一个方面被证明对用户来说真的很混乱,它是通过使用ZMQ_FD文件描述符将ZeroMQ套接字集成到外部事件循环中的能力.混淆的主要原因是描述符是边缘触发的,即只有在之前没有消息并且新消息到达时才发出信号.nanomsg使用级别触发的文件描述符,只需在有可用消息时发出信号,无论过去是否可用.
路由优先级
nanomsg实现出站流量的优先级.您可以决定将消息优先路由到特定目标,并仅在主要目标不可用时才回退到备用目标.
更多讨论,参阅这里.
TCP传输增强功能
TCP传输有一个小的改进.连接时,您可以选择指定用于连接的本地接口,如下所示:
nn_connect (s, "tcp://eth0;192.168.0.111:5555").
异步DNS
DNS查询(例如,将主机名转换为IP地址)以异步方式完成.在ZeroMQ中,这些查询是同步完成的,这意味着当DNS不可用时,整个库(包括未使用DNS的套接字)都会挂起.
零拷贝
虽然ZeroMQ提供了"零拷贝"API,但它不是真正的零拷贝.相反,它是"零复制,直到消息到达内核边界".从那时起,数据就像标准TCP一样被复制.另一方面,nanomsg旨在支持真正的零拷贝机制,例如RDMA(CPU旁路,直接内存到内存复制)和shmem(通过使用共享内存在同一个盒子上的进程之间传输数据).零拷贝消息传递的API入口点nn_allocmsg和nn_freemsg函数结合NN_MSG传递给send/recv函数的选项.
高效的订阅匹配
在ZeroMQ中,简单的尝试用于存储和匹配PUB/SUB订阅.订阅机制适用于多达10,000个订阅,其中简单的trie运行良好.但是,有些用户使用多达150,000,000个订阅.在这种情况下,需要更有效的数据结构.因此,nanomsg使用内存效率版本的Patricia trie而不是简单的trie.
有关详细信息,请查看此文章.
统一缓冲模型
ZeroMQ具有奇怪的双缓冲行为.传出和传入数据都存储在消息队列和 TCP的tx/rx缓冲区中.例如,它意味着如果要限制传出数据的数量,则必须设置两个ZMQ_SNDBUF和ZMQ_SNDHWM套接字选项.鉴于两者之间没有语义差异,nanomsg仅使用TCP(或等效的)缓冲区来存储数据.
可伸缩性协议
最后,在哲学层面上,nanomsg旨在实现不同的"可扩展性协议",而不是通用的网络库.特别:
不同的协议是完全分开的,你不能连接REQsocket到SUBsocket或类似的.每个协议都包含一个具有明确定义的先决条件的分布式算法(例如,"服务必须是无状态的" REQ/REP)和保证(如果REQ套接字保持活动请求将最终处理).部分故障由协议处理,而不是由用户处理.实际上,它对用户是透明的.协议的规范位于/ rfc子目录中.目标是通过IETF标准化协议.没有通用的UDP类socket(ZMQ_ROUTER),你应该使用L4协议来实现这种功能.