Python Multiprocessing with Queue vs. ZeroMQ IPC

Jestem zajęty pisaniem aplikacji Python przy użyciu ZeroMQ i wdrażaniem wariacji wzoru Majordomo, jak opisano w ZGuide .

Mam brokera jako pośrednika między grupą pracowników a klientami. Chcę wykonać obszerne rejestrowanie każdego przychodzącego żądania, ale nie chcę, aby broker marnował na to czas. Broker powinien przekazać to żądanie logowania do czegoś innego.

Myślałem o dwóch sposobach:

1. Twórz pracowników, którzy są tylko do rejestrowania i używaj transportu ZeroMQ IPC
2. Używaj przetwarzania wieloprocesowego z kolejką

Nie jestem pewien, który z nich jest lepszy czy szybszy. Pierwsza opcja pozwala mi używać bieżących klas podstawowych pracowników, których już używam dla normalnych pracowników, ale druga opcja wydaje się szybsza do wdrożenia.

Chciałbym uzyskać porady lub komentarze na temat powyższego lub być może inne rozwiązanie.

Podoba mi się podejście polegające na użyciu standardowych narzędzi, takich jak zaproponował Jonathan. Nie wspominałeś o tym, nad którym systemem pracujesz, ale inną alternatywą wynikającą z tego samego ducha może być użycie standardowego modułu rejestrującego Pythona razem z logging.handlers.SysLogHandlerwysyłaniem komunikatów rejestrujących do usługi rsyslog (dostępnej na dowolnym systemie Linux / Unix, ale ja myślę, że jest też opcja Windows , ale nigdy jej nie użyłem).

Zasadniczo cały system implementuje to samo, o czym myślisz. Proces lokalny umieszcza w kolejce komunikat dziennika do przetworzenia / przetworzenia / napisania przez kogoś innego. W tym przypadku ktoś inny ( rsyslog) to dobrze znana, sprawdzona usługa, która ma wiele wbudowanych funkcji i elastyczności.

Inną zaletą tego podejścia jest to, że twój produkt będzie lepiej integrować się z innymi narzędziami sysadmin, które są zbudowane na syslog. I nie wymagałoby nawet pisania kodu, aby uzyskać tę opcję.

Warto rozważyć trzecią możliwość wdrożenia zdalnego rejestrowania. Jeśli korzystasz ze standardowego modułu rejestrowania w języku Python, możesz rozważyć użycie logging.QueueHandlerklasy w pracownikach, klientach i brokerze oraz logging.QueueListenerklasy w procesie zdalnego rejestrowania.

Zamiast używać normalnego języka Python multiprocessing.Queuejako transportu między procesami aplikacji a procesem logowania, zaimplementuj własną Queueklasę zastępczą za pomocą ZeroMQ z pisaniem kaczych, aby twoja klasa była zastępczym standardowym Pythonem Queue. W ten sposób Twoja aplikacja będzie mogła działać bez zmian w dowolnym środowisku z jednego komputera wielordzeniowego poprzez rozproszone centra danych.

Podsumowując, użyj standardowego rejestratora Python QueueHandlerwe wszystkich swoich pracownikach, klientach i brokerach i stwórz niezależny proces oparty na wybranych przez ciebie QueueListenerprogramach loggingobsługi Pythona, aby poradzić sobie z dużym obciążeniem rejestrowaniem.

Są to radykalnie różne podejścia, każde z własnymi zestawami zalet i wad, które najprawdopodobniej zobaczysz na późniejszym etapie rozwoju:

Myślałem o dwóch sposobach:

1. Twórz pracowników, którzy są tylko do rejestrowania i używaj transportu ZeroMQ IPC
2. Używaj przetwarzania wieloprocesowego z kolejką

Jednym ze sposobów , w jaki możesz spróbować jest mieć dodatkowego pracownika rejestrującego, jak w podejściu 1. Możesz pozwolić swoim pracownikom zalogować się do klastra rejestrującego memcache, a pracownik rejestrujący monitoruje bieżące obciążenie zasobem, a po zmniejszeniu danego parametru ładowania zasobu dziennik roboczy loguje się na urządzeniu z ograniczoną liczbą procesorów IOP (np. dyskiem twardym).

Podoba mi się również podejście Jonathana z zastrzeżeniem, że ja też w większości używam Pythona 2.x i że prawdopodobnie będziesz musiał skonfigurować własny backend rejestrowania, aby naprawdę zwiększyć wydajność.

Popraw mnie, jeśli się mylę, ale uważam, że wykonujesz jakieś bardzo intensywne zadanie, a procesory pamięci masowej są twoim wąskim gardłem.

Wygodnym sposobem nadal byłoby zezwolenie brokerowi na brokeragerejestrowanie - w opisanej formie - ze wszystkimi wadami centralnej instancji brokera. Na przykład, jeśli broker ma tak duże zapotrzebowanie, że nigdy nie ma czasu na zapisanie zapisanych dzienników z powrotem do magazynu, należy zastosować inne podejście.

Ostatecznie możesz skończyć z modelem bez brokera. To znaczy, że pracownicy zarządzają swoją pracą między sobą. W prostym przykładzie za pomocą rozproszonego algorytmu round-robin .