Python: VM OpenMPI. RabbitMQ

Question

Załóżmy, że jest się zainteresowanym napisaniem aplikacji python, w której powinna istnieć komunikacja między różnymi procesami. Komunikacja zostanie wykonana poprzez wysłanie tablic strings i/lub numpy.

Jakie są względy preferujące OpenMPI w porównaniu z narzędziem takim jak RabbitMQ?

Answer 1

Nie ma jednej prawidłowej odpowiedzi na takie pytanie. Wszystko zależy od wielu różnych czynników. Na przykład:

1. Jaki rodzaj komunikacji posiadasz? Czy wysyłasz duże pakiety lub małe pakiety, czy potrzebujesz dobrej przepustowości lub małego opóźnienia?
2. Jakiego rodzaju gwarancji dostawy potrzebujesz?
3. OpenMPI może błyskawicznie dostarczać wiadomości tylko do uruchomionego procesu, a różne rozwiązania MQ mogą umieszczać w kolejce wiadomości i pozwalać na dowolne konfiguracje producent-konsument.
4. Jaki rodzaj sieci posiadasz? Jeśli korzystasz z hosta lokalnego, prawdopodobnie najprawdopodobniej byłaby to wartość podobna do ZeroMQ. Jeśli korzystasz z zestawu hostów, zależy od dostępnych połączeń. Na przykład. OpenMPI może wykorzystywać łącza infiniband/mirynet.
5. Jakiego rodzaju przetwarzasz? W MPI wszystkie procesy są zwykle uruchamiane w tym samym czasie, przetwarzanie i kończenie wszystkich naraz.

Answer 2

To jest dokładnie scenariusz, w którym byłem kilka miesięcy temu i zdecydowałem się użyć AMQP z RabbitMQ przy użyciu wymiany tematów, oprócz memcache dla dużych obiektów.

Wiadomości AMQP są ciągami w formacie obiektów JSON, dzięki czemu można łatwo dodać atrybuty do wiadomości (np. Liczbę ponownych prób) i ponownie opublikować. Obiekty JSON są podzbiorem JSON, które odpowiadają dykcjom Pythona. Na przykład {"recordid": "272727"} jest obiektem JSON z jednym atrybutem. Mógłbym właśnie przetrawić dyktando Pythona, ale zablokowałoby to nas tylko za pomocą Pythona z kolejkami wiadomości.

Duże obiekty nie są kierowane przez AMQP, zamiast tego przechodzą do pamięci memcache, gdzie są dostępne dla innego procesu, aby je odzyskać. Możesz równie dobrze wykorzystać Redis lub Tokyo Tyrant do tej pracy. Chodzi o to, że nie chcemy, aby krótkie wiadomości były ustawiane w kolejce za dużymi obiektami.

W końcu moje procesy w Pythonie zakończyły się przy użyciu zarówno AMQP, jak i ZeroMQ dla dwóch różnych aspektów architektury. Może się okazać, że ma sens stosowanie zarówno OpenMPI, jak i AMQP, ale w przypadku różnych typów zadań.

W moim przypadku proces przełożonego trwa wiecznie, uruchamia całe stado robotników, którzy również działają wiecznie, chyba że umrą lub zawiesią się, w takim przypadku przełożony ponownie je uruchomi. Praca nieustannie napływa w postaci komunikatów za pośrednictwem AMQP, a każdy proces obsługuje tylko jeden etap pracy, więc gdy zidentyfikujemy wąskie gardło, możemy mieć wiele instancji procesu, być może na oddzielnych maszynach, w celu usunięcia wąskiego gardła. W moim przypadku mam 15 wystąpień jednego procesu, 4 z dwóch innych i około 8 innych pojedynczych instancji.