一个高性能、轻量级的分布式内存队列系统--beanstalk

简介:

 Beanstalk是一个高性能、轻量级的、分布式的、内存型的消息队列系统。最初设计的目的是想通过后台异步执行耗时的任务来降低高容量Web应用系统的页面访问延迟。其实Beanstalkd是典型的类Memcached设计,协议和使用方式都是同样的风格。其基本设计思想很简单:高性能离不开异步,异步离不开队列,而内部都是生产者-消费者模式的。

背景介绍:

现在市面上有很多消息队列系统了。常用的有ActiveMQ, RabbitMQ,ZeroMA,Kafka,RocketMQ。Redis之父最近又开源了一个Disque。我之前在乐视用的是apache的qpid。但是之所以各个系统都在流行,还要看其侧重点。

其中ActiveMQ可以称之为传统型,它们完全支持JMS和AMQP规范。

JMS即Java消息服务(Java Message Service)应用程序接口。它是Java平台上有关面向消息中间件(Message Oriented Middleware,缩写为MOM)的技术规范,它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。(*我这里说了,JMS是应用程序接口,就是API,API就意味着是和编程语言绑定的)

JMS的体系架构由JMS提供者、JMS客户、JMS生产者、JMS消费者、JMS消息、JMS队列、JMS主题组成。

JMS对象模型包含:连接工厂、JMS连接、JMS会话、JMS目的、JMS生产者和消费者和JMS消息。其中大家最关心的是JMS消息的两种模型:点对点(point to point, queue)和发布/订阅(publish/subscribe, topic)。这两者之间的区别就是点对点模式是生产者发送一条消息到queue,一个queue可以有很多消费者,但是一个消息只能被一个消费者接收,当没有消费者可用时,这个消息会被保存直到有一个可用的消费者,所以queue实现了一个可靠的负载均衡。而发布订阅模式是发布者发送到topic的消息,只有订阅了topic的订阅者才会收到消息。topic实现了发布和订阅,当你发布一个消息,所有订阅这个topic的服务都能得到这个消息,所以从1到N个订阅者都能得到这个消息的拷贝。

AMQP(高级消息队列协议),和JMS的区别在于:JMS只是java平台的方案,AMQP是一个跨语言的协议。由于跨语言的特点,降低了企业和系统集成的开销。所以现在的消息队列系统支持AMQP的多,支持JMS的少。

AMQP的特征是面向消息,队列化,消息模型(和JMS一样:点对点和发布订阅),可靠性和安全性。它提供了三种消息传递保证方式:最多一次,至少一次和精确一次。

我们经常在使用消息队列的时候提到的broker是对实现了AMQP协议的服务端的称呼。其基本结构如下图。

Beanstalk介绍:

那下面开始说beanstalk了。首先说beanstalk其实并不是JMS规范的,也并不严格遵守AMQP协议。有人说Beanstalk之于RabbitMQ,就好比Nginx之于Apache。它更简单,轻量级,高性能,易使用。但是相比kafka,数据处理能力还是有差距,所以我们现在其实在逐渐替代它。但它有些很易用的特殊功能,后面会讲到。

Beanstalk主要包括4个部分。

1> job:一个需要异步处理的任务,需要放在一个tube中。

2> tube:一个有名的任务队列,用来存储统一类型的job,是producer和consumer操作的对象。

3> producer:job的生产者,通过put命令来将一个job放到一个tube中。

4> consumer:job的消费者,通过reserve、release、bury、delete命令来获取job或改变job的状态。

刚才说Beanstalk有一些特殊的好用功能。那就是它支持任务优先级(priority)、延时(delay)、超时重发(time-to-run)和预留(buried),能够很好的支持分布式的后台任务和定时任务处理。这些特性是和beanstalk工作过程密切相关。

Beanstalk的一个job的生命周期有READY、RESERVED、DELAYED、BURIED四种。

当producer直接put一个job时,job就是READY状态,等待consumer来处理。如果选择延迟put,job就先到DELAYED状态,到指定时间再READY。consumer获取了READY的job,此状态就为RESERVED。这样其他consumer不能再操作此job。当consumer完成该job后,可以选择delete、release或者bury。

delete之后,job不能再获取。release的job可以重新迁移或延迟迁移回READY。bury的job可以被休眠,需要的时候再READY或者delete掉。

Beanstalk使用场景:

