큐 대 ZeroMQ IPC를 사용한 Python 멀티 프로세싱


10

ZeroMQ를 사용하여 Python 응용 프로그램을 작성 하고 ZGuide에 설명 된대로 Majordomo 패턴의 변형을 구현하는 데 바쁩니다 .

나는 노동자와 고객 사이의 중개자로 중개인을 가지고 있습니다. 들어오는 모든 요청에 ​​대해 광범위한 로깅을 수행하고 싶지만 브로커가 시간을 낭비하지 않기를 바랍니다. 브로커는 해당 로깅 요청을 다른 것으로 전달해야합니다.

나는 두 가지 방법을 생각했다 :-

  1. 로깅 전용 작업자 생성 및 ZeroMQ IPC 전송 사용
  2. 큐에서 멀티 프로세싱 사용

그 문제에 대해 어느 것이 더 낫거나 빠른지 잘 모르겠습니다. 첫 번째 옵션을 사용하면 이미 일반 작업자에게 사용하는 현재 작업자 기본 클래스를 사용할 수 있지만 두 번째 옵션은 더 빨리 구현하는 것 같습니다.

위의 또는 다른 해결책에 대한 조언이나 의견을 원합니다.

답변:


4

Jonathan이 제안한 것과 같은 표준 도구를 사용하는 방식이 마음에 듭니다. 어떤 OS를 사용하고 있는지 언급하지 않았지만 동일한 정신을 따르는 또 다른 대안은 Python의 표준 로깅 모듈을 함께 사용 logging.handlers.SysLogHandler하고 로깅 메시지를 rsyslog 서비스 (Linux / unix에서 사용 가능) 로 보내는 것입니다. windows 옵션 도 있다고 생각 하지만 결코 사용하지는 않았습니다).

기본적으로 전체 시스템은 생각했던 것과 동일한 것을 구현합니다. 로컬 프로세스는 다른 사람이 처리 / 처리 / 작성할 로그 메시지를 큐에 넣습니다. 이 경우 다른 사람 ( rsyslog)은 많은 기능과 유연성이 내장 된 잘 알려진 입증 된 서비스입니다.

이 접근 방식의 또 다른 장점은 제품이 syslog 위에 구축 된 다른 sysadmin 도구와 훨씬 더 잘 통합된다는 것입니다. 또한 해당 옵션을 얻기 위해 코드를 작성하지 않아도됩니다.


1
바퀴를 재발 명하지 않는 제안에 +1. 이런 식으로 설계된 시스템을 상속받지 않아도됩니다. 작업을 훌륭하게 수행하지만 향후 수정을 위해 많은 자유를 제공합니다.
evadeflow

2

원격 로깅을 구현할 수있는 세 번째 가능성을 고려할 수 있습니다. 표준 Python 로깅 모듈을 사용하는 경우 logging.QueueHandler작업자, 클라이언트 및 브로커의 logging.QueueListener클래스 및 원격 로깅 프로세스 의 클래스 사용을 고려할 수 있습니다 .

multiprocessing.Queue애플리케이션 프로세스와 로깅 프로세스 사이의 전송으로 일반 Python을 사용하는 대신 , QueueDuck 타이핑과 함께 ZeroMQ를 사용하여 클래스를 표준 Python 대신 사용할 수 있도록 자체 대체 클래스를 구현하십시오 Queue. 이런 식으로 응용 프로그램은 분산 된 데이터 센터를 통해 단일 멀티 코어 컴퓨터에서 어떤 환경에서도 변경없이 실행할 수 있습니다.

요약하면, QueueHandler모든 작업자, 클라이언트 및 브로커에서 표준 Python 로거 를 사용하고 무거운 로깅 해제를 처리하기 위해 선택한 QueueListenerPython logging처리기 와 기반으로 독립적 인 프로세스를 만듭니다 .


Python 2.7을 사용하고 있습니다. QueueHandler 클래스는 Python 3.2에서만 사용할 수 있다고 생각합니다.
Imraan

Python 3에서 코드를 가져 와서 앱의 일부로 직접 사용하는 것은 매우 쉽습니다.
Jonathan

나는 그것을 시도하고 그것이 작동하는지 알려드립니다
Imraan

0

이것들은 각각 장단점이있는 근본적으로 다른 접근법이며, 나중에 개발 단계에서 패닝 될 것입니다.

나는 두 가지 방법을 생각했다 :-

  1. 로깅 전용 작업자 생성 및 ZeroMQ IPC 전송 사용
  2. 큐에서 멀티 프로세싱 사용

접근 방법 1에서와 같이 추가 로깅 작업자를 사용하는 것이 한 가지 방법입니다. 작업자가 memcache 로깅 클러스터에 로그인하도록 할 수 있으며 로깅 작업자는 현재 리소스로드를 모니터링하고 지정된 리소스로드 매개 변수를 무시하면 작업자는 IOP 제한 장치 (예 : 하드 디스크)에 기록합니다.

필자는 또한 Python 2.x를 너무 많이 사용한다는 경고에 대한 Jonathan의 접근 방식이 마음에 들며 실제로 성능 봉투를 푸시하기 위해 자체 로깅 백엔드를 설정해야 할 수도 있습니다.

내가 틀렸다면 바로 잡으십시오.하지만 테이크 아웃은 병목 현상이 발생한 스토리지 IOP를 사용하여 실제로 데이터 집약적 인 작업을 수행하고 있습니다.

편리한 방법 은 브로커가 brokerage중앙 브로커 인스턴스의 모든 단점과 함께 설명 된 형식으로 로깅을 수행하도록 하는 것입니다. 예를 들어 브로커가 수요가 많아 memcached 로그를 스토리지에 다시 쓸 수있는 호흡 공간을 확보하지 못하면 다른 접근 방식을 취해야합니다.

결국 브로커리스 모델로 끝날 수 있습니다. 그것은 노동자들이 그들 자신의 일을 관리하는 것입니다. 간단한 예에서는 분산 라운드 로빈 알고리즘을 사용합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.