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

Question

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

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

Answer 1

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

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

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

Если бы задача не была тривиально разделена по горизонтали, я бы сначала посмотрел, будут ли работать такие инструменты, как Hadoop , для меня. Распределенное управление задачами - трудная задача, чтобы получить право, и колесо уже было изобретено.

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

Answer 2

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

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

Answer 3

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

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

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