Эффективный макет для распределенного сервера python?

Question

Если бы я хотел, чтобы Python был распределен по нескольким процессорам на нескольких компьютерах, каким был бы мой наилучший подход?Если бы у меня было 3 восьмиядерных сервера, это означало бы, что мне пришлось бы запускать 24 процесса python.Я бы использовал многопроцессорная библиотека, и для совместного использования объектов, похоже, лучшей идеей было бы использовать менеджер.Я хочу, чтобы все узлы работали вместе как один большой процесс, поэтому идеально было бы использовать одного менеджера, но это дало бы моему серверу единственную точку отказа.Есть ли лучшее решение?Было бы хорошей идеей реплицировать хранилище объектов менеджера?

Кроме того, если менеджер собирается выполнять все запросы к базе данных, имеет ли смысл размещать его на том же компьютере, что и база данных?

Answer 1

При распределении процессов перед вами стоят две основные проблемы:

1. Координирует работу, которую разделяют, распределяют и повторно собирают (можно сказать, отображают и сокращают).
2. Совместное использование правильных оперативных данных между взаимозависимыми процессами

Ответ на вопрос № 1 будет во многом зависеть от того, какую обработку вы выполняете.Если он легко разделяется по горизонтали (т. е.вы можете разделить большую задачу на несколько независимый меньшие задачи), балансировщик нагрузки, подобный Хапрокси возможно, это удобный способ распределить нагрузку.

Если задача не является тривиально разделяемой по горизонтали, я бы сначала посмотрел, есть ли существующие инструменты, такие как Хадуп, сработало бы у меня.Правильно распределенное управление задачами - сложная задача, и колесо уже изобретено.

Что касается # 2, совместного использования состояния между процессами, ваша жизнь будет намного проще, если вы разделите абсолютный минимум, а затем только делитесь им явно и четко определенным образом.Я бы лично использовал SQL - алхимия поддерживается выбранной вами СУБД даже для решения самых маленьких задач.Интерфейс запросов достаточно мощный и безболезненный как для небольших, так и для крупных проектов.

Answer 2

Я думаю, что было бы полезно получить больше информации о том, что вы обслуживаете, какую базу данных вы бы использовали, какие у вас требования к задержке / пропускной способности и т. д. Многое зависит от ваших требований: например, , если ваша система представляет собой типичный сервер, который имеет много операций чтения и не так много операций записи, и у вас нет проблем с чтением слегка устаревших данных, вы можете выполнять локальные операции чтения в кэш-памяти для каждого процесса и отправлять только записи в база данных, транслирующая результаты обратно в кеши.

Для начала я думаю, что это зависит от того, что должен делать менеджер. В конце концов, беспокоиться об отдельных точках сбоя может быть бессмысленно, если ваша система настолько тривиальна, что сбой не произойдет, за исключением катастрофического сбоя оборудования. Но если он у вас есть, иметь его на той же машине, что и база данных, имеет смысл. Вы уменьшаете время ожидания, и ваша система не может выжить, если один из них выйдет из строя без другого.

Answer 3

Кажется, суть вашего вопроса в том, как делиться объектами и состоянием. Было бы очень полезно получить дополнительную информацию, в частности размер, частоту, скорость изменения и источник данных.

Что касается общей памяти с несколькими компьютерами, вы, вероятно, захотите взглянуть на memcached . Вы можете хранить свои данные и быстро и легко получать к ним доступ из любого рабочего процесса.

Если ваш сценарий представляет собой более простую модель распределения заданий, вы, возможно, захотите взглянуть на сервер очередей - поместите свои задания и связанные с ними данные в очередь и попросите работников забирать задания из очереди. Beanstalkd , вероятно, является хорошим выбором для очереди, а вот начало работы учебное пособие.