我正在寻找根据BSD或MIT许可证发布的ZeroMQ的Python 2.7替代品。我正在寻找支持请求 - 回复和pub-sub消息传递模式的东西。如有必要，我可以自己序列化数据。我发现Twisted来自Twisted Matrix Labs，但似乎需要一个阻塞事件循环，即reactor.run（）。我需要一个将在后台运行的库，让我的应用程序检查某些事件的消息。还有其他选择吗？
答案 0 :(得分：8)
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不同，您可以修改源代码并在不同的许可下重新发布，作为专有产品等。可以找到关于许可的更多推理here。
POSIX合规性
ZeroMQ API虽然以BSD套接字API为模型，但并不完全匹配API。 nanomsg旨在完全符合POSIX标准。
套接字表示为int，而不是void指针。
正如ZeroMQ所知，上下文并不存在于nanomsg中。这意味着更简单的API（可以在一个步骤中创建套接字）以及在单个进程中使用库在不同模块之间进行通信的可能性（考虑使用不同语言实现的插件彼此对话）。可以找到更多讨论here。
发送和接收函数（nn_send，nn_sendmsg，nn_recv和nn_recvmsg）完全匹配POSIX语法和语义。
实施语言
该库是用C而不是C ++实现的。
从用户的角度来看，这意味着不依赖于C ++运行时（libstdc ++或类似），这在受约束和嵌入式环境中可能很方便。 从nanomsg开发者的角度来看，它让生活更轻松。 由于使用了侵入式容器而不是C ++ STL容器，因此内存分配的数量大大减少。 上述内容还意味着更少的内存碎片，更少的缓存未命中等。 可以在here和here找到关于C与C ++主题的更多讨论。
可插拔传输和协议
在ZeroMQ中，没有用于插入新传输（比如WebSockets，DCCP，SCTP）和新协议（REQ/REP，PUB/SUB的对应等）的正式API。因此没有自2008年以来增加了新的运输工具。也没有实施新的协议。正式的内部传输API（请参阅transport.h和protocol.h）旨在缓解此问题，并作为创建和试验新传输和协议的基础。
请注意，这两个API仍然是新的，将来可能会进行一些调整，以使它们可以在各种场景中使用。
nanomsg实现了一个新的SURVEY协议。我们的想法是向多个对等方发送消息（＆＃34;调查＆＃34;）并等待所有对等方的响应。有关详细信息，请查看文章here。另请查看here。
在金融服务中，使用＆＃34;将来自任何人的消息传递给其他人是很常见的。一种消息传递。为了解决这个用例，在nanomsg中实现了一个新的BUS协议。查看详细信息here。
线程模型
我在ZeroMQ中所做的一个重大建筑错误是它的线程模型。每个单独的对象都由一个线程专门管理。这适用于工作线程处理的异步对象，但是，它会成为用户线程管理的对象的麻烦。该线程可用于在任意时间跨度内进行无关的工作，例如，一小时，在此期间，由它管理的对象完全卡住了。一些不幸的后果是：无法在REQ/REP协议中实现请求重新发送，PUB/SUB订阅在应用程序执行其他工作时未应用，类似。在nanomsg中，对象没有紧密地绑定到特定的线程，因此这些问题不存在。
REQ套接字无法在真实环境中真正使用，因为如果由于服务故障或类似情况而丢失消息，它们会卡住。用户必须使用XREQ来实现请求自行重试。使用nanomsg，重试功能内置于REQ套接字中。
在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实现出站流量的优先级。您可以决定将消息优先路由到特定目的地，并且仅当主要目标不可用时才回退到备用目的地。
有关详细讨论，请参阅here。
TCP传输增强功能
对TCP传输进行了一些小改进。连接时，您可以选择指定用于连接的本地接口，如下所示：
nn_connect (s, "tcp://eth0;192.168.0.111:5555")。
异步DNS
DNS查询（例如，将主机名转换为IP地址）以异步方式完成。在ZeroMQ中，这些查询是同步完成的，这意味着当DNS不可用时，整个库，包括尚未使用DNS的套接字，只是挂起。
<强>零复制
虽然ZeroMQ提供了＆＃34;零拷贝＆＃34; API，它不是真正的零拷贝。相反，它会零复制，直到消息进入内核边界＆＃34;。从那时起，数据就像标准TCP一样被复制。另一方面，nanomsg旨在支持真正的零拷贝机制，例如 RDMA （CPU旁路，直接内存到内存复制）和 shmem （使用共享内存在同一个盒子上的进程之间传输数据）。零拷贝消息传递的API入口点是nn_allocmsg和nn_freemsg函数以及传递给send / recv函数的NN_MSG选项。
高效订阅匹配
在ZeroMQ中，简单的尝试用于存储和匹配PUB / SUB订阅。订阅机制适用于多达10,000个订阅，其中简单的trie运行良好。但是，有些用户使用多达150,000,000个订阅。在这种情况下，需要更有效的数据结构。因此，nanomsg使用内存效率版本的Patricia trie而不是简单的trie。
有关详细信息，请查看此article。
统一缓冲模型
ZeroMQ有一种奇怪的双缓冲行为。传出和传入数据都存储在TCP的tx / rx缓冲区中的消息队列和中。例如，如果您想限制传出数据的数量，则必须同时设置ZMQ_SNDBUF和ZMQ_SNDHWM套接字选项。鉴于两者之间没有语义差异，nanomsg仅使用TCP（或等效的）缓冲区来存储数据。
可扩展性协议
最后，在哲学层面，nanomsg旨在实现不同的可扩展性协议＆＃34;而不是一个通用的网络库。具体做法是：
不同的协议是完全分离的，您无法将REQ套接字连接到SUB套接字或类似的。
每个协议都包含一个具有明确定义的先决条件的分布式算法（例如＆＃34;服务必须是无状态的＆＃34;在REQ/REP的情况下）和保证（如果REQ套接字保持活动请求将是最终处理）。
部分故障由协议处理，而不是由用户处理。实际上，它对用户是透明的。
协议的规范位于/ rfc子目录中。
目标是通过IETF标准化协议。
没有通用的UDP类套接字（ZMQ_ROUTER），您应该使用L4协议来实现这种功能。