用作延时队列:比如可以用于如果用户30分钟内不操作,任务关闭。

用作循环队列:用release命令可以循环执行任务,比如可以做负载均衡任务分发。

用作兜底机制:比如一个请求有失败的概率,可以用Beanstalk不断重试,设定超时时间,时间内尝试到成功为止。

用作定时任务:比如可以用于专门的后台任务。

用作异步操作:这是所有消息队列都最常用的,先将任务仍进去,顺序执行。 


原文发布时间为:2017-10-11

本文作者:佚名

本文来自云栖社区合作伙伴“51CTO”,了解相关信息可以关注。

相关文章
|
4月前
|
Kubernetes 大数据 调度
Airflow vs Argo Workflows:分布式任务调度系统的“华山论剑”
本文对比了Apache Airflow与Argo Workflows两大分布式任务调度系统。两者均支持复杂的DAG任务编排、社区支持及任务调度功能,且具备优秀的用户界面。Airflow以Python为核心语言,适合数据科学家使用,拥有丰富的Operator库和云服务集成能力;而Argo Workflows基于Kubernetes设计,支持YAML和Python双语定义工作流,具备轻量化、高性能并发调度的优势,并通过Kubernetes的RBAC机制实现多用户隔离。在大数据和AI场景中,Airflow擅长结合云厂商服务,Argo则更适配Kubernetes生态下的深度集成。
564 34
|
2月前
|
关系型数据库 分布式数据库 数据库
|
1月前
|
缓存 监控 Linux
CentOS系统如何查看当前内存容量。
以上方法都不需要特殊软件或者复杂配置即可执行,在CentOS或其他Linux发行版中都适合运行,并且它们各自透露出不同角度对待问题解答方式:从简单快速到深入详尽;从用户态到核心态;从操作层数到硬件层数;满足不同用户需求与偏好。
201 8
|
2月前
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
分布式新闻数据采集系统的同步效率优化实战
|
2月前
|
存储 缓存 监控
手动清除Ubuntu系统中的内存缓存的步骤
此外,只有系统管理员或具有适当权限的用户才能执行这些命令,因为这涉及到系统级的操作。普通用户尝试执行这些操作会因权限不足而失败。
441 22
|
6月前
|
监控 Linux Python
Linux系统资源管理:多角度查看内存使用情况。
要知道,透过内存管理的窗口,我们可以洞察到Linux系统运行的真实身姿,如同解剖学家透过微观镜,洞察生命的奥秘。记住,不要惧怕那些高深的命令和参数,他们只是你掌握系统"魔法棒"的钥匙,熟练掌握后,你就可以骄傲地说:Linux,我来了!
221 27
|
6月前
|
存储 编解码 安全
阿里云高性能企业级甄选Intel第八代计算型c8i、通用型g8i和内存型r8i实例简介
计算型c8i、通用型g8i和内存型r8i实例是阿里云推出的高性能企业级甄选Intel第八代云服务器实例,采用CIPU+飞天技术架构,搭载最新的Intel 第五代至强可扩展处理器(代号EMR),性能进一步大幅提升,同时拥有AMX加持的AI能力增强,并在全球范围率先支持TDX机密虚拟机能力,实现了AI增强和全面安全防护的两大特色优势。本文将为您介绍这三个实例规格的性能、适用场景及最新活动价格以及选择指南,以供选择参考。
264 18
|
10月前
|
缓存 Java Linux
如何解决 Linux 系统中内存使用量耗尽的问题?
如何解决 Linux 系统中内存使用量耗尽的问题?
816 59
|
10月前
|
Linux
如何在 Linux 系统中查看进程占用的内存?
如何在 Linux 系统中查看进程占用的内存?
1357 58
|
8月前
|
存储 运维 安全
盘古分布式存储系统的稳定性实践
本文介绍了阿里云飞天盘古分布式存储系统的稳定性实践。盘古作为阿里云的核心组件,支撑了阿里巴巴集团的众多业务,确保数据高可靠性、系统高可用性和安全生产运维是其关键目标。文章详细探讨了数据不丢不错、系统高可用性的实现方法,以及通过故障演练、自动化发布和健康检查等手段保障生产安全。总结指出,稳定性是一项系统工程,需要持续迭代演进,盘古经过十年以上的线上锤炼,积累了丰富的实践经验。
605 7

热门文章

最新文章