내가 레일에 루비를 사용하여 응용 프로그램을 작성하려고 그리고 난 다음 달성하기 위해 노력하고있어 : 앱에서 UDP를 수신 할 필요가긴 실행 루비 과정
특정 포트 (아마도 초당 1 개 이상)에 들어오는 메시지를 데이터베이스에 저장하여 나머지 Rails 앱이 액세스 할 수 있도록합니다.
나는이 메시지를 수신하고 올바른 모델을 사용하여 데이터베이스에 메시지를 저장할 내 레일 앱의 루비 스크립트로 쉘을 분리하는 별도의 데몬을 작성하려고 생각했습니다. 이 방법의 문제점은 루비 스크립트가 매우 자주 실행된다는 것입니다. 지속적으로 UDP 메시지를받을 수있는 장기 실행 루비 프로세스를 데이터베이스에 저장할 수 있다면 성능면에서 더 낫습니다.
올바른 방법인가요? 이 도움이 될 레일스 프레임 워크에 뭔가가 있습니까?
들어오는 요청마다 Rails 스택을로드하고 싶지 않습니다. 너무 느릴 것입니다. 들어오는 연결을 처리하기 위해 더 낮은 레벨의 것을 사용하고자 할 것입니다. Webrick의 내부를 보면 루비로 코딩 된 간단한 서버 데몬을 볼 수 있습니다. 아니면 성능이 좋은 것을 원하면 Mongrel이나 Thin을보십시오.
일반적으로 전체 레일 스택이 여기에 많은 도움이되지는 않습니다. 대부분의 기능은 웹 앱 제공에 맞춰져 있으며, 곧바로 데이터를 저장하지 않습니다.
아마도 가장 도움이되는 레일스의 일부는 ActiveRecord입니다. 모델 데이터를 데이터베이스에 저장하는 데 사용할 수있는 기회가 꽤 있습니다. 실제로 include 실제 Rails 모델을 UDP 모니터링 프로세스에서 사용할 수 있어야합니다. Rails 프로젝트 외부의 데이터베이스에 연결하는 예는 ActiveRecord docs을 확인하십시오.
필자는 포트에서 많은 메시지를 받고이를 데이터베이스에 유지하는 것과 비슷한 기능을하는 응용 프로그램을 보유하고 있습니다. 우리는 데이터베이스가 어떤 이유로 든 사용할 수없는 경우에도 메시지를 잃어서는 안된다는 사실을 포함하여 데이터베이스 설계를 진화시킬 때 여러 가지 문제를 해결했습니다.
성능상의 이유로 우리는 메시지를 잃지 않았 음을 보장하기 위해 2 단계 프로세스를 진행했습니다. 우리는 메시지를 청취 한 다음 Apache Active-MQ을 사용하여 메시지 대기열에 지속시킨 작은 핸들러를 작성했습니다. 그런 다음 별도의 레일스 애플리케이션 내에서 ActiveMessaging 플러그인을 사용하여 큐에서 메시지를 소비하고이를 데이터베이스에 보관합니다. 이 방법을 사용하면 리스너를 쉽게 확장 할 수 있으며 메시징 처리량이 훨씬 높아집니다.
이 경로를 찾으려면 일반적으로 Apache 버전의 몇 가지 버전 인 Active-MQ의 Fuse implementation을보고 싶을 수 있습니다.