beanstalked 性能

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1796 天前的主题，其中的信息可能已经有所发展或是发生改变。

业务要用到延时队列，不知道 beanstalked 性能怎么样，有没有老哥在生产环境用过的。

队列

延时

beanstalked

性能

18 条回复 • 2021-03-09 09:18:05 +08:00

luxinxin

2020-01-23 14:42:29 +08:00 via iPhone

试过一天两百万任务，没啥问题

loveyu

2020-01-23 19:03:26 +08:00

做过压力测试，单机性能 8k/s, 纯内存。不过由于没有高可用，大佬们不给上生产

OllyDebug

2020-01-23 19:16:01 +08:00 via iPhone

生产环境千万级业务没啥压力

tt67wq

2020-01-23 19:18:56 +08:00 via iPhone

这东西不是拿来学习用的吗

babyrjw

2020-01-23 20:00:07 +08:00

@loveyu 您家现在生产用的什么哇？

babyrjw

2020-01-23 20:01:33 +08:00

@luxinxin 我大概 300/s job，一天大约 400w，延时大约 1-10 分钟，担心高峰堆积

babyrjw

2020-01-23 20:02:11 +08:00

@OllyDebug 看老哥用的稳，心里放心一些了

babyrjw

2020-01-23 20:02:42 +08:00

@tt67wq 啊？那生产一般用哇？

loveyu

2020-01-23 20:20:56 +08:00

@OllyDebug 生产走原始 DB 定时任务，一分钟一次

loveyu

2020-01-23 20:21:25 +08:00

@OllyDebug 回复错了，忽略

skypyb

2020-01-23 20:24:19 +08:00 via Android

延时用 rabbit 怎么样？可持久化，堆积量和压力承载性能都挺不错啊

babyrjw

2020-01-23 20:36:26 +08:00

@skypyb rabbit 好像只能同一队列同一延时，队首的没超时，队列中的超时也无法处理

babyrjw

2020-01-23 20:38:00 +08:00

@loveyu 额额，扫 db 好像不太适合我

loveyu

2020-01-23 20:49:20 +08:00

@babyrjw 这个要上生产也是有多个方案的，比如 redis 做持久化，然后故障恢复后从 redis 中恢复。或者直接使用 benastalk 的持久化，只用作去触发异步队列，做幂等加补偿，也是一个方案

skypyb

2020-01-23 23:10:54 +08:00 via Android

@babyrjw rabbit 有延时交换机插件的啊，可以了解一下
https://www.skypyb.com/2020/01/jishu/1323/

daimaldd

2020-01-25 01:40:59 +08:00

https://github.com/laohanlinux/beanstalkr 实现了一些命令

zibber

2020-01-26 17:48:16 +08:00

要配置一下高可用吧,以前单机任务多了容易挂

734695609

2021-03-09 09:18:05 +08:00

@skypyb 你说的是 rabbitmq_delayed_message_exchange 插件吗，这个插件用起来是很方便，不是我试过之后感觉有几个问题
1.延迟时间类型是 int，最大只能支持 24.8 天，后面的小数点被我省略了。
2.关于迁移，如果换服务器怎么办，只把队列迁移过去原来的延迟时间还在不在，因为看到作者在 github 写的
You can disable this plugin by calling rabbitmq-plugins disable rabbitmq_delayed_message_exchange but note that ALL DELAYED MESSAGES THAT HAVEN'T BEEN DELIVERED WILL BE LOST. 即把插件关闭所有尚未传递的延迟消息将丢失
3.作者说插件设计不支持十万百万场景，因为有人用这个插件支撑了太多延时队列导致延迟时间会更久，提了 issue，Current design of this plugin doesn't really fit scenarios with a high number of delayed messages (e.g. 100s of thousands or millions). See #72 for details.
所以我想问一下你们的生产环境用的是这个吗，有出现上述的问题吗，或者换了什么解决方案吗