2023년 최신 PHP 면접 질문 28개 공유(답변 포함)-PHP 튜토리얼-php.cn

이 기사는 기본 지식을 정리하는 데 도움이 되는 28개의 PHP 인터뷰 질문(공유할 답변 포함)을 정리하고 공유합니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.

2023년 최신 PHP 면접 질문 28개 공유(답변 포함)

관련 추천 : 2023년 PHP 면접 질문 모음(모음)

새해 이후 새로운 취업 기회를 찾아볼 계획인데, 기본적인 면접에 대한 이해와 공부가 많았다. 이전에는 충분히 깊지 않았습니다. 앞으로 나아갈 수 있도록 격려하기 위해 최근 포럼과 검색 엔진에서 관련 지식을 배우고 요약하기 시작했습니다. 질문 중 일부는 포럼에서 선배들이 공유하는 질문이나 답변이며 일부는 질문입니다. 최근 인터뷰에서 접한 내용을 바탕으로 제가 이해한 부분과 선배님들의 공유를 모아서 다른 친구들에게도 도움이 되었으면 하는 마음으로 공유합니다. 오해는 앞으로 계속 업데이트하겠습니다

1. PHP 배열 기본 구현 원리

1 기본 구현은 해시 테이블(해시 테이블) + 이중 연결 리스트(해시 충돌 해결)를 통해 이루어집니다.

2. 질서를 유지하는 방법

3. 해시 중복 해결(PHP에서 사용하는 연결 목록 방식):

4. 기본 지식

연결 목록: 큐, 스택, 이중 연결 목록,

참조:

알고리즘의 시간 복잡도와 공간 복잡도에 대해 설명하는 기사

2. 버블 정렬의 시간 복잡도와 공간 복잡도

1, 코드 구현

$arr = [2, 4, 1, 5, 3, 6]; for ($i = 0; $i < (count($arr)); $i++) { for ($j = $i + 1; $j < (count($arr)); $j++) { if ($arr[$i] <= $arr[$j]) { $temp = $arr[$i]; $arr[$i] = $arr[$j]; $arr[$j] = $temp; } } } result : [6,5,4,3,2,1]
로그인 후 복사

2. 계산 원리

1차: 배열의 첫 번째 요소를 다른 모든 요소와 비교 . 어느 요소가 더 큰지 순서를 변경한 다음 첫 번째 요소를 버블링합니다. 하나의 (가장 큰) 요소

O(n^2)

최적의 시간 복잡도: O(n) , 첫 번째 루프에서 교환이 없으면 점프해야 합니다. 루프에서 직접 빠져나옴

O( 1)

최적의 공간 복잡도: O(1), 정렬 , 위치 교환 필요 없음O(n^2) ；

最优时间复杂度：O(n) ，需要加判断，第一次循环如果一次都没有交换就直接跳出循环

空间复杂度：O(1)，交换元素的时候的临时变量占用的空间

最优空间复杂度：O(1)

3. 시간 복잡도 및 공간 복잡도

시간 복잡도: 전체 프로세스는 점근적 시간 복잡도로 프로세서의 효율성을 추정합니다(알고리즘의 효율성 추세를 설명하는 것은 특정 항목을 참조하지 않음). 알고리즘이 사용하는 시간, 서로 다른 기계의 성능이 일관되지 않기 때문에 일반적인 효율성 계산 방법)

표현 방법: Big O 표기법

복잡도 수준:

Constant order O(1)
선형 순서 O(n)
제곱 순서 O(n²)
3차 순서 O(n³)
K번째 순서 O(n^k)
지수 순서( 2^ n)
대수 순서 O(logN)
선형 로그 순서 O(nlogN)

시간 복제 유형:

최고의 시간 복잡도
최악의 시간 복잡도
평균 시간 복잡도
분할 시간 복잡도

공간 복잡도: 전체 점근적 공간 복잡도, 컴퓨터 메모리 사용량 추정(알고리즘이 차지하는 저장 공간의 추세를 기술함, 실제 점유 공간이 아님, 위와 같음)

참고자료:
알고리즘의 시간 복잡도와 공간 복잡도에 대해 이야기하는 기사

3. 네트워크 7계층 프로토콜과 TCP 및 TCP

애플리케이션 계층, 프리젠테이션 계층, 세션 계층, 전송 레이어, 네트워크 레이어, (데이터) 링크 레이어, 물리 레이어

