높은 동시성에 관한 15가지 PHP 인터뷰 질문(요약)-PHP 튜토리얼-php.cn

높은 동시성에 관한 15가지 PHP 인터뷰 질문(요약)

추천 관련 기사: ""높은 동시성 및 대규모 트래픽" 액세스를 위한 솔루션 및 솔루션에 대한 심층 토론 "

1 AMQP를 사용하는 Rabbitmq

이란 무엇입니까? 고급 메시지 큐 프로토콜 메시지 큐 기술의 일종으로, 서비스 간 높은 수준의 분리를 달성하기 위해 소비가 공급자의 존재를 보장할 필요가 없다는 것이 가장 큰 특징입니다

2. Rabbitmq를 사용하는 이유

분산 시스템의 비동기 기능, 피크 클리핑, 로드 밸런싱 및 일련의 고급 기능이 있습니다.
지속성 메커니즘, 프로세스 메시지 및 대기열의 정보도 저장할 수 있습니다.
소비자와 생산자 간의 분리를 달성합니다.
동시성이 높은 시나리오의 경우 메시지 대기열을 사용하면 동기 액세스를 직렬 액세스로 전환하여 특정 양의 현재 제한에 도달할 수 있으며 이는 데이터베이스 작업에 도움이 됩니다.
메시지 대기열을 사용하여 비동기식 주문 배치 효과를 얻을 수 있습니다. 대기열 중에 논리적 주문이 백그라운드에 배치됩니다.

3.rabbitmq를 사용한 시나리오

서비스 간 비동기 통신
순차적 소비
최대 요청 절단

발신자 확인 모드

채널을 확인 모드(발신자 확인 모드)로 설정하면 채널에 게시된 모든 메시지에 고유 ID가 할당됩니다. 메시지가 대상 대기열로 전달되거나 메시지가 디스크에 기록되면(지속 메시지) 채널은 생산자에게 확인 메시지(고유 메시지 ID 포함)를 보냅니다.

RabbitMQ에서 내부 오류가 발생하여 메시지가 손실되면 nack(승인되지 않음) 메시지가 전송됩니다.

발신자 확인 모드는 비동기식이므로 생산자 애플리케이션은 확인을 기다리는 동안 계속해서 메시지를 보낼 수 있습니다. 확인 메시지가 생산자 애플리케이션에 도달하면 생산자 애플리케이션의 콜백 메서드가 트리거되어 확인 메시지를 처리합니다.

수신자 확인 메커니즘

수신자 메시지 확인 메커니즘

소비자는 각 메시지를 받은 후 확인해야 합니다(메시지 수신과 메시지 확인은 서로 다른 작업입니다). 소비자가 메시지를 확인한 경우에만 RabbitMQ가 대기열에서 메시지를 안전하게 삭제할 수 있습니다. 여기에는 시간 초과 메커니즘이 사용되지 않습니다. RabbitMQ는 소비자 연결 중단을 통해 메시지를 다시 보내야 하는지 여부만 확인합니다. 즉, 연결이 중단되지 않는 한 RabbitMQ는 소비자에게 메시지를 처리할 충분한 시간을 제공합니다. 데이터의 궁극적인 일관성을 보장합니다.

몇 가지 특별한 경우가 아래에 나열되어 있습니다.

소비자가 메시지를 받고 확인하기 전에 연결을 끊거나 구독을 취소하면 RabbitMQ는 메시지가 배포되지 않았다고 생각한 다음 이를 다시 배포합니다. 다음 구독 소비자. (메시지 반복 소비의 숨겨진 위험이 있을 수 있으며 중복 제거가 필요함)

소비자가 메시지를 받았지만 메시지를 확인하지 않고 연결이 끊어지지 않으면 RabbitMQ는 소비자가 바쁘다고 간주하여 연결을 끊지 않을 것입니다. 더 많은 소식을 소비자에게 배포하세요.

메시지 생성 중에 MQ는 생성자가 전송한 각 메시지에 대해 내부 msg-id를 생성합니다. 이는 중복 메시지가 대기열에 들어가는 것을 방지하기 위해 중복 제거(메시지 전달이 실패하고 재전송됨)의 기반으로 사용됩니다. 메시지를 소비할 때 동일한 내용이 반복적으로 소비되지 않도록 중복 제거를 위한 기반으로 메시지 본문에 bizId(결제 ID, 주문 ID, 게시물 ID 등과 같이 동일한 비즈니스에 대해 전역적으로 고유함)가 있어야 합니다. 메시지.

6. 메시지는 어떤 기준으로 전송되나요?

TCP 연결을 생성하고 파괴하는 데 드는 오버헤드가 크고 시스템 리소스에 따라 동시성 수가 제한되어 성능 병목 현상이 발생합니다. RabbitMQ는 채널을 사용하여 데이터를 전송합니다. 채널은 실제 TCP 연결 내에 설정된 가상 연결이며 각 TCP 연결의 채널 수에는 제한이 없습니다. 7. 메시지를 전달하는 방법은 무엇입니까?

대기열에 하나 이상의 소비자 구독이 있는 경우 메시지는 라운드 로빈 방식으로 소비자에게 전송됩니다. 각 메시지는 구독한 소비자 한 명에게만 배포됩니다(소비자가 메시지를 정상적으로 처리하고 확인할 수 있는 경우). 라우팅을 통해 다중 소비 기능을 실현할 수 있습니다8. 메시지를 라우팅하는 방법은 무엇입니까?

