在Web应用程序中使用像RabbitMQ这样的消息传递吗？

通常，消息总线（例如RabbitMQ，但不限于此）允许可靠的作业处理队列。 对于Web应用程序而言，这对您而言意味着能够随着需求的增长而扩展应用程序并保持UI快速响应的能力。 他们可以要求处理一个作业（例如，单击网页上的按钮以开始对服务器上的视频文件进行代码转换），而不是迫使用户等待处理该作业，而是向总线发送一条消息，后端服务会在队列轮到时将其拾取，并可能通知用户工作已经/将要开始。然后，您可以将控件返回到UI，以便用户可以继续使用该应用程序。 在这种情况下，您的Web界面将零负担，而只是给用户以您认为合适的方式查看过程的各个阶段的可视性（例如，作业可以以查询过程的状态逐步更新数据库记录，您可以查询并显示为您的用户）。 我假设任何遇到任何类型的大量流量的Web应用程序都将具有这种类型的基础结构。尽管存在不利因素（网络故障可能会破坏消息传递，更复杂的基础结构等），但扩展后端的优势变得越来越明显。如果您使用的是云服务，则通过订阅作业队列并仅挑选要处理的消息，使用这种类型的基础结构即可轻松添加其他消息处理程序来处理您的工作。     

我刚刚进行了一次Google搜索，并提出了以下建议： Reddit.com Digg.com Poppen.De 至少，这应该可以帮助您入门。