메시지 대기열을 사용해야 합니까? 사용해야 하는 이유에 대해 이야기해 봅시다.

이 글은 메시지 대기열을 사용하는 이유와 메시지 대기열을 사용해야 하는 이유를 주로 소개합니다. 관심 있는 친구들이 함께 살펴보는 것이 도움이 되기를 바랍니다. . 모두가 도움이 됩니다.

메시지 대기열을 사용하는 이유 여섯 단어 요약: 분리, 비동기, 피크 제거

1) Decoupling

기존 모드에서는 시스템 간 결합이 너무 강합니다. 어떻게 표현하면, 시스템 A는 인터페이스 호출을 통해 세 시스템 B, C, D에 데이터를 보냅니다. 나중에 시스템 E가 연결되거나 시스템 B가 연결될 필요가 없다면 시스템 A는 여전히 수정해야 합니다. 매우 번거로운 코드입니다.

시스템 A가 상대적으로 중요한 데이터를 생성한다면 시스템 B, C, D, E가 실패할 경우 어떻게 해야 할지 항상 고려해야 할까요? 다들 이 데이터를 받았나요? 분명히 시스템 A는 다른 시스템과 밀접하게 결합되어 있습니다.

그리고 메시지 대기열에 데이터(메시지)를 쓰면 메시지가 필요한 시스템이 메시지 대기열 자체에서 해당 데이터를 직접 소비합니다. 이런 식으로 시스템 A는 누구에게 데이터를 보낼지, 이 코드를 유지할 필요가 없고, 다른 시스템의 성공적 호출 여부, 실패 시간 초과 등을 고려할 필요가 없습니다. 어쨌든 책임은 나에게만 있습니다. 생산을 위해 다른 것은 신경 쓰지 않습니다.

2) Asynchronous

먼저 전통적인 동기화 상황을 살펴보겠습니다. 예를 들어 시스템 A는 사용자 요청을 받고 라이브러리 쓰기 작업을 수행해야 하며 B에서도 동일한 작업을 수행해야 합니다. C, D. 시스템에서 라이브러리 쓰기 작업을 수행합니다. A가 로컬에서 라이브러리를 쓰는 경우 1ms만 소요되는 반면 세 시스템 B, C, D는 각각 100ms, 200ms, 300ms가 걸립니다. 최종 총 요청 지연은 1 + 100 + 200 + 300 = 601ms로, 이는 사용자 경험을 크게 감소시킵니다.

메시지 대기열을 사용하는 경우 시스템 A는 메시지 대기열에 3개의 메시지만 보내면 됩니다. 5ms가 걸리면 시스템 A가 요청을 수락하고 사용자에게 응답을 반환하는 데 걸리는 총 시간은 1입니다. + 5 = 6ms 사용자에게는 경험 만족도가 직접적으로 극대화됩니다.

3)피크 제거

캐시나 메시지 대기열을 사용하지 않는 경우 시스템은 MySQL 데이터베이스를 직접 기반으로 하며 이러한 피크 기간이 있으면 많은 수의 요청이 생성됩니다. MySQL에 쏟아부으면 시스템이 직접 충돌할 것이라는 데에는 의심의 여지가 없습니다.

그런 다음 메시지 대기열을 사용하면 MySQL은 초당 최대 1,000개의 데이터를 처리할 수 있으며 피크 기간 동안 5,000개의 데이터가 즉시 쏟아집니다. 그러나 이 5,000개의 데이터가 메시지에 쏟아집니다. 대기줄. 이러한 방식으로 우리 시스템은 데이터베이스 성능에 따라 메시지 대기열에서 요청을 천천히 끌어올 수 있으며 초당 처리할 수 있는 최대 요청 수를 초과하지 않습니다.

즉, 초당 5,000개의 요청이 들어오고 1,000개의 요청이 메시지 대기열에서 나갑니다. 피크 기간이 1시간이라고 가정하면 이 동안 수십만 또는 심지어 수백만 개의 요청이 메시지 대기열에 백로그될 수 있습니다. 기간. 그러나 이 단기 피크 기간 백로그는 완전히 허용됩니다. 피크 기간 이후에는 초당 메시지 큐에 들어가는 요청이 그리 많지 않지만 데이터베이스는 여전히 초당 1,000개의 요청 속도로 처리되기 때문입니다. 따라서 피크 기간이 끝나면 시스템은 메시지 백로그를 신속하게 처리합니다.

추천 학습: "Redis 비디오 튜토리얼"

위 내용은 메시지 대기열을 사용해야 합니까? 사용해야 하는 이유에 대해 이야기해 봅시다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!