标签: task-queue

在celeryd-multi的文档中,我们找到了这个例子:

# Advanced example starting 10 workers in the background:
#   * Three of the workers processes the images and video queue
#   * Two of the workers processes the data queue with loglevel DEBUG
#   * the rest processes the default' queue.
$ celeryd-multi start 10 -l INFO -Q:1-3 images,video -Q:4,5 data
    -Q default -L:4,5 DEBUG

(从这里:http://docs.celeryproject.org/en/latest/reference/celery.bin.celeryd_multi.html#examples)

什么是一个实际的例子,说明为什么在一个主机上有多个工作程序处理相同的队列是好的,如上例所示？这不是设置并发性的原因吗？

更具体地说,以下两行(A和B)之间是否存在实际差异？:

A:

$ celeryd-multi start 10 -c 2 -Q data

B:

$ celeryd-multi start 1 -c 20 …

在他的Google I/O 2009"App Engine上的离线处理:前瞻性"演示(视频,幻灯片)中,Brett Slatkin展示了Task Queue服务.

他说

Pub-sub系统最大化事务,解耦:

• 每秒大量小额交易
• 一对多扇出,更换接收器
• 保证订购,过滤,两阶段提交

并特别强调

我们的新API实现了排队,而不是pub-sub

我只对这些功能的一部分感兴趣:

• 一对多扇出 改变 选定/固定内部接收器处理程序
• 保证订购,过滤,两阶段提交

有针对性的目标是简化在同一Web应用程序的不同模块之间发布通知/消息.示例使用场景案例将是:

• 使支付模块知道账单的接收.
• 使用户能够跟踪他已决定关注/加注的特定域对象的更改.

在Task Queue服务之上实现这些的正确方法是什么？

试图用来python-rq支持我们的Web应用程序的后端,但推动新的工作需要很长时间 - 最多12秒.

执行enqueue_call函数调用时会发生性能损失,特别是当连接到系统的工作进程数增加(超过200)时.

系统工作原理如下:

1. 前端将作业推送到任务队列服务器.enqueue_call除了要执行的函数的实际参数之外,它还使用函数将参数传递给作业(例如timeout和ttl).
2. 多个进程(分布在多台机器上)正在运行工作程序,每个进程都在UNIX下运行screen.工作人员遵循文档中提供的模式,执行Worker.work()无限循环函数来侦听队列.
3. 在处理过程中,一些任务会产生新的任务,通常在它们运行的​​同一队列上.

关于基础设施:

• 运行此任务队列的Redis服务器专用于它.此外,禁用持久性.它运行在4 GB Rackspace服务器中.
• 在redis-benchmark具有任务队列的服务器上运行时,对于大多数基准测试,我们得到的结果平均超过20000 r/s.

在这种情况下,我们如何才能提高新工作的推动绩效？我们应该使用更好的模式吗？

我想使用django_rq和rq-scheduler离线任务,但我不确定在哪里调用rq-scheduler重复任务的能力.现在,我已将我的日程安排添加到tasks.py我的应用程序中的模块,并将其导入__init__.py中.不过,必须有更好的方法来做到这一点,对吗？

提前致谢.

我们一直在将我们的api从python移动到节点.我们在Python应用引擎apis中使用了任务队列.现在,app引擎支持node.js,您是否建议我们使用任务队列或云发布/订阅来完成任务？每种方法的优点/缺点包括可靠性,可移植性等.

我正在写一个项目,负责处理面向数据服务器的主应用程序之外的任务,这是使用Node.js在javascript中编写的.它需要处理将来安排的任务,并可能处理"现在"的任务."现在"只是意味着下一次工作人员可以使用它将对该任务进行操作,因此这可能无关紧要.工作人员将全部与外部资源交谈,一个示例工作是发送电子邮件.我们是一个小商店,我们没有大量的资源,所以我不想做的一件事是在这个过程中开始混合语言,我已经看到Node可以很容易地为我们这样做,所以这就是我们要去的东西,除非我在开​​始编码之前看到一个令人信服的理由,这很快就会出现.

所有这一切,我无法分辨是否有令人信服的理由使用基于AMQP的服务器,如OpenAMQ或RabbitMQ,比如Kue或Beanstalkd与节点客户端.那么,我们走了:

是否有令人信服的理由使用基于AMQP的服务器而不是使用像Kood的beanstalkd或redis这样的服务器？如果是的话,哪个基于AMPQ的服务器最适合我布局的架构？如果不是,哪个nosql解决方案(beanstalkd,redis/Kue)最容易设置并且部署速度最快？

一个函数如何限制其调用？如果过于频繁,则不应丢弃这些调用,而是在时间上排队并间隔开,间隔为X毫秒.我看过油门和去抖动,但他们放弃了通话而不是将它们排队等待将来运行.

有没有比process()X毫秒间隔设置方法的队列更好的解决方案？JS框架中是否有这样的标准实现？到目前为止我看过underscore.js - 没什么.

我遇到了这个错误将近一个小时，但找到了一个解决方案，导致了一个令人担忧的困境。该解决方案让我们意识到，当任务队列中有一个任务要由要替换的服务器版本提供服务时，无法运行 gcloud app deploy。

错误是：ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build XXXXXXXXXXXX status: FAILURE那个 xxxx 部分是一些自动生成的 base64 值。

解决方法是：删除任务队列中的所有任务

问题：是否有解决方法或者我必须在部署之前删除任务队列中的所有任务（就像我所做的那样）？

详细信息：服务器是用 nodejs 编写的。

我一直在学习RabbitMQ各种拓扑,但是,我找不到任何对生产者发出的动态队列创建(也就是Declare Queue)的引用.想法是根据特定事件(例如HTTP请求)动态创建队列.队列将是临时的,具有TTL集并以事件ID命名.然后,消费者可以订阅主题"event.*"并合并与其相关的所有消息.

例:

1. 收到HTTP POST"创建用户"
2. producer创建一个队列user.ID
3. 在队列中推送有关用户的所有后续消息(例如"添加用户名","添加电子邮件"......)
4. worker被分配到随机队列"user.*"并将所有内容合并到一个用户帐户中
5. TTL过期后会自动删除队列

现在,RabbitMQ的这种情况是否可行？

我们最近被迫用RQ取代芹菜,因为它更简单,芹菜给我们带来太多问题.现在,我们无法找到一种动态创建多个队列的方法,因为我们需要同时完成多个作业.因此,基本上我们对其中一条路线的每个请求都应该启动一项工作,让多个用户等待一个用户的工作完成后才能继续下一个工作是没有意义的.我们会定期向服务器发送请求,以获取作业状态和一些元数据.这样我们就可以使用进度条更新用户(这可能是一个漫长的过程,所以必须为了UX而这样做)

我们正在使用Django和Python的rq库.我们没有使用django-rq(如果使用它有优势,请告诉我)

到目前为止,我们在一个控制器中启动了一项任务,例如:

redis_conn = Redis()
q = Queue(connection=redis_conn)  
job = django_rq.enqueue(render_task, new_render.pk, domain=domain, data=csv_data, timeout=1200)

然后在我们的render_task方法中,我们根据长任务的状态将元数据添加到作业:

current_job = get_current_job()
current_job.meta['state'] = 'PROGRESS'
current_job.meta['process_percent'] = process_percent
current_job.meta['message'] = 'YOUTUBE'
current_job.save()

现在我们有另一个端点获取当前任务及其元数据并将其传递回客户端(这通过oeriodic AJAX请求发生)

我们如何在不阻碍其他工作的情况下同时运行工作？我们应该动态制作队列吗？有没有办法利用工人来实现这一目标？