정전 후 카멜 처리 재개

Question

나는 현재 이전 상태에서의 재개가 중요한 카멜 통합 응용 프로그램을 개발 중입니다. 예를 들어, 정전이 발생하면 이전에 처리 된 모든 메시지가 다시 처리되지 않아야합니다. 처리는 정전 이전에 중단되었던 지점부터 다시 시작해야합니다.

나는 Terracotta와 Apache Shiro을 포함한 여러 가지 가능한 해결책을 찾아 보았습니다. 나는 아파치 카멜과의 통합에 대한 문서가 부족하다는 것을 어느 쪽인지 사용하는 방법을 잘 모릅니다. 그러나 나는이 두 가지에 정착하지 못했습니다.

나는 내가 사용할 수있는 잠재적 대안이나 나에게 도움이 될 자습서의 포인터에 대한 제안을 찾고있다.

Answer 1

생존 장애의 어려움은 주로 주에서 발생하며 기내 메시지로해야 할 일입니다.

일반적으로 경로 내에서 상태를 말하면 솔루션이 디스크 나 클러스터의 다른 노드로 플러시됩니다. 집계 패턴을 예로 들면, 집계 된 상태는 집계 저장소에 유지됩니다. 기본 구현은 메모리에 있으므로 전원이 꺼지면 모든 상태가 손실됩니다. 그러나 JDBC 용과 Hazelcast (경량 인 메모리 데이터 그리드)를 사용하는 다른 구현이 있습니다. 나는 Hazelcast를 직접 사용하지 않았지만 JDBC는 디스크에 동기 쓰기를 수행한다. 집계 자 패턴을 사용하면 중단 한 부분부터 다시 시작할 수 있습니다. 멱등 원을 소비하는 비슷한 해결책이 있습니다.

기내 메시지 주변의 두 번째 질문은 좀 더 복잡하며 주로 어디에서 소비하고 있는지에 달려 있습니다. 웹 서비스 요청을 처리하는 중이고 전원이 꺼지면 메시지를 분실했는지가 중요합니까? 사용자는 간단히 다시 시도 할 수 있습니다. 외부 시스템에 대한 영향은 트랜잭션 또는 JDBC 멱등 원 리포지토리가있는 멱등하지 않은 소비자로 래핑 될 수 있습니다.

메시징을 기반으로 통합을 구축하는 경우 트랜잭션 내에서 소비해야하므로 서버가 다운되면 메시지가 브로커로 다시 이동하여 다른 소비자에게 재생 될 수 있습니다.

seda: 또는 threads 블록을 사용하는 경우 인 메모리 대기열을 사용하여 스레드간에 교환을 전달할 때주의하십시오. 이러한 종류의 경로를 통과하는 메시지는 누군가 전원 케이블을 통해 이동하면 손실됩니다. 메시지 손실을 감당할 수 없으며 이러한 종류의 처리 모델이 필요한 경우 JMS 큐를 두 경로 사이의 끝점으로 사용하는 것을 고려하십시오 (트랜잭션을 사용하여 중단 한 부분을 다시 잡을 수 있습니다).