Координация распределенных процессов Python с использованием очередей или веб-службы REST

Question

Сервер A имеет процесс, который экспортирует n таблиц базы данных в виде плоских файлов. Сервер B содержит утилиту, которая загружает плоские файлы в базу данных устройства DW.

Процесс выполняется на сервере А, который экспортирует и сжимает около 50-75 таблиц. Каждый раз, когда таблица экспортируется и создается файл, также создается файл .flag.

Сервер B имеет процесс bash, который многократно проверяет каждый файл .flag, созданный сервером A. Он делает это, подключаясь к A и проверяя наличие файла. Если файл флага существует, сервер B извлечет файл с сервера A, распакует его и загрузит в базу данных аналитики. Если файл еще не существует, он будет спать в течение n секунд и повторите попытку. Этот процесс повторяется для каждой таблицы / файла, которые сервер B ожидает найти на сервере A. Процесс выполняется последовательно, обрабатывая один файл за раз.

Дополнительно: Процесс, который выполняется на сервере A, не может «отправить» файл на сервер B. Из-за размера файла и географических особенностей сервер A не может загрузить плоский файл в устройство DW.

Я считаю, что этот процесс громоздок и просто так может быть переписан / обновлен. Я предлагаю решение на основе обмена сообщениями. Сначала я думал, что это будет хорошим кандидатом на RabbitMQ (или тому подобное), где

• Сервер A записывает файл, сжимает его и затем создает сообщение для очереди.

• Сервер B будет подписываться на очередь и обрабатывать файлы, названные в теле сообщения.

Мне кажется, что подход, основанный на обмене сообщениями, не только сэкономит время, поскольку он устранит цикл проверки-ожидания-повторения для каждой таблицы, но также позволит нам запускать процессы параллельно (поскольку нет никаких зависимостей).

Я показал моей команде подтверждение концепции с использованием RabbitMQ, и все они были восприимчивы к использованию сообщений. Некоторые из них быстро определили другие возможности, где мы могли бы извлечь выгоду из обработки сообщений. Одной из таких областей, в которой нам было бы полезно реализовать обмен сообщениями, было бы заполнение наших измерений DW в реальном времени, а не в пакетном режиме.

Тогда мне пришло в голову, что решение на основе MQ может быть излишним, учитывая малый объем (50-75 задач). Это может быть излишним, учитывая, что наша операционная команда должна будет установить RabbitMQ (и его зависимости, включая Erlang), и это приведет к новым головным болям администрации.

Затем я понял, что это можно сделать проще с помощью решения на основе REST. Сервер A может создать файл и затем выполнить HTTP-вызов простой веб-службы (web.py) на сервере B. Сервер B может затем инициировать процесс передачи и загрузки на основе вызываемого URL-адреса. Учитывая время, необходимое для передачи, распаковки и загрузки каждого файла, я бы, вероятно, использовал многопроцессорную обработку Python для создания подпроцесса, который загружает каждый файл.

Я думаю, что решение на основе REST - это идея, учитывая тот факт, что оно проще. По моему мнению, использование MQ было бы более уместным для задач с большим объемом, но мы говорим только (на данный момент) о 50-75 операциях с потенциально большим количеством впереди.

Будет ли REST-based хорошим решением, учитывая мои требования и объем? Существуют ли другие платформы или продукты OSS, которые уже делают это? Я хочу добавить обмен сообщениями, не создавая других проблем при администрировании и разработке.

Answer 1

Посредники сообщений, такие как Rabbit, содержат практические решения для ряда проблем:

• Поддерживается несколько производителей и потребителей без риска дублирования сообщений
• атомарность и единица измерениярабочая логика обеспечивает целостность транзакций, предотвращая дублирование и потерю сообщений в случае сбоя
• горизонтальное масштабирование - большинство зрелых брокеров могут быть кластеризованы так, что на нескольких машинах существует одна очередь
• нет-обмен сообщениями рандеву - отправителю и получателю не обязательно работать одновременно, поэтому один из них может быть отключен для обслуживания без ущерба для другого
• сохранения порядка FIFO

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

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

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

Answer 2

Как упоминалось в wberry, решение на основе REST или веб-хука может быть функциональным, но не очень устойчивым к сбоям. Оплата оперативной цены за обмен сообщениями принесет долгосрочные дивиденды, поскольку вы обнаружите дополнительные проблемы, которые естественным образом соответствуют модели обмена сообщениями.

Относительно других опций OSS; Если вы рассматриваете потоковую обработку в дополнение к этому конкретному случаю использования, я бы рекомендовал взглянуть на Apache Kafka . Kafka обеспечивает семантику обмена сообщениями, аналогичную RabbitMQ, но сосредоточена на обработке потоков сообщений (не говоря уже о том, что она была испытана в бою в LinkedIn).