Beanstalkd FAQ 中文版

  1. 它是怎样工作的?
  2. 任务支持持久化吗?万一断电了怎么办?
  3. Beanstalkd是否从本质上支持分布式服务器?
  4. 协议是否帮助实现了阻塞,或者是客户端类库,换句话说,客户端类库本身还需要轮询吗?
  5. 如果我想轮询,在预订一个任务时可以设置处理超时吗?
  6. 什么是Tubes,他们是如何工作的?
  7. 设置待唤醒状态的目的是?我应该在什么时候用到它?
  8. 有没有一些web管理监控接口?
    1. 图形化
    2. 管理监控接口
    3. CLI
  9. TTR(job的最大处理时间)是怎样工作的?
  10. DEADLINE_SOON响应如何理解?

在团队分享关于Beanstalkd的PPT :http://pan.baidu.com/s/1dDg2edF

它是怎样工作的?

Beanstalkd就是为分布式应用提供的一个很大的待办事项列表。

如果有一个工作单元,你想推迟到之后进行(比如,发送电子邮件,向处理很慢的外部服务推送数据,从一个处理很慢的外部服务拉数据,生成高质量的图像缩略图 ),你投放该类的工作到beanstalkd,也就是“任务”。有些流程(比如web请求处理程序),“producers” ,将向队列投放任务。另外一些流程,“worker”,将从队列中取任务并运行。

任务支持持久化吗?万一断电了怎么办?

支持,你可以在启动的时候指定-b /dir/参数,beanstalkd会将所有的任务写入binlog文件。在断电的情况下,你可以用同样的参数指定重启beanstalkd 它将会恢复log中的内容。

Beanstalkd是否从本质上支持分布式服务器?

是的,尽管这是由客户端来处理,就像用memcached。Beanstalkd服务器不会知道其他运行的beanstalkd实例。

协议是否帮助实现了阻塞,或者是客户端类库,换句话说,客户端类库本身还需要轮询吗?

beanstalk协议中有一个阻塞的”reserve“(预订)命令。客户端可以尝试阅读响应,这将阻塞,直到有任务是可用的,并预订给客户端。

客户端不需要轮询。

如果我想轮询,在预订一个任务时可以设置处理超时吗?

是的,从1.1版本开始支持,reserve-with-timeout命令就可以。更多信息可以查看协议文档。

什么是Tubes,他们是如何工作的?

Tubes就是任务队列。

Tubes的常见用例将通过一个beanstalk实例运行完全不同的生产者和消费者,一个给定的消费者不应该处理由其他消费者投放的任务。

比如说,Producer1可以排队的任务到Tube1, Consumer1可以从这里拿到任务,完全独立于 Producer2和Consumer2正在Tube2做的事情。

设置待唤醒状态的目的是?我应该在什么时候用到它?

如果设置一个任务为待唤醒,服务器将不理会直到你踢出这个任务。任务处于待唤醒状态时,不会被预订,也不会被放回到就绪队列。

例如,当涉及大量而且无法预料的运行时间job处理时,防止服务器将一个超时任务投放到队列中是非常有用的。

如果一个客户端预订了一个任务,然后置为待唤醒,然后做的逻辑工作,然后陷入僵局,任务将无限期处于待唤醒,可人为检查,不会被另外的worker重新运行。

有没有一些web管理监控接口?

有,如下是一些管理和监控工具列表:

图形化
管理监控接口
CLI

TTR(job的最大处理时间)是怎样工作的?

TTR只是应用在一个任务将要变成预订状态的瞬间。在这种情况下,一个定时器(任务统计中称作time-left)开始从任务的TTR开始倒计时。
如果定时器到达0,该任务放回就绪队列。
如果任务在定时器跑完之前被置为等待唤醒,删除,或者释放,定时器将不再存在。
如果任务在定时器到达0之前被取到,定时器从TTR新开始倒计时。
一个没有被预订的任务的统计信息将继续包含time-left入口 ,但是它的值是没有意义的。

DEADLINE_SOON响应如何理解?

在reserve的失败的情况下有可能响应DEADLINE_SOON,说明你已经有一个预订的任务它的期限真的到了。(安全隔离接近1秒)。

如果你在预订任务时经常收到DEADLINE_SOON的错误,你应该考虑增加任务的TTR时长,这通常说明worker没有特定的TTR内完成任务的处理。也可能是你在完成任务时,没有删除任务。

可以去邮件列表看更多讨论信息。

script>