使用消息队列的 10 个理由 已翻译 100%

oschina 投递于 2013/08/16 08:31 (共 7 段, 翻译完成于 08-21)
阅读 111690
收藏 319
33
加载中

We’ve been working with, building, and evangelising message queues for the last year, and it’s no secret that we think they’re awesome. We believe message queues are a vital component to any architecture or application, and here are ten reasons why:

1. Decoupling

It’s extremely difficult to predict, at the start of a project, what the future needs of the project will be. By introducing a layer in between processes, message queues create an implicit, data-based interface that both processes implement. This allows you to extend and modify these processes independently, by simply ensuring they adhere to the same interface requirements.

已有 2 人翻译此段
我来翻译

2. Redundancy

Sometimes processes fail when processing data. Unless that data is persisted, it’s lost forever. Queues mitigate this by persisting data until it has been fully processed. The put-get-delete paradigm, which many message queues use, requires a process to explicitly indicate that it has finished processing a message before the message is removed from the queue, ensuring your data is kept safe until you’re done with it.

3. Scalability

Because message queues decouple your processes, it’s easy to scale up the rate with which messages are added to the queue or processed; simply add another process. No code needs to be changed, no configurations need to be tweaked. Scaling is as simple as adding more power.

已有 2 人翻译此段
我来翻译

4. Elasticity & Spikability

When your application hits the front page of Hacker News, you’re going to see unusual levels of traffic. Your application needs to be able to keep functioning with this increased load, but the traffic is anomaly, not the standard; it’s wasteful to have enough resources on standby to handle these spikes. Message queues will allow beleaguered components to struggle through the increased load, instead of getting overloaded with requests and failing completely. Check out our Spikability blog post for more information about this.

5. Resiliency

When part of your architecture fails, it doesn’t need to take the entire system down with it. Message queues decouple processes, so if a process that is processing messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. This ability to accept requests that will be retried or processed at a later date is often the difference between an inconvenienced customer and a frustrated customer.

已有 1 人翻译此段
我来翻译

6. Delivery Guarantees

The redundancy provided by message queues guarantees that a message will be processed eventually, so long as a process is reading the queue. On top of that, IronMQ provides an only-delivered-once guarantee. No matter how many processes are pulling data from the queue, each message will only be processed a single time. This is made possible because retrieving a message "reserves" that message, temporarily removing it from the queue. Unless the client specifically states that it's finished with that message, the message will be placed back on the queue to be processed after a configurable amount of time.

已有 1 人翻译此段
我来翻译

7. Ordering Guarantees

In a lot of situations, the order with which data is processed is important. Message queues are inherently ordered, and capable of providing guarantees that data will be processed in a specific order. IronMQ guarantees that messages will be processed using FIFO (first in, first out), so the order in which messages are placed on a queue is the order in which they'll be retrieved from it.

8. Buffering

In any non-trivial system, there are going to be components that require different processing times. For example, it takes less time to upload an image than it does to apply a filter to it. Message queues help these tasks operate at peak efficiency by offering a buffer layer--the process writing to the queue can write as fast as it’s able to, instead of being constrained by the readiness of the process reading from the queue. This buffer helps control and optimise the speed with which data flows through your system.

已有 1 人翻译此段
我来翻译

9. Understanding Data Flow

In a distributed system, getting an overall sense of how long user actions take to complete and why is a huge problem. Message queues, through the rate with which they are processed, help to easily identify under-performing processes or areas where the data flow is not optimal.

10. Asynchronous Communication

A lot of times, you don’t want to or need to process a message immediately. Message queues enable asynchronous processing, which allows you to put a message on the queue without processing it immediately. Queue up as many messages as you like, then process them at your leisure.

已有 1 人翻译此段
我来翻译

We believe these ten reasons make queues the best form of communication between processes or applications. We’ve spent a year building and learning from IronMQ, and our customers are doing amazing things with message queues. Queues are the key to the powerful, distributed applications that can leverage all the power that the cloud has to offer.

If you'd like to get started with an efficient, reliable, and hosted message queue today, check out IronMQ. If you’d like to connect with our engineers about how queues could fit into your application, they’re always available at get.iron.io/chat.

已有 1 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(30)

qwfys
qwfys
very good
eyesfour
eyesfour
Spikability 削峰能力
此号作废
此号作废
Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load
xway
xway

引用来自“八木”的评论

引用来自“媛媛小译”的评论

引用来自“红薯”的评论

引用来自“媛媛小译”的评论

引用来自“红薯”的评论

引用来自“媛媛小译”的评论

@红薯
Spikability这个单词似乎不是很好翻译,你有木有好的翻译?

这个还真没有。。。

那咋办?

从字面上的意思,应该跟轻量级有关,你觉得呢?

我也感觉跟轻量级有关

弹性&&轻量的?

大概是峰值处理能力吧,Spiky+ability?
mahone
mahone

引用来自“debug2012”的评论

引用来自“mahone”的评论

第2点,谈到消息队列有持久化功能
这点也是我比较想问的。消息队列有持久化功能吗?是否基本上所有的消息队列都有持久化功能?没有的话,进程死掉,或者停电,都会造成消息丢失吧。。。如果有,那是否会影响性能(磁盘读取)

rabbitmq 就有持久化功能,但是也不能保证完全安全,你想,如果数据还没有来得及写入磁盘就断电的情况下。

对。我就是这个意思。所以好奇,想问问。。。
debug2012
debug2012

引用来自“mahone”的评论

第2点,谈到消息队列有持久化功能
这点也是我比较想问的。消息队列有持久化功能吗?是否基本上所有的消息队列都有持久化功能?没有的话,进程死掉,或者停电,都会造成消息丢失吧。。。如果有,那是否会影响性能(磁盘读取)

rabbitmq 就有持久化功能,但是也不能保证完全安全,你想,如果数据还没有来得及写入磁盘就断电的情况下。
Xingo
Xingo
Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load

应用程序处理未知的和/或不一致的负荷的能力
小痴
小痴
我想请问OSC的消息队列采用的是哪种?
沙枣
沙枣
这个东西给了我一个启示,所有快速和慢速的两个进程,任务,函数,动作之间,都可以使用队列这种缓存的形式,让快的不必等,让慢的不能闲着。
fzxu_05
fzxu_05
http://blog.iron.io/2012/06/spikability-applications-ability-to.html

上不了?
返回顶部
顶部