메시지 공급자->라우팅->일대다 대기열 메시지가 교환기에 게시되면 메시지는 메시지 생성 시 설정되는 라우팅 키를 갖게 됩니다. 대기열 라우팅 키를 통해 대기열을 스위치에 바인딩할 수 있습니다.

메시지가 교환기에 도착한 후 RabbitMQ는 메시지의 라우팅 키를 대기열의 라우팅 키와 일치시킵니다(교환마다 다른 라우팅 규칙이 있음)

일반적으로 사용되는 교환은 주로 다음 세 가지 유형으로 나뉩니다.

fanout: exchange가 메시지를 받으면 바인딩된 모든 대기열에 브로드캐스팅됩니다.
direct: 라우팅 키가 완전히 일치하면 메시지가 해당 대기열에 전달됩니다.
topic: Can 소스의 다른 메시지가 동일한 대기열에 도착할 수 있습니다. 주제 교환기를 사용할 때 와일드카드를 사용할 수 있습니다

9. 메시지가 손실되지 않도록 하는 방법은 무엇입니까?

물론, 메시지 지속성은 대기열이 지속되어야 한다는 전제입니다. RabbitMQ가 서버 재시작 시 지속성 메시지를 복구할 수 있도록 보장하는 방법은 지속성 메시지를 디스크에 게시할 때 해당 메시지를 지속성 로그 파일에 기록하는 것입니다. 지속적 교환 시 Rabbit은 메시지가 로그 파일에 커밋될 때까지 응답을 보내지 않습니다.

소비자가 지속성 대기열에서 지속성 메시지를 소비하면 RabbitMQ는 지속성 로그의 메시지를 가비지 수집을 기다리는 것으로 표시합니다. 지속성 메시지가 사용되기 전에 RabbitMQ가 다시 시작되면 Rabbit은 자동으로 교환 및 대기열(및 바인딩)을 다시 작성하고 지속성 로그 파일의 메시지를 적절한 대기열에 다시 게시합니다.

10. RabbitMQ를 사용하면 어떤 이점이 있나요?

1. 높은 수준의 서비스 간 분리

2. 높은 비동기 통신 성능

3. 트래픽 피크 감소

11. RabbitMQ 클러스터

귀하가 생성한 대기열 , 큐의 메타데이터와 메시지는 모두 여러 인스턴스에 존재하며, 큐에 메시지를 쓸 때마다 메시지는 메시지 동기화를 위해 자동으로 여러 인스턴스의 큐로 전송됩니다.

좋은 점은 컴퓨터 중 하나가 다운되더라도 문제가 되지 않으며 다른 컴퓨터를 사용할 수 있다는 것입니다. 단점은 첫째, 성능 오버헤드가 너무 높다는 점입니다. 메시지가 모든 시스템에서 동기화되어 네트워크 대역폭 압박과 소비가 심해집니다. 둘째, 이렇게 플레이하면 확장성이 없습니다. 대기열의 로드가 너무 많아 머신을 추가하면 새 머신에도 대기열의 모든 데이터가 포함됩니다.

12.mq의 단점

시스템 가용성 감소

시스템에 외부 종속성이 많을수록 충돌이 발생하기 쉽습니다. 원래는 세 가지 시스템 BCD, ABCD 4의 인터페이스를 호출하는 시스템입니다. 시스템은 괜찮고 문제가 없습니다. MQ를 추가하면 MQ가 실패하면 어떻게 되나요? MQ가 중단되고 전체 시스템이 붕괴되면 파멸에 이르게 됩니다.

시스템 복잡성이 증가합니다

MQ를 갑자기 추가하는 경우 메시지가 반복적으로 소비되지 않도록 어떻게 보장할 수 있나요? 메시지 손실을 처리하는 방법은 무엇입니까? 메시지 전달 순서를 어떻게 보장하나요? 큰 머리, 큰 머리, 많은 문제, 끝없는 고통

13. 일관성 문제

시스템은 처리 후 직접 성공을 반환하고 사람들은 귀하의 요청이 성공했다고 생각하지만 문제는 BCD 3이 둘 다인 경우입니다. 시스템에서는 BD 시스템이 라이브러리를 성공적으로 작성했지만 C 시스템은 라이브러리 작성에 실패했습니다. 어떻게 해야 합니까? 귀하의 데이터가 일관되지 않습니다.

그래서 메시지 큐는 실제로 매우 복잡한 아키텍처입니다. 이를 도입하면 많은 이점이 있지만, 이것이 가져오는 단점을 피하기 위해 다양한 추가 기술 솔루션과 아키텍처도 만들어야 합니다. 맙소사, 시스템 복잡성이 수십 배, 어쩌면 10배 더 복잡해졌습니다. 하지만 중요한 순간에는 사용해야 합니다

14. 분산 트랜잭션

단계적으로 제출하세요. 중재자가 있고 모든 노드에 메시지를 보냅니다. 성공은 모든 노드가 승인된 후에만 발생합니다. 그렇지 않으면 재전송을 기다려야 합니다.

15. 생방송 등 갑작스러운 대규모 교통 상황에 대비한 설계 방법.

NGINX 플러스 머신