因此，我试图了解Queue解决了哪些实际问题。通过阅读Google的所有信息，我获得了高级知识。
因此，我正在研究公司A的体系结构，例如，他们在Job Queuing中有不同的用例
为什么以后再处理？
这是我的最佳猜测...
假设这是一个有效的用例，难道不应该添加更多服务器来处理更多“事物”吗？是否是因为添加更多的服务器比使用Queue并牺牲一点响应时间要贵得多？
给出我的用例示例，队列还能为他们解决什么其他问题？
你有没有在一家繁忙的银行排队？您将在队列中等待。
“但是，您可能会说，”增加更多的员工来处理更多的客户是没有道理的吗？是因为增加更多的员工比雇用Queue并牺牲一点响应时间要更昂贵？“
那是正确的。根据每天要到达的客户峰值为银行配备人员可能会非常昂贵。对于低于此级别的人员而言，它更便宜，并且有一些客户排队等候。
此外，每天的客户数量不是100％可预测的。队列允许过多的需求等待而不会中断系统。
队列启用解耦。
例如，想象一个在线商店客户在其中购买商品的地方。他们选择项目，提供信用卡号，然后单击“购买”。如果信用卡被拒，在线商店可以立即提示他们重新输入该号码。客户必须在线时，必须立即进行此交互。
但是，在生成发票，将记录添加到会计系统并从库存中取出库存时，不需要让客户等待。可以在订购过程中decoupled。这样做的一个好方法是将订单推入队列，该队列可以由下一个系统处理。
如果该“下一个系统”目前正处于离线状态，则没有[[没有理由取消全部销售。当“下一个系统”重新联机时，可以处理交易。这比使一个组件（不需要立即使用）发生故障而使整个过程失败要好得多。
底线：
队列为[[excellent。它们可以更好地处理故障。它们使事情更具弹性（只需等待几分钟，然后重试！）。当流程与排队体系结构兼容时，应始终使用它们。无队列的情况1] :: >>
您请求端点/ blabla / do-eveything /
将图像附加到电子邮件中
发送电子邮件（3秒）例如1秒（是否可以出错，重试？添加+ X秒）
收到确认>商店对第三家公司的跟踪确认例如1.5（可以出错，重试吗？加+ X秒）
跟踪确认后，出于大数据目的而从另一家第三方公司更新您的数据例如2秒（是否可以出错，重试？添加+ X秒）
...您会想到的
[最终用户说20年前互联网速度更快，也许我需要更改互联网连接或更改我的16个线程
方案2可以将所有内容排队
此请求要做
最终用户说这是网站/应用程序太快了，我可以保持56K互联网连接
与队列一起使用将为您提供更好的微/纳米服务体系结构，更好的测试，因为您可以测试单个作业，包括可以执行所有操作的完整控制器...