중요 업무 시스템을위한 분산 형 n-Producers / 1-Consumer 서비스 구현
중요한 임무 시스템을 위해 다중 생산자 / 1 소비자의 분산 버전을 구현하려고합니다. RDBMS를 기반으로 한 현재 접근 방식에 대한 좋은 대안을 찾고 있습니다.
문제
이 시스템은 초당 수천 개의 인스턴스를 지속적으로 생성하는 서버 (50 개 이상의) 생산자로 구성됩니다. 각 인스턴스는 잘 정의되고 타임 스탬프가 있으며 평면 구조입니다. 각 인스턴스는 생산자가 단일 대기열에 저장합니다.
다른 한편으로는 FIFO 방식으로 인스턴스를 소비하는 소비자가 있습니다.
생산자와 소비자는 TCP / IP 사설 네트워크로 연결된 서로 다른 시스템에서 실행됩니다.
완전성을 위해 두 가지 강력한 요구 사항이 있습니다.
- 소비자는 동일한 리소스를 두 번 사용할 수 없습니다. 오류입니다.
- 모든 리소스는 소비자가 소비해야합니다. 자원이 누락되면 손실입니다.
또한 솔루션은 Linux 및 Windows 서버에서 실행되어야합니다.
현재 접근 방식
현재 버전에서 시스템은 관계형 데이터베이스를 데이터 버스로 사용하여이 솔루션을 구현합니다.
모든 생산자와 소비자를 지원하는 하나의 데이터베이스 서버가 있습니다. 생산자는 결정된 테이블에 리소스를 삽입하고 소비자는 위 이미지에 표시된대로 해당 테이블의 리소스를 소비합니다.
데이터베이스 서버 / JDBC 트랜잭션 모델은 큐 손상을 방지하기 위해 삽입 / 삭제를 제어 할 수 있습니다.
현재의 접근 방식은 잘 작동하지만 :
- 데이터 관계가 필요하지 않은 작업에 대해 전체 관계형 데이터베이스 서버를 유지 관리하는 오버 헤드를 소개합니다.
- 관계형 데이터베이스 서버는 데이터베이스 서버 인스턴스가 전용이 아닐 때 일부 실제 설정에서 달성하기 어려운 중요한 임무 요구 사항에 적합해야합니다.
대안
다음은 현재 관계형 데이터베이스 서버 데이터 버스 접근 방식에 대한 몇 가지 대안을 나열합니다.
경량 관계형 데이터베이스 서버 전용
이것이 가장 쉬운 방법 인 것 같습니다. 전용 경량 관계형 데이터베이스 서버를 HSQLDB, Apache Derby 또는 H2로 사용하는 것입니다.
장점
MS SQL Server, Oracle DB Server 또는 심지어 MySQL과 같은 RDBMS와 비교할 때 유지 관리해야 할 오버 헤드가 상당히 적습니다. 또한 기본적으로 현재 솔루션에서 사용되는 것과 같은 SQL 엔진이므로 코드 변경 및 테스트가 덜 필요합니다.
단점
관계형 데이터베이스 서버이므로 관계없는 작업을 수행하기위한 일정 수준의 오버 헤드가 여전히 존재합니다. 또 다른 요점은 중요한 임무 측면입니다. 우리는 임베디드 모드와 네트워크 모드 모두에서 실시간 시스템 감시를 위해 내부적으로 Derby DB를 사용합니다. 크래시도 데이터 손상도없이 훌륭하게 작동합니다. 그러나 새로운 사용량에 대한 초당 트랜잭션 양은 더 높습니다.
Redis 서버
언뜻보기에 Redis는이 사용 사례에 완벽 해 보입니다. 메모리에서 빠르고, 데이터 관계에 대한 오버 하드없이 간단합니다. 데이터 버스로 널리 사용되며 신뢰할 수있는 것으로보고됩니다. 그러나 Windows는 아닙니다. 문서에서 말했듯이 Windows의 Redis는 권장되지 않습니다 . 마이크로 소프트 윈도우 포트는 더 이상 유지되지 않습니다 마지막 릴리스 날짜 2016 그렇게 promissing없는 시스템 외모에 레디 스를 부착.
처음부터 솔루션 구현
마지막으로 생산자-소비자 문제입니다. TCP 또는 Camel과 같은 더 우아한 것을 사용하여 네트워크 서비스를 구현하고 내부적으로 동시 대기열을 사용하고 일부 로컬 지속성 엔진을 사용하는 것은 시간이 많이 걸리고 휠을 재발 명하지만 여전히 옵션입니다.
이것이 우리가 지금까지 고려하고있는 대안입니다. 누군가가 통찰력이나 권장 사항을 제공 할 수 있으면 감사합니다.
답변
메시지 대기열을 찾고있는 것 같습니다. 기술 스택에 따라 ZeroMQ 또는 RabbitMQ와 같이 관심을 가질 수있는 분산 대기열의 다양한 구현이 있습니다.
ZeroMQ와 같은 일부 접근 방식은 메시지 브로커없이 실행될 수 있습니다. 즉, 생산자와 소비자가 대기열을 조정 / 브로커하기 위해 다른 서비스 나 데이터베이스없이 직접 대화합니다. 중개인이 없다는 것은 중개 된 메시지 대기열보다 운영상 관리가 훨씬 간단하고 이해하고 확장하고 사용자 정의하는 것이 더 간단하다는 장점이 있지만 주된 단점은 일반적으로 중개인이 제공하는 서비스가 부족하다는 것입니다. 오프라인 상태이면 메시지가 손실 될 수 있습니다. 메시지를 안정적으로 처리해야하는 경우 소비자를 사용할 수없는 경우 재시도 전송을 처리 할 수 있도록 생산자를 설계해야하며, 성공적인 배달에 대한 승인 메커니즘을 추가해야하며 소비자는 멱 등성을 갖도록 설계되었습니다 (중복 메시지를 감지하고 삭제할 수 있음). 브로커리스의 주요 이점은 애플리케이션에 필요한만큼 브로커 동작을 자유롭게 구현할 수 있으므로 특정 브로커 동작에 묶이지 않는다는 것입니다.
RabbitMQ와 같은 중개 된 메시지 대기열은 사용 중에 다소 간단합니다. 브로커가 생성자와 소비자가이를 구현하도록 요구하는 대신 대기열 시스템의 패브릭에 지속성 및 메시징 안정성 계층을 추가하기 때문에 브로커 관리의 복잡성과 오버 헤드가 추가됩니다. , 브로커는 지연 시간을 추가하므로 밀리 초가 중요하거나 대상 확장 성 수준이 브로커 시스템에서 달성 할 수있는 수준을 초과하는 시나리오에는 적합하지 않을 수 있습니다.
관계없는 작업을 수행하기위한 일정 수준의 오버 헤드가 여전히 존재합니다.
실제로 그게 중요한지 아닌지 실제로 알아보기 위해 응용 프로그램을 프로파일 링하는 것이 좋습니다. in-process SQL 데이터베이스가 비 동시 애플리케이션에 충분하지 않은 경우 관계 관리 자체의 성능 문제가 아니라 비효율적으로 사용하고 있기 때문일 가능성이 높습니다.