이 HTTP 요청의 반환 결과를 데이터베이스 작업 결과와 연관시키려는지 여부와 사용자 상호 작용 디자인이 이 작업에 소요되는 시간을 허용하는지 여부에 따라 다릅니다.

이 '/blog' 인터페이스를 디자인할 때 HTTP가 200을 반환할 때의 의미를 명확하게 표시해야 합니다. 비즈니스 시나리오가 백엔드로의 데이터 전달에만 관심이 있고 백엔드가 데이터베이스에 올바르게 저장되었는지 여부에는 관심이 없다면 확실히 HTTP 요청을 직접 종료할 수 있습니다. 최종 사용자가 정확한 제출 결과를 얻으려면 상호 작용 수준을 고려해야 합니다. 좋은 상호 작용 효과를 디자인하고 2~6초 정도 기다리면 사용자 경험이 나쁘지 않을 것입니다(AJAX 요청 시나리오 참조, 열기). 새로운 페이지 시나리오) 여전히 조심하세요). Redis에 세 번 쓰는 것은 거의 시간이 걸리지 않으며 HTTP 요청 자체의 링크 지연에 비하면 아무 것도 아닙니다.

특정 비즈니스 시나리오를 자세히 분석해야 합니다. 특히 시간이 많이 걸리는 작업이 발생할 경우 프런트 엔드에서 작업 요청을 제출한 후 결과를 회전시키는 것도 솔루션입니다.

페이지 표시와 데이터베이스 작업 결과 사이에 상관 관계가 있는지 확인하세요. 상관관계가 있는 경우 데이터베이스 작업이 완료될 때까지 기다렸다가 반환할 수 있습니다. 비동기 대기열에서 직접 반환될 수도 있으며 성공 후 결과가 푸시됩니다. 결국 그것은 모두 귀하의 필요에 달려 있습니다.