die*_*con 11 amazon-ec2 rabbitmq amazon-web-services celery django-celery
我在EC2实例中运行Django应用，该实例使用RabbitMQ + Celery进行任务排队。从与生产应用程序相同的EC2实例运行RabbitMQ节点有任何缺点吗？
这些问题的答案实际上取决于您的应用程序的上下文。
当您面对场景时，您应该始终考虑一些事情。
关注点分离 这里，我们要确保其中一个系统不负责其他系统的运行。这包括诸如
如果运行所有东西的 ec2 实例宕机，队列中剩余的任务会继续运行吗？
如果我的 RAM 已满，所有系统是否仍能正常运行
我可以只扩展我的应用程序的一个部分，而不必重新设计基础设施吗？
通过将 rabbit 和 django（具有某种服务、wsgi、gunicorn、女服务员等）全部放在一个盒子上，您会失去很多资源应急。
虽然 RAM 和 CPU 可能很充裕，但 IO、磁盘写入、网络写入等是有限制的。这意味着如果由于某种原因你的写入功能很重，所有其他系统都可能因此受到影响。如果您对 RAM 功能进行大量写入，则同样适用。
因此，从您的问题和我自己的经验中可以看出，将事物保存在一个系统中的真正原因如下。
多点故障。如果您的一个 rabbit 实例失败，您的队列和任务将停止工作。
如果您的应用开始产生大量流量，其他系统就会开始争夺资源。
如果任何组件出现故障，这可能意味着其他服务的其他停机时间。
系统停机意味着所有组件完全停机。
当您的应用程序以最少的停机时间需要更多资源时，会遇到很多麻烦。
大量网络流量会减慢任务运行速度
大量任务运行会减慢网络请求
大量 IO 会减慢所有事情的速度
我通常遵循的经验法则是使单点故障彼此远离 - 这样您只需要管理这些组件。一个很好的用例是将一个 EC2 实例用于您的应用程序，另一个用于您的工作人员，另一个用于您的兔子。这样，如果需要，您可以只为这些组件应用更小/更大的实例。您甚至可以创建 AMI 并创建自动缩放组 - 如果这是您的用例。
这里有一些文章供参考
| 归档时间： |
|
| 查看次数： |
154 次 |
| 最近记录： |