在阅读本文前，假设您对数据结构有一定认识．集中队列的模式是基本松耦合思想实现用户从界面提交命令请求到后端服务异步处理的方式．这个模式是CQRS模式的子集．这个模式用于允许用户交互式处理更新，甚至在Web服务器运行慢下．这是一个异步模型，发送者不需要为一个响应而等待．有助于用户界面保持一致快速响应．
这种模式通常应用于Web应用程序通讯，Web层与服务层之间解耦．这种方法是简单，但有在分布式系统中很多挑战．其中一个挑战是所有服务调用必须在一个web请求完前完成．这个模型也需要服务的伸缩性与可用性满足或超过脆弱的第三方服务与web层. 任何不可以靠的或运行慢的服务层将会毁掉整个web层中的用户体验，同时对伸缩性有负面影响．
解决方案是异步通讯．Web层发送命令来服务层，在这儿命令是一个做某事的请求．例如，创建一个新帐户，增加图片，更新状态，下订单，取消订单．命令发出去是以一个消息存储于Queue之中．Queue是简单的数据结构，通常２个基本操作:add与remove．最先插入的元素将是最先被删除的元素；反之最后插入的元素将是最后被删除的元素，因此队列又称为“先进先出”（FIFO—first in first out）的线性表。
发送者不需要一个web用户界面．它可以是移动应用．例如，通用REST API通讯．也可以有多个发送者与接收者．
如上图，Web层增加消息到Queue．服务层从Queue上删除与处理消息．Queue为大量的命令消息提供了缓冲，web层的工作能快速减负，服务层也不容易超载．服务层花时间在有效资源下只处理新的消息．
接收者的编程模型
1. 从Queue上获取下一个有效消息
2. 处理消息
3. 从Queue上删除消息
实现上是先dequeues消息, 然后删除消息. 为什么分两个阶段才删除呢？这是确保至少一次处理
下面让我们再来看张图，Queued Message Handler示意图:
关于长时间处理任务
一些Queue服务支持在Queue上更新消息．为了实现多个步骤处理，每个步骤完成，它能顺便更新Queue中消息并标识它的最后完成一步．一个简单的例子，你能设计消息对象时可包含一个LastCompletedStep字段，你的应用程序能用它来追踪进度．如果进程被打断，更新LastCompletedStep字段的消息将在dequeued时返回; 消息处理能恢复LastCompletedStep相当于从新开始．
在对伸缩性要求高的情况下，Queue自己能变成瓶颈，这时需要多个Queue的实例，这不需要更改核心的模式．
总结
这个模式用于你的应用程序各层之前的解耦，特别是web(用户界面)层与做业务处理的服务层．它不适用于路由，只读页面请求的场景下．通讯是单向的，从web层到服务层，方便增加消息到Queue中．云服务中Queue是简化实现的．一个解耦的web层更加具有响应性与可靠性，提升用户体验．关注独立伸缩性，也允许每个层以理想的调配各层的资源．
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
