그래서 Google의 Pub/Sub 서비스를 대기열에 사용하려고했지만 시행 착오를 통해 실제 애플리케이션에서 어떤 것이 좋은지 전혀 알 수 없다는 결론에 도달했습니다.Google Pub/Sub의 목적은 무엇입니까?
구글은
하지만 방법은이 일이 나에게 정말 이상하다위한 글로벌 서비스 있다고 말한다. 구독자가 다시 구독하는 경우 최대 7 일간의 확인 된 메시지를 보관합니다. 이미 응답 한 경우에도 지난 7 일 동안의 모든 메시지를 받게되며, 확인 된 메시지는 이미 해당 구독자에게 다시 전송됩니다. FIFO도 없습니다.실시간 및 신뢰할 수있는 메시징 및 스트리밍 데이터
그래서이 서비스가 보장되는 유일한 방법은 메시지가 구독자에게 한 번 이상 전달된다는 것입니다. 이것은 멱등 원 행동에 사용할 수 없습니다. 각 구독자는 이미 확인 된 모든 메시지에 대한 정보를 저장해야하므로 여러 번 메시지를 처리하지 않습니다.
Google Cloud Pub/Sub has lot lot 분리 된 시스템이 메시지를 송수신해야하는 다양한 애플리케이션 overview page은 작업로드, 로깅 및 이벤트 알림의 균형을 잡는 등 많은 사용 사례를 제공합니다. Google Cloud Pub/Sub는 현재 어떠한 FIFO 보장도 제공하지 않으며 메시지를 다시 전달할 수 있습니다.
그러나 배달 보증이 "적어도 한 번"이라는 사실은 구독자가 다시 구독 할 때 확인 된 메시지가 다시 배달된다는 의미가 아닙니다. 확인 된 메시지의 재 전달은 드문 경우입니다. 이것은 일반적으로 ack가 네트워킹 문제, 기계 고장 또는 기타 예외적 인 상황으로 인해 서비스로 돌아 가지 않은 경우에만 발생합니다. 즉, 앱에서이 사례를 처리 할 수 있어야한다는 의미 일 수는 있지만 앱이 자주 발생한다는 것을 의미하지는 않습니다.
다른 응용 프로그램의 경우 메시지 재전송시 발생하는 상황이 다를 수 있습니다. 개요 페이지에서 언급 한 캐시 무효화와 같은 경우에는 캐시의 항목을 무효화하기위한 두 개의 이벤트를 얻는 것만으로 값이 추가 시간을 다시로드해야 함을 의미하므로 정확성에 대한 우려는 없습니다.
로깅이나 통계 목적으로 버튼 클릭이나 웹 사이트의 다른 이벤트를 추적하는 것과 같이, 드물게 확인 된 메시지 재전송은 중요한 방식으로 수집 된 정보에 영향을 미치지 않으므로 이벤트가 있는지 확인하지 않아도됩니다 중복은 괜찮습니다.
메시지가 정확히 한 번 처리되도록하려면 구독자 측에서 추적해야합니다. 구독자가 메시지에 대한 응답으로 기본 데이터베이스에 이미 액세스하고 업데이트하고있을 수 있으며 중복 이벤트는 해당 저장소를 통해 검색 될 수 있습니다.
물론 구독자의 승인 된 메시지를 추적 할 수 있습니다. 문제는 Pubsub를 대기열로 사용하고 작업자가 임시 (kubernetes) 일 경우 중앙 DB없이이 정보를 추적 할 수있는 방법이 없습니다. 첫 번째 장소. 따라서 제 질문은 의미합니다 : PubSub의 목적은 무엇입니까? –
매우 구체적인 유스 케이스를 염두에두고있는 것처럼 들리므로 유스 케이스로 질문을 업데이트하는 것이 좋습니다. 게시자와 가입자가 밀접하게 결합 된 경우 단일 중앙 데이터베이스에 액세스 할 수 있으며 대기열의 처리량이 상대적으로 적 으면 Pub/Sub가 사용자의 요구 사항을 반드시 충족시키지 않을 수도 있습니다. 그러나 "실제 응용 프로그램에서 어떤 것이 좋은지 전혀 알지 못한다"고 말하는 것이 큰 도약입니다. 나는 적어도 한 번 납품이 문제가되지 않는 경우를 언급했다. –
가입자가 이미 확인 응답 한 메시지를 다시 수신하는 경우는 거의 없습니다. 이런 일이 정기적으로 발생하는 경우 지원 티켓을 열어 GCP 담당자가 문제의 원인을 파악하는 데 도움을 줄 것을 제안합니다. –
실제로 그것은 드물지 만 오히려 정상적인 것은 아닙니다. 그리고 "버그"가 아니라 문서화 된 동작입니다. Pubsub는 한 번만 배달하는 것이 아니라 적어도 한 번 배달을 보장합니다. –