2
프로세스 간 통신을 위해 파일을 사용하는 것이 장단점은 무엇입니까? 이 질문을하는 맥락에 대한 배경을 알려 드리겠습니다.프로세스 간 통신
문제는 몇 가지 제약이있는 고전적인 생산자 소비자 문제입니다. 프로듀서는 기계 클러스터에서 실행되는 협업 프로세스 세트이며 브로드 캐스트를 사용하여 서로 통신합니다. 각 프로세스는 알고있는 로컬 사용자를 가지고 있으며 또한 위의 브로드 캐스트 메커니즘을 통해 다른 프로세스에 알립니다. 지금까지는 방송/공유되는 상태 정보가 지속되지 않지만 지금은 필요합니다.
이 시스템은 현재 수천 년간 사용자를 지원하고 있으며 추가로 종속성을 추가하여 지속성에 대한 지원을 추가하는 것에 대해 매우 우려하고 있습니다. 우리가 선택한 경로는 파일 시스템의 파일에 로컬 트래픽을 쓰는 새로운 프로세스를 생성하고 새로운 프로세스 (소비자라고 부를 수 있음)가 읽고 쓰는 새로운 프로세스를 생성하는 것이었다. 이 방법으로 볼 수있는 이점은 다음과 같습니다.
- 무료로 지속성을 얻습니다. 새 프로세스에는 파일 시스템에 로컬 트래픽을 기록 할 때 문제가 발생하지 않습니다. 소비자는 중단 된 부분을 알기 만하면 언제든지 데이터 처리를 시작할 수 있습니다.
- 일반적인 오래된 유닉스 파일 IO의 큐 라이브러리를 사용하는 데 필요한 학습 곡선이 없습니다.
- 가장 큰 장점은 파일 작성을위한 새로운 스레드를 제외하고는 현재 생산자 프로세스에 전혀 영향을 미치지 않는다는 것입니다.
- 파일 잠금 및 경합과 그 성능에 영향을
이 방법을 사용하는 경우의 몇 가지
이다.
- 쓰기 버퍼가 플러시되고 제작자가 전체 이벤트가 파일에 기록 된 후에 만 파일 잠금을 해제하는지 확인하십시오. 소비자는 불완전한 기록을 읽어야합니다.
생각들? 이 접근 방법이 순진한가? 그리고 선반 영구 큐 라이브러리를 사용하기 위해 램프 업 시간을위한 초기 비용을 지불해야합니까? 여기서 가장 중요한 점은 현재 프로세스에 최소한의 영향을 미치고 종속성을 추가하고 싶다는 것입니다.