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

Question

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

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

Answer 1

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

1. координирование работы, дробить, распределенный и вновь собирали (картографическую и минимизируются, вы могли бы сказать)
2. Совместному права жить данные между со-зависимыми процессами

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

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

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

Answer 2

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

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

Answer 3

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

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

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