|
对于 Rails 开发者来说，默认会使用 Sidekiq 作为后台作业处理系统，通常来说 Sidekiq 在性能和功能方面都足够优秀。
但是还是有一些 Sidekiq 无法满足的需求，比如统一队列中的任务设置不同的优先级以及延迟调度作业等。
担心的事情还是发生了。最近一个线上业务的表现越来越差，简单说就是一个通知发生业务，需要做到有些通知需要优先发送，有些通知延迟发送。
之前开 Rails API 文档时，通过 backburner 了解到 Beanstalk，Beanstalk 是一个高性能、轻量级的、分布式的、内存型的消息队列系统。最初设计的目的是想通过后台异步执行耗时的任务来降低高容量 Web 应用系统的页面访问延迟。
基于 backburner 、beanstald 还有其他与 beanstald 相关的项目， 拼凑出了 BeanstalkMQ，目标是做一个跨语言任务调度平台。零零碎碎做了点整合工作，由于工作原因，暂时就没深入开发 BeanstalkMQ。
刚好最近的业务问题可以用 BeanstalkMQ 解决。上午还在犹豫要不要用 BeanstalkMQ 替代 Sidekiq，中午左右业务要报警了，就决定下午把部分队列任务切换到 BeanstalkMQ。
相比 Sidekiq 使用 Redis 作为消息队里，使用 BeanstalkMQ 时要自动搭建 mq 服务。beanstald 默认不提供授权认证功能，我把 beanstald mq 服务部署到 k8s 上，不再外网暴露，相对安全，然后再部署一个 beanstald mq web 管理端，基本上就把基础搭建好了。基于 backburner ，我做了一个更适合自己业务的 beanstalk_worker gem。具体队列的 worker 比较容易实现，就不再介绍了。
如果从性能上来说，BeanstalkMQ 不如 Sidekiq，这是由队列的实现机制决定的，改进的空间不大。不过 BeanstalkMQ 的特性比较丰富，比如支持延迟调度，job 优先级等。之所以说是初步替换，是因为还没用到延迟调度和 job 优先级。再观察两天，如果 BeanstalkMQ 性能和稳定性达到预期，那么就可以完全替换掉 Sidekiq 了。
由于 beanstald 的协议相对简单，所以方便实现 Go、Rust、Node.js、Python 等语言对应的客户端。
针对公司的项目，如果 Sidekiq 能满足你的需求，不建议你去折腾 BeanstalkMQ。如果是个人项目可以玩玩 BeanstalkMQ。
|