메모리 루틴:

첫 번째 단어: 테이블 간 전송(사물 체인 네트워크)

첫 번째 단어: 애플리케이션 레이어(발생 횟수(더 많음, 쉽게 발생) 기억하세요)

처음 4개의 정방향: 표현되어야 함 - 전송될 것입니다

마지막 3개의 역방향: 사물 인터넷의 동음이의어는 사물 인터넷보다 기억하기 더 쉽습니다

4. 두 가지의 특징 및 차이점 TCP 및 UDP

1. 모두 전송 계층 프로토콜입니다

2. TCP

는 연결 지향적이므로 일대일
만 가능합니다. 전송
데이터는 안정적이며 손실되지 않습니다
전이중 통신

3. UDP(TCP 특성에 따라 역방향)

연결 없음, 일대일 지원 , 일대다, 다대다
열 보존 전송을 지향합니다
헤더 오버헤드가 작고 데이터가 반드시 신뢰할 수 있는 것은 아니지만 속도는 빠릅니다

5. TCP's 3방향 핸드셰이크 및 4방향 웨이브

1. 3방향 핸드셰이크:

1) 처음: 클라이언트가 SYN = 1, seq = client_isn
을 보냅니다. 기능:
클라이언트: 없음
서버: 자신의 수신 기능과 클라이언트의 송신 기능을 확인
2) 두 번째: 서버가 SYN = 1을 보냅니다. SEQ = Server_ISN, ACK = Client_isn +1

:
3) 세 번째: 클라이언트가 보냅니다. SYN = 0, ACK = server_isn+1,seq =client_isn+1

2. 4번 웨이브

1) 첫 번째: 클라이언트가 FIN
2) 두 번째: 서버가 ACK
3) 세 번째 : 서버가 FIN을 보냅니다
4) 네 번째 : 클라이언트가 ACK를 보냄

6. HTTP 상태 코드

1. 상태 코드 분류

2, 공통 상태 코드

🎜400 잘못된 요청: 클라이언트 요청 구문 오류🎜
401 무단: 클라이언트에 권한이 없습니다
403 금지됨: 서버가 클라이언트 요청을 거부합니다
404 찾을 수 없음: 클라이언트가 요청한 리소스가 존재하지 않습니다
500 내부 서버 오류: 서버 내부 오류
502 불량 게이트웨이: 게이트웨이 또는 프록시로 작동하는 서버가 요청 수행을 시도할 때 업스트림 서버에서 잘못된 응답을 수신합니다.
503 서비스를 사용할 수 없는 과부하 또는 시스템 유지 보수
504 게이트웨이 시간 초과: 게이트웨이 시간 초과

3, 502

원인: nginx가 예외를 처리하기 위해 게이트웨이(php-fpm)에 요청을 제출하여

1) fastcgi 버퍼 설정은 다음과 같습니다. 너무 작음

fastcgi_buffers 8 16k;</ code><code>fastcgi_buffers 8 16k;

fastcgi_buffer_size 32k;

2）php-cgi的进程数设置过少

查看FastCgi进程数：netstat -anpo | grep "php-cgi"| wc -l

调整参数最大子进程数：max_children

一般按照单个进程20M计算需要需要设置的子进程数

3）max_requests（内存溢出或频繁重启）

参数指明每个children最多能处理的请求数量，到达最大值之后会重启children。

设置过小可能导致频繁重启children：

php将请求轮询给每个children，在大流量的场景下，每一个children 到达最大值的时间差不多，如果设置过小可能多个children 在同一时间关闭，nginx无法将请求转发给php-fpm，cpu降低，负载变高。

设置过大可能导致内存泄露

4）php执行时间超过nginx等待时间

fastcgi_connect_timeout

fastcgi_send_timeout

fastcgi_read_timeout

5）fastcgi执行时间

max_execution_time

