분산 큐 문제를 해결할 수있는 다양한 방법에 대해 자세히 알아 보려고합니다. 그래서 이미 어떤 제품, 서비스, 구현 및 연구 논문이 있는지 알고 싶습니다.
구현은 많은 도전에 직면하게되고 다음과 같은 절충을해야합니다.
- 주문이 강력하거나 느슨합니까?
- dem 등식이 있습니까?
- 단일 머신에 수용 할 수있는 것보다 더 많은 큐를 가질 수 있습니까?
- 단일 머신에 수용 할 수있는 것보다 더 많은 데이터를 대기열에 가질 수 있습니까?
- 데이터를 잃기 전에 몇 대의 컴퓨터가 충돌 할 수 있습니까?
- 순 분할을 견딜 수 있습니까?
- 넷 스플릿이 고정되면 자동으로 데이터를 조정할 수 있습니까?
- 클라이언트가 충돌 할 때 배달을 보장 할 수 있습니까?
- 동일한 메시지가 두 번 이상 전달되지 않을 수 있습니까?
- 주어진 지점에서 노드가 충돌하고 다시 작동하며 정크를 보내지 않습니까?
- 가동 중지 시간없이 실행중인 클러스터에 노드를 추가하거나 제거 할 수 있습니까?
- 가동 중지 시간없이 실행중인 클러스터의 노드를 업그레이드 할 수 있습니까?
- 이기종 서버에서 문제없이 실행할 수 있습니까?
- 대기열을 서버 그룹에 “고착”할 수 있습니까? (예 :“이 대기열은 유럽 데이터 센터에서만 허용됩니다”)
- 가능한 경우 두 개 이상의 데이터 센터에 데이터 복제본을 배치 할 수 있습니까?
모든 구현이 그 모든 것에“예”라고 말할 수 있다는 환상은 없습니다. 다양한 구현에 대해 듣고 싶습니다. 그들이 어떻게 작동하는지, 어떤 트레이드 오프를했는지, 그리고 왜 특정한 트레이드 오프를 결정했는지에 대한 이유.
또한 위 목록에서 놓칠 수있는 도전이있는 경우.
답변
기본 큐잉 시스템을 작성하는 것은 상당히 간단하지만, 모든 문제와 함께 위에서 언급했듯이 올바르게 수행하는 것은 또 다른 문제입니다. 소스 코드, 써드 파티 시스템 및 다양한 JMS 제공자를 작성한 자체 재배 시스템을 사용했습니다. 지금까지 JMS (Java Messaging Service)가 가장 완벽한 솔루션입니다. 당신이 요구하는 많은 것들이 JMS에서 가능합니다. 내가 가장 좋아하는 JMS 공급자는 ActiveMQ입니다. Spring을 사용하여 무료, 성능, 설치가 쉽고 내 앱에 더 쉽게 포함시킬 수 있습니다. JMS 프로 바이더는 사용자가 요청한 모든 것을 기본적으로 제공하지는 않지만 응용 프로그램이 필요로하는 경우 사용자가 요구 한 많은 것을 처리 할 수있는 도구 세트를 제공합니다. 많은 응용 프로그램에 나열된 모든 것이 필요하다는 것을 알지 못했습니다. 순서는 중요하지 않을 수 있습니다 (필요하지 않은 경우 가장 좋습니다).
http://activemq.apache.org/what-open-source-integration-solution-works-best-with-activemq-.html
주문이 강력합니까? 예. 프로그램 요구에 따라 둘 다 있습니다. 여기에 세부 사항은 다음과 같습니다 http://activemq.apache.org/total-ordering.html .
dem 등식이 있습니까? 아니요, 그러나 필요한 경우 응용 프로그램 계층에서 구현하는 것이 쉽지 않습니다.
단일 머신에 수용 할 수있는 것보다 더 많은 큐를 가질 수 있습니까? 예. 클러스터 된 서버를 가질 수 있으며 다른 대기열로 여러 시스템을 설정하려면 둘 중 하나를 사용하십시오.
단일 머신에 수용 할 수있는 것보다 더 많은 데이터를 대기열에 가질 수 있습니까? 예, 대부분의 JMS 공급자는 JMS 공급자가 중단 된 경우 메시지가 삭제되거나 손실되지 않도록 일종의 DB / 영구 저장소를 사용해야합니다.
데이터를 잃기 전에 몇 대의 컴퓨터가 충돌 할 수 있습니까? 타이밍과 관련이 있기 때문에 대답하기가 조금 더 어렵습니다. 그러나 JMS 제공자를 크래시하고 디스크가 손상되지 않은 경우 디스크가 백업되고 마지막 커미트를받은 위치에서 시작됩니다. 즉, 메시지가 두 번 전달 될 수 있지만이를 처리하기 위해 앱을 코딩하면 문제가되지 않습니다. 각 유형 (생산자, 소비자 또는 JMS 서버) 중 하나 이상이있는 한 완료됩니다. 디스크가 나갈 경우 중복성을 위해로드 / 밸런스 / 페일 오버를 수행 할 수도 있습니다.
순 분할을 견딜 수 있습니까? 나는 당신이 “net-split”의 의미를 이해한다고 생각하지만, 완전히 확실하지는 않습니다. JMS 서버가 클러스터되어 있다면 서버 중 하나와의 연결이 느슨해지면 다른 서버로 이동하여 중단 된 곳에서 픽업됩니다. 예, 그러나 이러한 유형의 상황은 클라이언트의 연결이 끊어진 시점에 따라 메시지가 중복 될 수 있습니다.
넷 스플릿이 고정되면 자동으로 데이터를 조정할 수 있습니까? 트랜잭션 된 세션을 사용하는 경우 커밋 된 메시지는 작동중인 기존 클라이언트에 다시 전달합니다.
클라이언트가 충돌 할 때 배달을 보장 할 수 있습니까? 예, 이것이 JMS의 주요 목표 중 하나입니다. 배달 보장은 메시지가 대기중인 경우 클라이언트가 처리 함을 보장합니다.
동일한 메시지가 두 번 이상 전달되지 않을 수 있습니까? 트랜잭션 세션을 사용중인 경우 예 이는 클라이언트가 메시지를 수락하고 commit / rollback을 호출했음을 의미합니다. 커밋이 호출되면 메시지를 다시 전달하지 않습니다.
주어진 지점에서 노드가 충돌하고 다시 작동하며 정크를 보내지 않습니까? 내구성있는 클러스터 큐가있는 경우 예. 클러스터의 다른 노드가 메시지를 전달한 경우 “정크”를 분출하지 않습니다. 아직 확인되지 않은 것은 다시 전달할 수 있습니다.
가동 중지 시간없이 실행중인 클러스터에 노드를 추가하거나 제거 할 수 있습니까? 예.
가동 중지 시간없이 실행중인 클러스터의 노드를 업그레이드 할 수 있습니까? 이것은 대답하기가 조금 까다 롭지 만 네가 할 수 있다고 믿습니다.
이기종 서버에서 문제없이 실행할 수 있습니까? 이것이 정확히 무엇을 의미합니까? 필자는 대부분의 JMS 공급자가 다른 하드웨어, OS 등을 사용하는 환경에서 실행하기가 매우 쉽다는 것을 알게되었습니다. 모든 분산 처리 시스템은 느린 노드에 의해 부정적인 영향을받을 수 있습니다. 대기열과 소비자를 실행하는 2 개의 8 코어 인텔 서버가있었습니다. 16 개의 코어가 함께 있으며 단일 코어 컴퓨터를 소비자로 추가했을 때보 다이 두 개의 상자 만 사용하여 성능이 향상되었습니다. 이 단일 코어 시스템은 속도가 너무 느려 전체 그리드 속도가 2 배 느려졌습니다. 이것은 JMS 자체와 아무 관련이 없습니다.
대기열을 서버 그룹에 “고착”할 수 있습니까? 짧은 대답입니다. 유럽 데이터 센터에만있는 클러스터를 실행하고 큐를 구성 할 수있는 방법을 생각할 수 있습니다. 그런 다음 스프링 설정에서 소비자는 다른 클러스터의 다른 대기열뿐만 아니라 해당 대기열을 소비합니다. 문서를 참조하고 싶을 수도 있습니다.
http://activemq.apache.org/clustering.html
가능한 경우 두 개 이상의 데이터 센터에 데이터 복제본을 배치 할 수 있습니까? 다시 한 번 믿지만 클러스터링 문서를 참조하는 것이 가장 좋습니다.
또한 JMS에는 필요에 따라 조정할 수있는 많은 옵션이 있습니다. 트랜잭션 된 세션 및 지속 가능한 큐를 사용하면 성능 비용이 발생합니다. 나는 모든 종소리를 켜고 휘파람이 성능에 10 배나 영향을 미친다는 것을 보았습니다. JBossMQ를 사용할 때 이러한 기능 중 일부를 끄면 약 10,000 메시지 / 초를 얻을 수 있지만,이를 켜면 1000 메시지 / 초로 떨어졌습니다. 큰 드롭.