在生产环境中将RabbitMQ和Celery运行在同一台服务器上

Question

我正在EC2实例上运行一个Django应用程序，该应用程序使用RabbitMQ + Celery进行任务排队。将我的RabbitMQ节点从与生产应用程序相同的EC2实例上运行是否有任何缺点？

- dietbacon

Answer 1

这个问题的答案实际上取决于你的应用程序的情境。

当你面临不同的场景时，应该考虑以下几点：

关注点的分离 在这里，我们要确保一个系统不负责运行其他系统。这包括诸如

• 如果运行所有任务的EC2实例崩溃了，将会继续运行队列中的剩余任务吗

• 如果我的RAM已满，所有系统是否仍然能够正常运行

• 我能否只扩展我的应用程序某一部分，而不必重新设计基础架构。

通过在一个系统中同时使用rabbit和django（带有某种服务，wsgi，gunicorn，waitress等），您失去了很多资源备用性。

虽然RAM和CPU可能非常充足，但IO，磁盘写入，网络写入等都有极限。这意味着，如果由于某种原因你有一个重写函数，所有其他系统都可能受到影响。如果你有一个重写RAM函数，同样适用。

所以从你的问题和我的经验中可以看出，将所有东西放在一个系统中的缺点如下:

• 多个故障点。如果您的rabbit的一个实例失败，您的队列和任务将停止工作。

• 如果您的应用程序开始产生大量流量，其他系统开始争夺资源。

• 如果任何组件出现故障，这可能意味着其他服务的停机时间。

• 系统停机意味着所有组件完全停机。

• 当您的应用程序需要更多资源时，会带来许多头疼的问题，同时最小化停机时间。

• 大量的Web流量将减缓任务运行速度

• 大量的任务运行将减慢Web请求

• 大量的IO将减慢所有事情

我通常遵循的经验法则是将单个故障点远离彼此 - 这样您只需要管理这些组件。一个好的用例是为您的应用程序使用一个EC2实例，另一个为您的worker，另一个为您的rabbit。这样，如果需要，您可以为这些组件应用较小/较大的实例。您甚至可以创建AMI并创建自动缩放组 - 如果这是您的用例。

以下是一些参考文献：

• 关注点的分离
• 现代设计结构
• 单点故障

- Giannis Katsini

Answer 2

TLDR; 如果您可以在一个EC2上运行，请这样做，但是今天使其易于扩展。

Joshnidhin和Giannis都涵盖了RAM，IO和CPU方面。

我曾经在单个实例中通过容器化运行生产应用程序，并放心地睡觉，如果明天突然有很多人想要我已经构建的东西，我可以通过在不同的实例上部署这些容器来快速扩展，而不是仅仅在单个实例上。

Docker允许您为每个容器设置CPU消耗和内存使用限制，因此您也可以确保它们不会互相干扰。

- mahoriR

Answer 3

如果我们将EC2实例从这个问题中排除，那么问题就变成了：

在我的生产应用程序上运行RabbitMQ节点是否有任何缺点？

我会说这取决于各种因素，例如工作负载及其组成、工作负载的复杂性、您是否预计使用量增长等。

如果您的工作负载表现良好，并且服务器足够大（包括应用程序和任务队列），那么为什么不呢？因为只需要管理一个服务器。请确保通过限制它们的系统资源使用来保护这两个进程。

如果您的流量不稳定，则可能需要多个服务器。在这种情况下，拥有专用服务器更好（关注点分离），因为您将不得不管理多个服务器。

现在回到EC2，以上所有内容仍然适用。 EC2使应用程序的水平扩展更加容易，因此，如果您将它们放在单独的实例上，则可以以成本效益的方式单独扩展它们。如果没有，当您扩展时将浪费资源。

- Josnidhin