하위 프로세스의 최대 수를 조정합니다. max_children
일반적으로 하위 프로세스의 수는 설정해야 하는 값은 단일 프로세스당 20M을 기준으로 계산됩니다.
3) max_requests(메모리 오버플로 또는 빈번한 재시작)
매개변수는 각 하위 항목이 처리할 수 있는 최대 요청 수를 나타냅니다. 최대값에 도달한 후 하위 항목이 다시 시작됩니다. .
너무 작게 설정하면 하위 항목이 자주 다시 시작될 수 있습니다.
PHP는 각 하위 항목에 대한 요청을 폴링합니다. 트래픽이 많은 시나리오에서는 설정이 너무 작으면 각 하위 항목이 거의 동시에 최대값에 도달합니다. , 여러 하위 항목이 동시에 있을 수 있습니다. 시간이 꺼져 있고 nginx가 요청을 php-fpm으로 전달할 수 없으며 CPU가 감소하고 로드가 높아집니다.致 너무 많이 설정하면 메모리 누수가 발생할 수 있습니다.

4) PHP 실행 시간이 Nginx 대기 시간을 초과합니다. `FastCGI_CONNECT_TIMEOUT`

FastCGI_TIMEOUT

Eout

5) fastcgi 실행 시간

nginx라면 어떻게 해야 하나요? 오류 502를 보고합니까? 솔루션 공유

7. http와 HTTPS의 차이점

1. 포트: http 80; https: 443

2. http는 stateless이며, https는 암호화된 전송이 가능한 http + SSL로 구축된 프로토콜입니다.

3. http 일반 텍스트 전송, https 암호화 전송

4. http는 3개의 패키지로 더 빠른 3방향 핸드셰이크, https에는 12개의 패키지가 필요합니다(3개의 tcp 패키지 + 9개의 SSL 핸드셰이크 패키지)

8. redis 분산 잠금 및 문제

1. 구현:
잠금: setnx
잠금 시간 초과: 만료
2 가능한 문제
1) nx 설정 및 만료는 비원자적입니다. 문제(잠금 후 설정을 사용할 수 있게 되면 중단됨)
Redis 2.6.12 이상에서는 SET 명령에 대한 선택적 매개 변수를 추가합니다. 이는 setnx 명령을 대체할 수 있습니다.
2) 다른 프로세스 잠금은 다음과 같습니다. 시간 초과 후 실수로 삭제되었습니다. (프로세스 A의 실행 시간이 초과되어 잠금이 해제됩니다. 이때 프로세스 B는 잠금을 획득하고 요청 처리를 시작합니다. 이때 프로세스 A는 처리를 완료하고 프로세스 B의 잠금은 삭제됩니다. 실수로)
해결 방법: 자신의 프로세스 잠금만 삭제할 수 있습니다(lua 스크립트 만료된 잠금을 획득한 후 프로세스 B가 실수로 프로세스 A의 잠금을 삭제하는 것을 방지)

3) 동시성 시나리오, 실행 시간 초과 프로세스 A는 잠금을 해제하고 프로세스 B는 이때 잠금을 획득합니다.

해결 방법: 데몬 프로세스를 시작하고 현재 프로세스가 만료되도록 잠금을 지연합니다.
4) 단일 지점 인스턴스 보안 문제
각 클라이언트를 잠그도록 알림
참고 :

Redis에서 분산 잠금을 구현할 때 주의해야 할 점은 무엇인가요? [노트 요약]

은 Redis

9의 분산 잠금에 대한 심층적인 이해를 제공합니다. 왜 빨리요?

추천 자료: //m.sbmmt.com/redis/475918.html

10 redis

🎜🎜1의 데이터 유형 및 적용 시나리오: 🎜🎜🎜 일반 키/값. 저장공간🎜🎜🎜2, 해시:🎜🎜

해시맵: 객체 정보를 저장하는 키-값 팀 모음

3. 목록:

이중 연결 목록: 메시지 대기열

4. 세트:

값이 항상 null인 해시맵: 순서가 지정되지 않음 집합 및 반복 없음: 교집합, 합집합, 차이 집합, 중복 제거 값 계산

5, zset:

중복 없이 정렬된 집합: hashMap(중복 제거) + Skiplist 점프 테이블(순서 보장): 순위 목록

참고 :
Redis의 5가지 데이터 유형 및 적용 시나리오

11. Persistence를 구현하기 위한 Redis의 방법, 원리 및 특징

1. RDB Persistence(스냅샷): 지정된 시간 간격 내에서 작성 디스크에 설정된 메모리 데이터의 스냅샷

