Высокопроизводительная замена для многопроцессорной обработки. - PullRequest
0 голосов
/ 13 февраля 2020

Мое распределенное приложение состоит из множества производителей, которые ставят задачи sh в несколько очередей FIFO, и нескольких потребителей для каждой из этих очередей. Все эти компоненты находятся на одном узле, поэтому работа с сетью не требуется.

Этот шаблон отлично поддерживается встроенным в Python multiprocessing.Queue, однако при масштабировании В моем приложении реализация очереди кажется узким местом. Я не отправляю большие объемы данных, поэтому совместное использование памяти не решает проблему. Мне нужна быстрая гарантированная доставка 10 ^ 4-10 ^ 5 маленьких сообщений в секунду. Каждое сообщение имеет размер около 100 байт.

Я новичок в мире быстрых распределенных вычислений, и меня очень смущает количество вариантов. Существует RabbitMQ, Redis, Kafka и др. c.

ZeroMQ - более сфокусированная и компактная альтернатива, у которой также есть преемники, такие как nanomsg и nng. Кроме того, реализация чего-то вроде очереди «многие ко многим» с гарантированной доставкой кажется нетривиальной без посредника.

Я был бы очень признателен, если бы кто-то мог указать мне на «стандартный» способ сделать что-то подобное с одним из более быстрых рамок.

1 Ответ

1 голос
/ 16 февраля 2020

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

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

Чтобы сделать все это, RabbitMQ нужен брокер. Это делает это довольно медленно. Хотя в какой-то момент шла речь о переопределении RabbitMQ поверх базовых протоколов ZeroMQ (zmtp) и об отказе от посредника, вместо этого реализуя все функциональные возможности в конечных точках.

Напротив, ZeroMQ делает гораздо меньше, чтобы гарантировать что, в случае сбоев, ваши сообщения, в конечном итоге, будут доставлены в пункт назначения. Если процесс умирает или происходит сбой сетевого подключения, высока вероятность того, что сообщения будут потеряны. Более поздние версии могут быть настроены для активного мониторинга подключений, так что, если сетевой кабель обрывается или процесс где-то умирает, конечные точки на другом конце сокетов могут быть проинформированы об этом довольно быстро. Если затем реализовать интегрированную среду последовательных процессов поверх структуры акторов ZMQ (подумайте: подтверждения сообщений и т. Д. c. Это замедлит это), вы можете получить систему, в которой конечные точки могут точно знать, что сообщения были переданы. по назначению.

Быть без брокера позволяет ZMQ быть довольно быстро. И он эффективен для различных видов транспорта, от inproc до tcp, которые можно смешивать друг с другом. Если вы не беспокоитесь о сбоях процессов или сетевых подключениях, ZMQ дает вам гарантию доставки сообщений прямо из коробки.

Итак, решение, что важно в вашем приложении, помогает выбрать, какую технологию вы используете. Вы собираетесь использовать его как часть - RabbitMQ, ZeroMQ и др. c. Как только вы решили, что проблема «как получить нужные мне шаблоны» сводится к «какие шаблоны поддерживает эта технология». RabbitMQ - это, AFAIK, чисто паб / саб (каждого может быть много), тогда как у ZeroMQ их гораздо больше.

...