Эффективный макет для распределенного сервера Python?
Если бы я хотел, чтобы Python был распределен между несколькими процессорами на нескольких компьютерах, какой был бы мой лучший подход? Если бы у меня было 3 восьмиъядерных сервера, это означало бы, что мне пришлось бы запускать 24 процесса Python. Я бы использовал многопроцессорная библиотека, и для обмена объектами, похоже, лучшей идеей было бы использование менеджера. Я хочу, чтобы все узлы работали вместе как один большой процесс, поэтому один менеджер был бы идеальным, но это дало бы моему серверу единую точку отказа. Есть ли лучшее решение? Будет ли хорошей идеей репликация хранилища объектов менеджера?
Кроме того, если менеджер будет выполнять все запросы к базе данных, имеет ли смысл разместить его на том же компьютере, что и база данных?
Ответы 3
Я думаю, было бы полезно больше информации о том, что вы обслуживаете, какую базу данных вы бы использовали, какие у вас требования к задержке / пропускной способности и т. д. Многое зависит от ваших требований: например. если ваша система является типичным сервером, на котором много операций чтения и не так много записей, и у вас нет проблем с чтением слегка устаревших данных, вы можете выполнять локальные чтения из кеша для каждого процесса и отправлять записи только в база данных, транслируя результаты обратно в кеши.
Для начала, я думаю, это зависит от того, что должен делать менеджер. В конце концов, беспокоиться об отдельных точках отказа может быть бессмысленно, если ваша система настолько тривиальна, что отказ не произойдет, если не произойдет катастрофический отказ оборудования. Но если у вас есть только один, имеет смысл разместить его на том же компьютере, что и база данных. Вы уменьшаете задержку, и ваша система не сможет выжить, если одна выйдет из строя без другой.
У вас есть две основные проблемы при распределении процессов:
- Координация работы, которая разделяется, распределяется и повторно собирается (можно сказать, отображена и сокращена)
- Обмен правильными данными в реальном времени между зависимыми процессами
Ответ на первый вопрос во многом будет зависеть от того, какую обработку вы выполняете. Если его легко разделить по горизонтали (т.е. вы можете разделить большую задачу на несколько меньших задач независимый), балансировщик нагрузки, такой как HAProxy, может быть удобным способом распределения нагрузки.
Если задача не является тривиально горизонтально разбиваемой, я сначала посмотрю, подойдут ли мне существующие инструменты, такие как Hadoop. Распределенное управление задачами - сложная задача, и колесо уже изобретено.
Что касается № 2, совместного использования состояния между процессами, ваша жизнь будет намного проще, если вы поделитесь абсолютным минимумом, а затем поделитесь им только явно и четко определенным образом. Я бы лично использовал SQLAlchemy, поддерживаемый выбранной вами РСУБД, даже для самых небольших задач. Интерфейс запросов достаточно мощный и удобный как для небольших, так и для крупных проектов.
После факта сейчас, но, возможно, не помешает упомянуть Параллельный Python
Кажется, суть вашего вопроса заключается в том, как делиться объектами и состоянием. Было бы очень полезно получить дополнительную информацию, в частности размер, частоту, скорость изменений и источник данных.
Для разделяемой памяти между машинами вы, вероятно, захотите посмотреть memcached. Вы можете хранить свои данные и быстро и легко получать к ним доступ из любого рабочего процесса.
Если ваш сценарий представляет собой более простую модель распределения заданий, вы можете захотеть взглянуть на сервер очередей - поместите свои задания и связанные с ними данные в очередь и попросите рабочих забирать задания из очереди. Beanstalkd, вероятно, хороший выбор для очереди, и вот учебник начиная.
Вы должны запускать программу с одного сервера. Как вы планируете запустить процесс на другом сервере?