1) 하위 프로세스를 포크하고 스냅샷 콘텐츠를 임시 RDB 파일(dump.rdb)에 씁니다. 하위 프로세스가 스냅샷 콘텐츠를 쓰면 새 파일이 이전 파일을 대체합니다. 파일

2 ) 전체 Redis 데이터베이스에는 하나의 백업 파일만 포함됩니다

3) 성능을 극대화하려면 지속성 작업을 완료하는 데 포크 하위 프로세스만 필요하므로 디스크 IO가 줄어듭니다

4) 지속성이 유지되기 전 가동 중지 시간으로 인해 데이터 손실이 발생할 수 있습니다.

2. AOF 지속성: 서버의 모든 쓰기 및 삭제 작업을 로그 형식으로 기록합니다

1) 쓰기 명령을 받을 때마다 쓰기 기능을 사용하여 파일에 추가합니다.appendonly.aof

2 ) 영구 파일은 점점 더 커지고 중복 로그가 많이 있습니다(0은 100으로 100배 증가, 100개의 로그 레코드가 생성됩니다)

3) 다양한 fsync 전략을 설정할 수 있습니다

appendfsync Everysec: 1초에 한 번 최대 1초의 데이터가 손실됩니다(기본값)
appendfsync Always : 변경 시마다 한 번 실행
appendfsync no : 처리되지 않음

4) AOF 파일이 다음과 같은 경우 다시 작성됩니다. 너무 큽니다: AOF 파일 크기를 압축합니다.

fork 프로세스, redis 로컬 데이터 개체의 최신 상태를 AOF 임시 파일에 씁니다(RDB 스냅샷과 유사).
기본 프로세스에서 받은 변경 사항이 먼저 (다시 쓰기가 실패한 후에도) 데이터 무결성을 보장할 수 있습니다.)
하위 프로세스가 다시 쓰기를 완료한 후 메모리의 새로운 변경 사항을 메모리에 동기적으로 추가합니다. 임시 AOF 파일
상위 프로세스는 임시 AOF 파일을 새 AOF 파일로 바꾸고 이름을 바꿉니다. 나중에 받은 새 명령은 새 파일에 기록됩니다

참조:
Redis 심층 학습의 지속성 원리에 대한 자세한 설명
RDB 및 AOF 지속성에 대한 간략한 분석, 장점과 단점? 선택하는 방법?

12. 플래시 판매 설계 과정 및 어려움

1. 정적 캐시

2. nginx 로드 밸런싱

세 가지 방법: DNS 폴링, IP 부채 밸런싱, CDN

3 , 현재 제한 메커니즘

방법: IP 전류 제한, 인터페이스 토큰 전류 제한, 사용자 현재 제한, 헤더 동적 토큰(프런트 엔드 암호화, 백엔드 암호 해독)

4. 분산 잠금

방법:

setnx + 만료(비원자성, set은 redis2.6 이후 원자성을 보장함)
릴리스 잠금 시간 초과(데몬 자동 갱신 활성화)
만료된 잠금으로 인해 실수로 다른 스레드가 삭제됨(requestId 확인 또는 lua 스크립트 보장 검색 원자성 + 삭제)

5. 캐시 데이터

방법:

캐시 분석: 캐시 데이터 워밍업 + 블룸 필터/캐시 비우기
캐시 눈사태: 캐시 설정 만료를 방지하기 위한 무작위 만료 시간 동시에

6. 재고 및 주문

재고 공제
- redis 자체 감소 재고로 인해 동시 시나리오에서 음수가 발생하고 재고 반환에 영향을 미칠 수 있습니다. 원자성을 보장하려면 lua 스크립트를 사용하세요.
- redis가 재고를 보류한 후 비동기 메시지를 사용하여 주문을 생성하고 재고 변경 사항을 업데이트합니다.
- 데이터베이스는 낙관적 잠금을 사용하여 재고를 업데이트합니다. 여기서 stock_num - Sell_num > 0
- 메시지 전송 기록 테이블을 추가하고 비동기 메시지 손실을 방지하기 위한 재시도 메커니즘
- 주문 생성
  - 프런트 엔드는 웹소켓 연결을 설정하거나 주문 상태를 폴링하고 모니터링합니다.
  - 반복 소비를 방지하기 위해 소비 확인 기록 상태
- 창고 반품
  - 주문 생성 후 지연 메시지를 보내 주문 결제 상태 및 재고 반품 여부를 확인합니다.