2013-01-03 4 views
3

필드의 장치에서 메시지를받는 상황을 처리하고 있습니다. 이 메시지에는 일련 번호가 찍혀 있으며 원래 순서대로이 메시지를 처리해야합니다. 메시지가 없어지는 것은 드물지만 불가능하지는 않으므로 처리 할 메커니즘이 필요합니다.주문이 중요 할 때 누락 된 메시지

내 구현은 NServiceBus를 기반으로하며 "HandleCurrentMessageLater"기능을 사용하여 메시지가 순서가 맞지 않은 경우 큐 뒷면으로 메시지를 팝합니다.

이것은 백 로그를 처리 할 수 ​​있도록 시퀀스의 다음 메시지를 수신하는 경우에 적합합니다.

이 경우 누락 된 메시지를 처리하려면 어떤 옵션이 필요합니까? 나의 첫 번째 반응은 일련의 실패한 시도 또는 이와 비슷한 일련 번호를 증가시키는 일종의 노화 알고리즘을 구현하는 것이지만, 이렇게하는 데는 복잡 할 수밖에 없다.

비슷한 문제에 직면 한 사람이 있었고 해결 방법을 공유하고 싶습니까? 이것은 당신의 사업에서 입력을해야합니다 뭔가처럼

감사

+0

하나의 메시지가 누락되면 모든 후속 메시지가 결국 실패하기를 원하십니까? –

+0

나는 어떤 점에서 메시지가 손실되어 내가 가진 데이터를 처리한다는 것을 받아 들여야 할 것이다. 우리는 모든 상황에서 데이터 손실을 제한해야하므로 추적 정보를 다루고 있습니다. –

답변

2

그것은 나에게 소리. 시간 제한이있어 그 메시지가 취소 불가능하게 손실 될 수 있다고 생각할 수 있습니까? 그렇다면 그러한 경우에 취해야 할 비즈니스 조치는 무엇입니까? 그리고 그 메시지가 마침내 수신되었지만 타임 아웃 후에 무슨 일이 일어나야합니까?

사가에서 구현할 수있는 여러 종류의 사례입니다. 메시지가 도착하여 순서가 맞지 않으면 HandleCurrentMessageLater를 계속 호출하지만 제한 시간을 요청하여 비즈니스 승인 시간 초과 후에도 이러한 조건이 참인 경우 보상 작업을 실행할 수 있으며 나머지 작업은 백업 된 메시지를 처리 ​​할 수 ​​있습니다.

또는 대체 솔루션이 가능할 수 있습니다. 원래 순서대로 메시지를 처리해야한다고하셨습니다. 당신은 이것의 실생활에 대한 어떤 세부 사항도 언급하지 않지만 높은 수준의 비즈니스 요구 사항과 같지만 기술적 인 요구 사항은 아닙니다. 다른 말로하면, 비즈니스는 그것을보고 싶어하지만 실제로 일어나는 방식 일 필요는 없습니다. 보통 순서대로 메시지를 처리 ​​할 수 ​​있으며 수집 된 데이터가 유효한 순서 번호를 나타내는 값을 증가시킬 수도 있습니다. 메시지가 잘못된 순서로 도착하면 여전히 소프트 처리 될 수 있지만 시퀀스 번호는 증가하지 않습니다.

기본적으로 메시지 1-5를 받고 정상적으로 처리합니다. 그런 다음 7-10 (6은 건너 뛴)을 받고 처리하지만 ValidSequenceNumber는 여전히 5입니다. 그런 다음 # 6이 도착하면이를 처리하고 보충 조치를 취하여 ValidSequenceNumber가 10이됩니다. 사가 (Saga)는 이런 논리를 구현할 수있는 좋은 후보자가 될 것입니다.

+1

데이비드에게 감사드립니다. 나는 내가 수동으로 당분간 그것을 고칠 수 있도록이 상태에 대해보고하기 위해보다 수동적 인 방법을 사용하기로 결정했다. 자동화 된 메커니즘을 적용하기 전에 얼마나 자주, 그리고 더 중요한 이유가 있었는지 이해하고 싶습니다. –

+0

+1 "이해 이유":-) –

0

모든 메시지를 안정적으로 전달해야하고 전송 채널이 안정적이지 않은 경우 확인 및 재전송 메커니즘이 필요합니다. 이것은 다음과 같이 보일 수 있습니다.

정상 흐름 :

  1. 메시지를 보낸 후, 클라이언트가 일시적으로 필요한 경우 재전송 할 수 있어야하기 위해 메시지를 저장합니다.
  2. 성공적인 se seence 전송시 서버는 시퀀스 번호를 포함하여 확인 메시지를 클라이언트에 보냅니다.
  3. ACK를 수신하면 클라이언트는 임시 메시지 저장소에서 해당 메시지를 제거합니다.

분실 메시지 : 아웃 - 오브 - 시퀀스 상태의 검출을

  1. , 서버는 최근 성공적 받았다 메시지의 시퀀스 번호를 포함하여, 클라이언트에게 다시 전송 메시지를 전송한다.
  2. 클라이언트는 마지막으로 수신 한 메시지에 이어 모든 메시지를 다시 보냅니다.

분명히 서버와 클라이언트 사이의 전송 채널과 양방향 통신이 필요합니다.

이 문제는 시퀀스 전송을 보장하는 TCP 프로토콜에 대해 심층적으로 해결되었습니다. TCP 재전송 내부를 살펴볼 수 있습니다.

+0

감사합니다 Bernd, 우리는 이와 같은 메커니즘을 갖추고 있습니다. 그러나 극한 상황에서 우리는 여전히 메시지를 잃을 수 있습니다. 예를 들어 장치에서 발생하는 오류가 있고 메시지가 단순히 전송되지 않는 경우입니다. 장치에 대한 총 전력 손실과 같은 여러 가지 문제가 발생할 수 있습니다. –

1

David Boike는 NSB 무용담을 사용할 때 정답을 가지고 있습니다. 다른 옵션을 추가하고 싶습니다. 짧은 시간 내에 메시지가 생성되면 장치는 NSB 기능을 사용하여 여러 논리적 메시지를 하나의 전송 메시지로 배치 할 수 있습니다. Send 또는 Publish 과부하 IBus을 사용하면 여러 메시지 매개 변수를 사용하기 만하면됩니다. 이러한 배치는 순서대로 처리되도록 보장됩니다.

+0

감사합니다. 그렇지만 특정 순서의 모든 메시지를 일괄 처리 할 수는 없습니다. 정보는 장기간에 걸쳐 수집되며, 정보가 제공되는대로 처리해야합니다. 이것은 비즈니스 요구 사항입니다. –

관련 문제