消息队列代理RabbitMQ vs Redis


一个快速消息队列基准:ActiveMQ,RabbitMQ,HornetQ,QPID,Apollo给出了流行的消息队列代理的比较。 对RabbitMQ的共识,这是公认的,但不包括即将到来的选项之一是Redis。 有了PubSub的近期支持,它塑造了一个强有力的竞争者。

RabbitMQ的优点

♦ 高度可定制的路由

♦持续的队列

Redis的优势

♦高速由于在存储器中的数据存储

♦可以兼任这两个键值的数据存储和作业队列

因为我使用python工作,我决定使用Celery。 我试图通过增加100000消息队列,用一个工人来处理排队的消息同时测试的RabbitMQ和Redis的。 该试验运行三次,取平均值。 在使用Celery的情况下,似乎没有成为一个突发模式,即工人不能不能退出时在队列中的所有消息被处理。 所以我只好用下一个最好的逼近,在日志信息的时间戳。

tasks.py任务定义和消息代理使用
from celery import Celery
celery = Celery('tasks', broker='amqp://guest@localhost//')

celery = Celery('tasks', broker='redis://localhost//')

@celery.task
def newtask(somestr, dt, value):
pass

test.py执行实际的任务添加到队列

from tasks import newtask
from datetime import datetime
import time

dt = datetime.utcnow()
st_time = time.time()
for i in xrange(100000):
newtask.delay('shortstring', dt, 67.8)
print time.time() - st_time

celery工作通过运行以下命令获取信息

time celery -A tasks worker --loglevel=info -f tasks.log --concurrency 1
--concurrency表示有多少工人同时运行。 -f表示要使用的日志文件。 我们可以推断处理的最后一条消息采取的运行从日志时间戳的时间。 接下来,我们需要评估采取的INFO级别记录的工作人员也从花费的总时间减去它的时间。

import logging
import sys
import time
logger = logging.getLogger('MainProcess')
hdlr = logging.FileHandler('/tmp/myapp.log')
formatter = logging.Formatter('%(asctime)s %(levelname)s %(message)s')
hdlr.setFormatter(formatter)
logger.addHandler(hdlr) 
logger.setLevel(logging.INFO)

def main():
inputf = sys.argv[1]
for inputf in sys.argv[1:]:
    loglines = file(inputf).readlines()
    loglines = [line.split(']', 1)[1].strip() for line in loglines]
    st_time = time.time()
    for line in loglines:
        logger.info(line)
    print inputf, time.time() - st_time

if __name__ == "__main__":
main()

下面是结果对每个试验包括100000消息的制表。 显而易见的是,需要的RabbitMQ和Redis的时间75%用来添加消息,86%的时间处理消息。 由于该消息的处理能力几乎是相等的,该决定将仅基于功能。 也就是说,如果你想复杂的路由能力使用RabbitMQ。 如果你需要一个在内存key-value存储使用Redis。

cob.png

原文地址:http://www.zhouuu.com/664.html

0 个评论

要回复文章请先登录注册