데몬이 시작 시에만 구성 파일을 읽는 이유는 무엇입니까? 해당 파일/핫 리로드의 변경 사항에 "반응"할 수 없는 이유는 무엇입니까? [폐쇄]

몇 가지 이유가 있습니다. 주된 이유 중 하나는 많은 데몬이 여러 구성 파일을 가지고 있고 단일 파일 변경이 자체적으로 작동하지 않을 수 있다는 것입니다. 따라서 구성 파일 중 하나가 변경될 때마다 데몬의 구성을 다시 로드하려고 하면 해결되는 것보다 더 많은 문제가 발생할 수 있습니다. 질문.

순전히 구현 관련 관점에서 보면 구성 파일의 변경 사항을 모니터링해야 하면 데몬이 더 복잡해집니다. 데몬에는 데몬의 핵심 목적에 해당하는 작업이 수행되는지 확인하는 일종의 중앙 루프가 있습니다. 구성 파일 변경 사항을 확인하는 것이 반드시 해당 핵심 목적에 맞는 것은 아닙니다.

별도의 신호를 처리하면 두 가지 문제가 모두 해결됩니다. 구성이 일관되고 다시 로드해도 안전하다는 신호를 사용자에게 알리고, 메인 루프에 미치는 영향을 최소화하면서 신호 처리기(일반적으로 기본 플래그 변경)에서 비동기적으로 구현될 수 있습니다. 플래그 변경에 반응합니다).

일부 데몬은 구성 변경 자체에 반응합니다. cron예를 들어 기본 루프가 실행될 때마다 해당 구성 파일의 변경 사항을 확인합니다.

다른 답변에서 언급된 다른 모든 이유 외에도 더 깊은 철학적 이유가 있으며 이는 기본 Unix 프로그래밍 설계 원칙 중 하나입니다.뭔가를하고 잘해라.

Unix에서 프로그램은 일반적으로 한 가지 일만 수행합니다. 여러 프로그램을 결합하면 더 복잡한 작업을 수행할 수 있습니다.

이제 (예를 들어) 웹사이트를 제공하는 것이 한 가지가 되었습니다. 파일 변경을 보는 것은 또 다른 이야기입니다. 따라서 Unix의 모토에 따르면 웹 서버는 예를 들어 웹 사이트를 제공하므로 이들은 두 개의 서로 다른 프로그램이어야 합니다.그리고파일의 변경 사항을 감시하는 것이 작동하지 않습니다뭔가를하고 잘해라, 그럴 것이다두가지. 종종 두 가지 작업을 수행하는 프로그램은 적어도 이 두 가지 작업을 잘 수행하지 못합니다. (예를 들어 웹 서버를 작성하는 사람은 HTTP 전문가일 수 있지만 파일 모니터링 전문가는 아닐 수 있습니다.)

특히 네트워크 지향 데몬의 경우 "한 가지 작업만 수행" 원칙을 고수해야 하는 또 다른 이유가 바로 보안입니다. 모든 코드 줄은 잠재적인 오류입니다. 가장 안전한 코드는 코드가 없는 것입니다. 데몬에 속하지 않는 데몬에서 책임을 제거함으로써 코드 양을 줄이고 그에 따른 공격 표면을 줄일 수 있습니다.

여러 작업을 수행하는 프로그램이 일반적으로 그 중 하나 이상에서 성능이 저하된다는 사실 외에도 책임을 나누는 또 다른 이유가 있습니다.코드 재사용. 파일 모니터링이 웹 서버의 일부인 경우 SSH 서버도 파일 모니터링을 구현해야 합니다. 그리고 파일 서버. 그리고 채팅 서버. 그리고 전화 서버. 그리고 데이터베이스 서버. 그리고 미디어 스트리밍 서버. 기타 등등

그리고 파일 모니터링이 별도의 프로그램에서 수행되는 경우 이 프로그램만 구현하면 됩니다.한 번, 한 번 테스트, 한 번 최적화, 한 번 기록 등. 또한 사람들에게 사용법을 한 번만 교육하면 적용할 수 있습니다.지금까지 작성된 모든 데몬, 사실 심지어미래에 작성될 모든 데몬.

그래서,만약에질문에서 요청한 작업을 수행하고 싶습니다.둘데몬: 예를 들어 웹 사이트를 제공하는 데몬, 파일의 변경 사항을 모니터링하고 해당 변경 사항에 따라 작업을 수행하는 데몬입니다.

그리고 놀랍게도 그러한 데몬이 이미 존재합니다.

다른 답변 추가: 가장 큰 장애물 중 하나는 적어도 애플리케이션의 현재 상태, 이전 값 및 기타 변경된 값을 이해하기 위해 각 구성 값에 설명이 있어야 한다는 것입니다. 일반적으로 구성 파일은 비실행 상태에서 초기 상태로 들어가는 방법을 데몬 프로세스에 지시합니다. 데몬이 구성을 변경할 때 다시 로드한다는 것은 구성 값을 데몬의 현재 상태에 대한 수정으로 해석할 수도 있다는 의미입니다. 예를 들어 일종의 작업 데몬을 생각해 보겠습니다. 구성에서는 worker_threads: 2데몬이 방금 시작된 경우 설명은 간단합니다. 작업을 수행하기 위해 두 개의 스레드가 생성됩니다. 이 값에 대한 수정 사항을 처리해야 하는 경우 이제 몇 가지 작업을 수행해야 합니다. 즉, 스레드 수가 증가하면 더 많은 스레드를 추가해야 합니다. 감소하면 일부 스레드를 제거하십시오.

변경 내용의 해석은 이전 값뿐만 아니라 데몬의 현재 상태에 따라 달라집니다. 구성을 로 업데이트하는 경우 worker_threads: 1두 스레드가 모두 사용 중인 경우 데몬은 어떻게 해야 합니까? 구성에 설명된 상태와 즉시 일치하려면 하나를 종료해야 합니까? 작업이 완료될 때까지 실행된 다음 스레드를 종료하도록 허용해야 합니까?

이 외에도 구성 값 변경의 해석은 다른 구성 값의 변경에 따라 달라집니다. 모든 작업자 스레드가 사용 중일 때 작업자 스레드 수를 줄일 때 수행할 작업을 결정하는 추가 구성 값이 있다고 가정합니다 kill_threads_on_worker_reduction: true/false. 설정되면 활성 작업자 스레드를 종료할지 여부를 결정할 수 있습니다. 하지만 구성 값이 다음과 같은 경우반품바뀌었어? 실행 중인 새 작업에만 적용됩니까, 아니면 변경 전에 시작된 작업에 소급하여 적용됩니까?

이건 그냥 연구일 뿐이야하나가능한 구성 값. 모든 구성 값, 가능한 모든 애플리케이션 상태 및 변경된 값의 가능한 모든 조합에 대해 이를 계산해야 합니다.

어떤 경우에는 구성 변경이 설명하기 더 간단하지만 이는 구성 변경을 라이브로 다시 로드하는 것이 종종 쉽지 않은 이유를 설명하는 데 도움이 됩니다.