redis - 쿠폰 대기열 문제

Question

사용자가 쿠폰 수집 페이지에서 쿠폰을 받기 위해 클릭하면 백엔드 서비스 인터페이스 A가 호출되고 인터페이스 A는 대기열에 수집 작업을 씁니다.

으아악

그럼 큐에 쓴 후 루프에서 큐를 읽는 건가요? 사용자는 여전히 성공적인 결과를 기다리고 있습니다.

Answer 1

https://redis.io/topics/pubsub

Redis는 게시/구독을 지원합니다

Answer 2

내가 아는 것은 쿠폰 성공 페이지(또는 더 나은 경험을 위해 redis pubsub가 있는 웹소켓)에서 설문 조사를 수행하여 최종 결과를 얻는 것입니다.

Answer 3

제품 요구 사항은 동기식이며(결과는 동기식으로 반환됨) 대기열은 주로 주문, 알림 등과 같은 비동기식 구현을 달성하는 데 사용됩니다.
큐를 사용하여 동기화 결과를 시뮬레이션하려는 경우 쿠폰 결과만 별도로 얻을 수 있습니다.

"Redis는 게시/구독을 지원합니다": 이 모드를 사용하는 데 몇 가지 문제가 있습니다

1. 정의해야 할 채널이 너무 많습니다. 하나의 채널을 재사용하는 경우 구독자는 많은 메시지를 필터링해야 하며 텍스트 프로토콜이 필요합니다(게시에서는 텍스트만 지원)

2. 서비스 요청 후, 답변을 받기 전에 전화가 끊기면 쿠폰정보가 사라집니다

제안사항은 다음과 같습니다.

1. 가장 좋은 방법은 비동기식 요청을 동기식 요청으로 수정하는 것입니다

2. 그렇지 않으면 요청 처리 결과를 해시(id-> 결과)에 넣는 것을 고려할 수 있습니다.

Answer 4

비동기식이고 수집 요청을 통해 수집 결과가 반환되지 않는 경우 위에서 언급한 것처럼 ajax를 사용하여 수집 결과를 얻으면 루프에서 요청을 시작하는 데 ajax가 필요하지 않습니다. 폴링의 경우 폴링이 포함되는 한 문제가 발생합니다. 폴링 간격이 너무 짧으면 서버에 큰 부담이 됩니다. 결과 통보 및 접수가 늦어질 수 있습니다.

동기화를 원하지 않는 경우에는 websocket을 사용하면 두 당사자가 언제든지 지연 없이 통신하고 데이터를 교환할 수 있습니다.
또는 SSE(서버 전송 이벤트)를 사용하여 직접 푸시할 수 있습니다. WebSocket은 양방향이고 SSE는 단방향이므로 메시지 푸시에 충분합니다.

으아악

SSE 링크SSE

서버의 내부 작업 프로세스는 여러 가지 옵션이 있으며 중간에 캐시 또는 mq 계층을 추가하면 비동기 작업이 가능합니다. 예를 들어 zmq, redis pub/sub 등이 있습니다.

Answer 5

지식을 추구합니다. . . .