전염병 기간 동안 중급 PHP 인터뷰의 핵심 사항을 기록하십시오-PHP 튜토리얼-php.cn

전염병으로 인해 화상면접입니다. A측 라인업에는 인사담당자 1명, 제품관리자 1명이 포함되어 있습니다. 이번 면접의 직접적인 책임자는 기술이사 A입니다. 나머지 2명은 서로 다른 부서장인 것으로 보입니다(B와 C). ) 같은 위치에 있습니다(글쎄, 모두 35세 이상입니다).

말을 많이 하지 않고 바로 본론으로 들어가겠습니다. (콜론으로 구분하고 싶은 분들도 계시는데 키보드의 콜론 키와 탭이 깨져 있는 것 같습니다.)

처음에 hr님이 인터뷰에 참여한 멤버들과 포지션을 소개해 주시고, 이어서 질문을 이해해 주셨어요. 관리자가 Ben에게 사임 이유와 알고 싶은 질문을 물었습니다.

이제 진짜 드라마가 시작됩니다.

국장A: MySQL에 매우 능숙하신 것으로 보아 MySQL의 격리 수준에 대해 말씀해 주십시오. .

나: MySQL 트랜잭션의 격리 수준은 가장 높은 것부터 커밋되지 않은 읽기, 커밋된 읽기, 반복 가능한 읽기 및 직렬화입니다. MySQL의 기본 격리 수준은 반복 가능한 읽기입니다. 트랜잭션 동시성으로 인해 발생할 수 있는 문제는 더티 읽기입니다. , 비반복 읽기, 팬텀 읽기, 이러한 상황을 일으키는 작업과 해결 방법을 각각 자세히 설명합니다.

국장 A: 실제 시나리오에서 격리 수준을 수정하는 전략은 무엇입니까?

나: .... (여기서 생략 부호는 제가 헛소리를 했다는 의미입니다. 사실 수천만 건의 방문 데이터만 처리했기 때문에 조금 혼란스럽습니다. 하지만 동시성이 높지 않기 때문에 격리 섹터 수정이 포함되지 않거나 일반적으로 충분히 깊이 생각하지 않습니다.)

Director A: innodb의 인덱스는 무엇이며 어떻게 구현됩니까?

Me: 기본 키는 B-트리, B+ 트리, 해시로 구현할 수 있는 고유한 일반 조인트 인덱스입니다.

디렉터 A: 이러한 구현의 차이점은 무엇인가요? 인덱스를 설계할 때 어떤 전략을 사용하여 선택하시나요?

Me: B-트리와 B+ 트리는 리프 노드에 대한 데이터와 트리의 깊이가 다릅니다. 동일한 검색을 위해 B-트리는 B+-트리보다 1개의 더 많은 IO가 필요합니다. 실제 비즈니스 시나리오에 따라 다른 인덱스 알고리즘을 선택합니다. 읽기가 많고 쓰기가 적다면 B + 트리를 선택하겠습니다. (사실 잊어버렸기 때문에 잘 모르겠습니다.)

디렉터 A: MySQL 잠금의 분류 및 기능 , 실제 사용 시나리오는 무엇입니까?

나: (이전 인터뷰들이 얕은 부분부터 깊은 부분까지 진행되어서 이때 조금 긴장했어요.)... 그리고 제가 이해한 바를 간략하게 설명했는데, 사실 답변이 만족스럽지 못했어요. B와 C도 다른 질문을 삽입하기 때문이죠.

디렉터 B: 분산에 대해 잘 알고, 분산 잠금 구현 방법을 알고, etcd에 대해 배운 적이 있나요?

나: redis의 setnx와 만료 시간을 함께 사용하여 이를 구현할 수 있습니다. 이전에 내 비즈니스에서 etcd를 구현했지만 이것을 이해한 적이 없기 때문입니다(내 마음 속에는 이 개념이 없습니다). 그리고 (중단)

이사 C: 시간이 제한되어 있습니다. 계속해서 PHP 최적화를 완료했는지, opcahche 사용 방법을 살펴보겠습니다.

나: (잠시 고민하다가) 연산 코드 파싱 최적화.

이사 C: opcode가 어디 있지?

나: 전혀 감이 안 잡히는데, (정말 감이 안 온다. 이전 비즈니스 시나리오에서는 프런트엔드, CDN, 서버 리버스 프록시, 데이터베이스 캐시, 프로그램 로직 코드 최적화부터 시작해서 프로젝트가 질적으로 향상되었지만 유일하게 opchache와 접촉하지 않는 부분이 있고 뭔 실수야)

디렉터 C: url이 일어나는 과정을 간략하게 설명하고 집중하세요

내 브라우저는 url을 입력해서 IP로 파싱한 후 웹 서버에 요청을 보냅니다. nginx에서는 cgi를 통해 PHP-FPM으로 전송된 다음 PHP 스크립트가 구문 분석하고 논리를 처리하고 데이터를 응답할 때까지 기다립니다.

디렉터 C: cgi는 무엇이며 어디에 사용되나요?

나: cgi는 PHP와 같은 언어가 웹 서버와 통신하기 위한 프로토콜입니다.

디렉터 B: PHP-FPM의 아키텍처 모델은 무엇이며 어떻게 최적화했나요?

나: 마스터(메인)-워커(워커 프로세스) 아키텍처 모델입니다. 실제로 요청을 처리하는 작업 프로세스입니다. 마스터가 주로 하위 프로세스를 관리하고 재활용합니다. 구성에 대해 간략하게 요약하자면, 이전에 구성된 정적 모드로 인해 기본 프로세스 수는 200이었습니다. 나중에 특정 동시성이 발생하면 "세 번째" 구성 모드로 변경하고 구성해야 합니다. 지정된 프로세스 수에는 최소값과 최대값이 있습니다(여기서 최대값은 실제로 잊어버렸습니다. 제한이 없어야 한다고 생각합니다. 결국 하드웨어 리소스는 한계입니다). 그런 다음 프로세스 수를 동적으로 늘립니다. 실제 요청 수를 기준으로 합니다.

B국장: 또 다른 최적화는 없나요?

나: (잠시 침묵을 지켰습니다. 사실 개정하면서 다른 부분을 수정했는데 깜빡하고 있었네요. 인터뷰가 길어지는 느낌이 들었어요) 그리고 그 당시에는 다른 최적화에서 나온 것인데 기억이 나지 않습니다.

B디렉터: 당신이 사용하는 Rabbitmq와 그에 대한 이해도를 알려주세요.

나: (rabbitmq의 아키텍처를 간략하게 설명) 그리고 나의 사용 시나리오와 비즈니스.

디렉터 B: 토픽 모드 사용하는 방법 알려주세요

나: (토픽 사용 과정을 간략하게 설명했는데, 합격으로 간주됩니다.)

국장 A: Redis 샤딩에 대해 이야기해 보겠습니다.

나: 샤딩은 키를 여러 개의 Redis 인스턴스로 나누는 과정입니다. 여러 컴퓨터의 메모리와 CPU 처리 능력을 사용하여 ,,,,

감독 A: 순위 구현 방법

나: 점수가 있어서 레디스 세트를 주문했는데,,,

디렉터 A: 그 함수를 이용해서 값을 구해요

나: (기억이 나네요, 정말 기억이 안나네요) 이게 무슨 멤버 함수인지 잊어버렸네요.