这是一个创建于 4550 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果一个 job 第一次运行的时候失败，那么会被放入到一个叫做 failed 的 queue。
而这个时候你只要启动 rqworker failed 就可以进行重试。
你甚至可以加上 --burst 让这个临时的 worker 在处理完所有的 failed 任务之后就自动退出。
而这个时候你只要启动 rqworker failed 就可以进行重试。
你甚至可以加上 --burst 让这个临时的 worker 在处理完所有的 failed 任务之后就自动退出。
 |
1
muxi 2012-06-05 10:28:43 +08:00
这个组件很少人用到，在之前我的项目中做MQ选型的时候了解过，Livid真的是啥都搞啊
|
|
3
muxi 2012-06-05 13:44:38 +08:00  1
我用过三种，RabbitMQ,Beanstalk,Gearman，
目前这三个都在线上跑，总体下来都足够的稳定，也都各自有优缺点，客户端都足够的多，使用成本也不算高，如果业务量不大的话，都可以 RabbitMQ 配置集群很容易，也有易用的Web界面控制台，缺点是协议复杂，速度太慢，每秒写入大概在4000个左右，出队列就更慢了，大概2500个左右，当然，你可以通过增加Worker的数量来解决这个问题，RabbitMQ缺少Delay和优先级控制，重试机制也不好，当你启用ACK之后，如果多次没有得到回馈，这个消息就需要手动发送，我现在的解决办法就是定期重启所有Worker Beanstalk速度是非常快，协议简单，就是持久化麻烦，持久化往硬盘上写log，挂掉之后恢复巨慢，我遇到的情况是大概3G的数据恢复了十多分钟也没恢复好，最后我把log重命名然后写个程序自己导入 Gearman 严格意义上不属于Queue，只是一个任务分发的应用，但实际上Gearman内部维护了一个内存队列，也支持简单的优先级和同步与异步任务，配置一下可以实现队列信息持久化，我目前用的比较多，Gearman最大的问题是自己维护队列却没有提供查看队列的接口，哪怕是命令行接口，这导致在高速写入后，很难判定所有的Job是不是都完成了，如果配置了外部持久化存储，这个问题也容易解决，Gearman用的人比较多，性能比较优秀 RQ当初没用是因为用的人少，也没去研究任务优先级怎么搞的 |
 |
4
BeanYoung 2013-06-01 00:04:00 +08:00
貌似这个对于多任务队列且每个任务队列的task不在同一个路径下无解，且会造成死循环
|
Select Language