队列并不能解决“超载”

标签: 队列 超载 | 发表时间:2014-11-26 11:40 | 作者:
出处:http://news.cnblogs.com/

文/ 马德奎 

人们总是错误地使用队列,最坏的情况是用它解决“超载(overload)”问题。 Fred Hebert 是《 Learn You Some Erlang for Great Good!》一书的作者。在这本 Erlang 入门书籍中,他结合生动的插图、恰当的实例以浅显易懂的方式讲解了技术问题。近日,他以同样的方式 阐释了为什么“队列不能解决超载”。

他将系统比作一个洗手池,如下所示:

在正常的操作下,数据只从左侧流入,出口可以处理所有数据。但在一些重大活动期间,比如圣诞节,可能会出现如下情况:

数据从左右两侧同时流入系统。如果数据输入越来越快,那么出口就可能会无法及时处理所有数据。这时,人们通常会考虑增加一个队列缓冲区(如上图的水槽)存储临时数据。但不管队列多大,持续的超载都会导致如下情况的发生:

队列满了,系统崩溃。这时候,开发人员会查看堆栈跟踪、队列、数据库查询以及调用的 API。但经过各种优化,甚至更换更大的服务器后,系统仍然无法承受这种持续的超载,因为瓶颈在出口(下图中红箭头所示的位置):

该瓶颈可能是数据库,可能是磁盘、带宽或 CPU。不消除这种瓶颈,任何优化都是徒劳。所以此时,开发人员应该做的是阻塞输入,即“反压( back-pressure)”或者丢弃数据,即“卸载(load-shedding)”。可能有人会认为,反压会招致用户的不满。但实际上,即使不主动反压,当系统负载达到一定程度后,速度也会降低,甚至崩溃。所以,虽然反压会降低用户的输入速度,但却可以保证系统的运行。另外,引入队列作为一种优化机制会违背 端到端原则。因此,开发人员应该设置更多允许超时的地方,提供故障检测方法,并将其反馈给用户。

如上图所示,开发人员可以在识别出系统瓶颈后设置相应的反压机制,避免数据流入过快。而依据检查点的不同,开发人员可以对延迟和吞吐量实现不同层次的优化。

借助反压或卸载,开发人员可以获得以下好处:

  • 合适的服务质量指标
  • 减少紧急修复的次数
  • 根据账户限制和优先通道收费的方式
  • 系统更稳定

总之,如果 API 设计考虑了端到端原则和幂等性,那么反压或卸载对调用者而言通常不会成为问题,因为它们可以安全地重试请求。


感谢 郭蕾对本文的审校。

本文链接

相关 [队列 超载] 推荐:

队列并不能解决“超载”

- - 博客园_新闻
人们总是错误地使用队列,最坏的情况是用它解决“超载(overload)”问题. Fred Hebert 是《 Learn You Some Erlang for Great Good!》一书的作者. 在这本 Erlang 入门书籍中,他结合生动的插图、恰当的实例以浅显易懂的方式讲解了技术问题. 近日,他以同样的方式 阐释了为什么“队列不能解决超载”.

RabbitMQ:镜像队列Mirrored queue

- - 飞翔的荷兰人
        在上一节 《RabbitMQ集群类型一:在单节点上构建built-in内置集群》中我们已经学习过:在集群环境中,队列只有元数据会在集群的所有节点同步,但队列中的数据只会存在于一个节点,数据没有冗余且容易丢,甚至在durable的情况下,如果所在的服务器节点宕机,就要等待节点恢复才能继续提供消息服务.

快速的消息队列 SquirrelMQ

- Le - 开源中国社区最新软件
SquirrelMQ是一个快速的消息队列.   SquirrelMQ VS Redis 入队列: SquirrelMQ:100万条数据,105S,内存使用84MB. Redis:100万条数据,156S,内存使用127MB.   出队列:   SquirrelMQ:100万条数据,230S. Redis:100万条数据,163S.

Hadoop层级队列组织方式

- - 董的博客
Dong | 新浪微博: 西成懂 | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及 版权声明. 网址: http://dongxicheng.org/mapreduce/hadoop-hierarchy-queues/. 在Hadoop 0.20.x版本或者更早的版本,Hadoop采用了平级队列组织方式,在这种组织方式中,管理员可将用户分到若干个扁平队列中,在每个队列中,可指定一个或几个队列管理员管理这些用户,比如杀死任意用户的作业,修改任意用户作业的优先级.

Feed消息队列架构分析

- - Tim[后端技术]
最近一两年,大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式,并逐渐形成几种通用的使用方式,以下介绍微博的消息队列体系. 当前的主要消息队列分成如图3部分. 1、feed信息流主流程处理,图中中间的流程,通过相关MQ worker将数据写入cache、Redis及MySQL,以便用户浏览信息流.

jdk1.5——阻塞队列应用案例

- - 行业应用 - ITeye博客
1 打印日志: 原来打印16个日志需要16秒时间,现在开启4个线程,让这16个任务在4秒内完成:. 1 将16个任务增加到 阻塞队列中. 2开启4个线程,每次从队列中获取数据. 这样主线程不停的放, 并发来的4个线程不停的取, 你可以理解为并发一次来了4个线程,每个线程取到后内部打印1S操作仍旧不变,.

redis作为消息队列的使用

- - ITeye博客
在redis支持的数据结构中,有一个是集合list. 对List的操作常见的有lpush  lrange等. 在这种常见的操作时,我们是把集合当做典型意义上的‘集合’来使用的. 往往容易被忽视的是List作为“队列”的使用情况. 反编译redis的jar包,会发现:.  pop意为“弹”,是队列里的取出元素.

高可用消息队列框架ZBUS

- - 企业架构 - ITeye博客
我们在日常开发中可以需要用到消息队列 当然我们完全可以自己写一个生产者-消费者框架 但是高可用性、实时性已经大量数据堆积时候就显得问题捉襟见肘了下面推荐的框架在我时间项目中和测试中都是非常不错那么他是什么框架呢.    zbus git地址. http://git.oschina.net/rushmore/zbus ZBUS=MQ+RPC 服务总线 1)支持消息队列, 发布订阅, RPC, 交易系统队列适配 2)亿级消息堆积能力、支持HA高可用 3)无依赖单个Jar包 ~300K 4)丰富的API--JAVA/C/C++/C#/Python/Node.JS多语言接入,支持HTTP等协议长连接入.

[转]消息队列的两种模式

- -
Java消息服务(Java Message Service,JMS)应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信. 点对点与发布订阅最初是由JMS定义的. 这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅).

消息队列设计精要

- - 美团点评技术团队
消息队列已经逐渐成为企业IT系统内部通信的核心手段. 它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一. 当今市面上有很多主流的消息中间件,如老牌的ActiveMQ、RabbitMQ,炙手可热的Kafka,阿里巴巴自主开发的Notify、MetaQ、RocketMQ等.