zeromq

As we all know, a ZeroMQ socket shall not be shared among application threads . context_t instances however can. I have a multi-threaded-application and I'd like to have each thread exchange messages from time to time with a REQ/REP -socket counterparty ( event, exceptions and the like ), depending on what they are doing ( they are doing non-ZeroMQ-stuff ). To send messages to my REQ/REP -socket I use the following function ( a half-C++ half-pseudo-code ): sendMessage: bool sendMessage(std::string s) { zmq::socket_t socket(globalContext(), ZMQ_REQ); socket.connect("ipc://http-concentrator");

I am looking to implement a REQ-REP pattern with Python and ZeroMQ using multithreading. With Python, I can create a new thread when a new client connects to the server. This thread will handle all communications with that particular client, until the socket is closed: # Thread that will handle client's requests class ClientThread(threading.Thread): # Implementation... def __init__(self, socket): threading.Thread.__init__(self) self.socket = socket def run(self): while keep_alive: # Thread can receive from client data = self.socket.recv(1024) # Processing... # And send back a reply self.socket

I am trying to use zero-mq.My requirement is very simple.I want to be able to communicate between two peers in a network.I came across this program in the examples in the book. $ pub_server.py import zmq import random import sys import time port = "5556" if len(sys.argv) > 1: port = sys.argv[1] int(port) context = zmq.Context() socket = context.socket(zmq.PUB) socket.bind("tcp://*:%s" % port) while True: topic = random.randrange(9999,10005) messagedata = random.randrange(1,215) - 80 print "%d %d" % (topic, messagedata) socket.send("%d %d" % (topic, messagedata)) time.sleep(1) $sub_client.py

1.首先我们简单了解一下消息中间件的应用场景 异步处理 场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种1.串行的方式;2.并行的方式 (1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西. (2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。 假设三个业务节点分别使用50ms,串行方式使用时间150ms,并行使用时间100ms。虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回. (3)消息队列 引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理 由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。 应用解耦 场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口. 这种做法有一个缺点: 当库存系统出现故障时,订单就会失败。 订单系统和库存系统高耦合. 引入消息队列

MQ框架非常之多，比较流行的有RabbitMq、ActiveMq、ZeroMq、kafka。这几种MQ到底应该选择哪个？要根据自己项目的业务场景和需求。下面我列出这些MQ之间的对比数据和资料。 第一部分： RabbitMQ,ActiveMq,ZeroMq 比较 1、 TPS 比较 一 ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。这个结论来自于以下这篇文章。 http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/ 测试环境： Model: Dell Studio 1749 CPU: Intel Core i3 @ 2.40 GHz RAM: 4 Gb OS: Windows 7 64 bits 其中包括 持久化 消息和 瞬时 消息的测试。注意这篇文章里面提到的 MQ ，都是采用 默认配置 的，并无调优。 更多的统计图请参看我提供的文章url。 2 、 TPS 比较 二 ZeroMq 最好， RabbitMq 次之， ActiveMq 最差。这个结论来自于一下这篇文章。 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html

最近要为公司的消息队列中间件进行选型，市面上相关的开源技术又非常多，如ActiveMQ、RabbitMQ、ZeroMQ、Kafka，还有阿里巴巴的RocketMQ等。 这么多技术，如何进行选型呢？ 首先对于阿里的RocketMQ，因为是阿里开源的，对于国内开源的保持谨慎的态度，暂时不采取该中间件。 所以只能在ActiveMQ、RabbitMQ、ZeroMQ、Kafka中间选一款作为消息队列中间件。 下面从几个维度来对比下 1、社区活跃度 从目前网上的资料上看，RabbitMQ、activeMQ、ZeroMQ三者中RabbitMQ绝对是首选。 2、消息持久化 ZeroMq不支持消息持久化，ActiveMQ和RabbitMQ都支持。 3、核心技术 可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。 RabbitMq / Kafka最好，ActiveMQ次之，ZeroMQ最差。当然ZeroMQ也可以做到，不过自己必须手动写代码实现，工作量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。 4、高并发 毋庸置疑RabbitMQ最高，因为RabbitMQ是由天生具备高并发高可用特性的erlang语言实现的。 以上对比参考来源网络，大同小异。总结就是需要从RabbitMQ和Kafka之间选一款适合自己的

I want to limit the amount of memory consumed by my ZeroMQ message queues in a Python application. I know that setting the high-water mark will limit the amount that will be queued on the sender side, but is there a way to control how much will be queued on the receiver side? The Python ZeroMQ binding seems to have it set at unlimited. My test scenario: I have two python terminals that I am using for testing. One is the receiver: Python 2.5.1 (r251:54863, Aug 25 2008, 20:50:04) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more

我们先来看看第一种模式: Request-Reply Pattern 。 请求应答模式。 Request-Reply这个名字很直白，口语点说就是 一问一答 。可以使同步的遵循请求序的一问一答，也可以 是异步的不按请求序的一问一答；其中也可以包含各种不同的路由策略——让谁来回答。zeromq定义的为这个模式服务的socket有：ZMQ_REQ, ZMQ_REP, ZMQ_ROUTER以及ZMQ_DEALER. 用他们进行合理的组合，就可以实现现实世界中各种不同的请求应答模式。 分别来看： ZMQ_REQ ZMQ_REQ做的事情就是 发问 ，然后 收答 。发、收必须是严格按序进行。请求时对对端进行Round Robin，遇到异常则阻塞。官方对这个socket的总结如下： Summary of ZMQ_REQ characteristics Compatible peer sockets ZMQ_REP Direction Bidirectional Send/receive pattern Send, Receive, Send, Receive, … Outgoing routing strategy Round-robin Incoming routing strategy Last peer ZMQ_HWM option action Block ZMQ_REP ZMQ