你有没有在银行忙的时候排队？你会排队等候的。
“但是，”你可以说，“增加更多的员工来处理更多的客户难道没有意义吗？是不是因为增加员工的成本要比使用队列的成本更高，而且要牺牲一点响应时间？”
那是正确的。根据每天到达的高峰客户数量，为一家银行配备员工的成本可能相当高。这一级别以下的员工和一些客户排队等候更便宜。
而且，每天的客户数量也不是100%可预测的。队列允许多余的需求等待而不会破坏系统。
队列支持解耦。
例如，想象一个在线商店，顾客在那里购买商品。他们选择商品，提供信用卡号码，然后单击“购买”。如果信用卡被拒绝，网店可以立即提示他们重新输入号码。此交互必须在客户仍在线时立即进行。
但是，在生成发票、将记录添加到会计系统并将库存从货架上拉下来时，客户无需等待。这可以从订购过程中分离出来。一个很好的方法是将订单推送到一个队列中，这个队列可以由下一个系统处理。
如果这个“下一个系统”此时恰好处于离线状态，就没有理由取消整个销售。当“下一个系统”重新联机时，可以处理事务。这比仅仅因为一个组件（不需要立即使用）出现故障而导致整个过程失败要好得多。
一句话：排队很好。它们能够更好地处理故障。它们使事情更有弹性（只需等待几分钟，然后再试一次！）。当进程与队列体系结构兼容时，应该始终使用它们。

让我们做一些场景
场景1没有队列：
你请求一个端点/blabla/do eveything/
此请求是否有效
从非常慢的ftp下载图像，例如1.5秒（可能出错，重试吗？添加+x秒）
将图像附加到电子邮件
发送电子邮件（3秒），例如1秒（can错误，重试？添加+x秒）
收到确认>将确认存储到第三家公司跟踪资料，例如1.5（can错误，重试？添加+x秒）
跟踪确认时，请从另一家第三方公司更新数据以用于大数据目的，例如2秒（是否会出错，是否重试？添加+x秒）
... 你明白了吗
返回响应，如11秒后（这是为了慢）或更多或超时时，一切都失败了
最终用户说20年前互联网更快了，也许我需要改变我的互联网连接或改变我的16个线程
场景2：尽可能地排队：
你请求一个端点/blabla/do eveything/
此请求是否有效
队列作业“什么都做”，例如0.02秒
返回小于0.250秒的响应
最终用户说，是网站/应用程序太快，我可以保持我的56k互联网连接
在队列/事件系统中，一个失败的作业可以稍后重试，而不影响最终用户您可以暂停作业，在原始消息后添加无限数量的任务/步骤，从而提高容错性
使用queue将使您有一个更好的微/纳米服务体系结构，更好的测试，因为，您可以测试单个作业，插入一个完成所有操作的完整控制器。。。
是啊，也许是工作多了，思考多了，但一到最后就不用再去想假期时的工作了