새로 출시된 PHP 고급 인터뷰 질문이 나왔습니다! [답변첨부]

사실 저는 최근에도 일을 하고 있는데 퇴사를 준비 중이라 이력서를 올렸는데 제출을 안했어요. 초대장을 보고 나와 잘 맞는 몇몇 분들과 인터뷰를 했고, 여러 제안이 잇달아 들어왔습니다. 수많은 면접 질문을 떠올려보세요. 어떤 인터뷰에 나왔는지 잊어버리시는 분들도 계셨고, 나열된 질문들은 모두 인상깊은 질문들이었고, 잊어버리시는 분들도 계셨기 때문에 카테고리별로 나누었습니다. 답변이 틀리면 정정해 주세요. (더 보기: PHP 면접 질문 요약)

<strong>mysql</strong><strong>mysql</strong>

1.谈谈你在写sql语句需要注意有哪些点？

答：

1、select * 问题，客户端需要什么，就给什么，不要给多余的字段，这种情况可能还会导致本来可以走覆盖索引的语句不能走覆盖索引。
2、不要在查询语句字段上做函数运算，这样会让索引失效。
3、一定要避免mysql自动类型转换，比如 where ‘9’ =9。
4、能不设置允许 null 的字段尽量不要设置，因为 null 会导致 mysql 多一层判断。
5、使用 like 的时候如果是通配符 %
1. SQL 문을 작성할 때 주의해야 할 점에 대해 이야기해 주세요.

1. 선택 * 질문: 클라이언트에게 필요한 것을 모두 제공하고 추가 필드를 제공하지 마세요. 이러한 상황으로 인해 포함 인덱스를 사용할 수 있는 문이 포함 인덱스를 사용하지 않을 수도 있습니다.

2. 쿼리 문 필드에 함수 작업을 수행하지 마십시오. 인덱스가 무효화됩니다.

3. '9' =9와 같은 MySQL 자동 유형 변환을 피하세요.
4. 가능하면 null을 허용하는 필드를 설정하지 마세요. null로 인해 MySQL이 추가 판단을 내리게 되기 때문입니다.
5.like를 사용할 때 와일드카드 문자 %가 앞에 있으면 전체 테이블 스캔도 수행됩니다.

답변:

2. 문자열 인덱스를 구성할 때 크기에 주의하세요. 인덱스 길이가 너무 길면 공간을 더 많이 차지하므로 적절하게 가로채서 인덱스를 사용할 수 없다는 단점이 있습니다. 업무에 따라 적절하게 처리합니다.

3. 인덱스의 기본 데이터 구조는 무엇인가요?

답: B+ 트리입니다.

4. 왜 레드-블랙 트리나 다른 트리가 아닌 B+ 트리를 사용하나요?

답: 레드-블랙 트리를 사용할 수 있습니다. 그러나 이로 인해 트리 높이가 너무 높아질 수 있으며, 이는 동일한 쿼리에 대해 더 많은 디스크 I/O가 수행되어 성능에 영향을 미친다는 것을 의미합니다. 그러나 B+ 트리는 트리 높이가 너무 높아지는 것을 방지할 수 있습니다. 높은. 이 질문에 대한 대답은 그리 좋지 않습니다. 그 이상입니다. 추가해 주시면 감사하겠습니다.

5. 인덱스 푸시다운을 아시나요?

본질적으로는 테이블로 반환해야 하는 일반 인덱스에 대한 최적화입니다. 즉, 엔진 레이어가 인덱스 포인터를 순회할 때 먼저 몇 가지 우선순위 판단을 하고 조건을 충족하지 않는 인덱스를 필터링합니다. 디스크 IO를 줄일 수 있습니다.

6. 누군가가 데이터베이스를 운영하다가 실수로 잘못된 문장을 실행하고 실수로 많은 데이터를 삭제했다고 가정해 보겠습니다. 회복하는 방법.

답변: 먼저 bin-log가 켜져 있어야 합니다. 켜져 있지 않으면 복구가 불가능할 수 있습니다. 특정 파일 시스템을 복원할 수 있는지 여부에 따라 다릅니다. bin-log가 활성화된 경우 유형 설정을 행 또는 혼합으로 설정해야 하며 문을 설정할 수 없습니다. 그러면 실수로 행이 삭제된 경우 해당 삭제 이벤트가 삽입 이벤트로 대체되어 대기 데이터베이스에서 실행될 수 있습니다. 실수로 테이블이 삭제된 경우 가장 최근의 전체 백업을 먼저 확보하여 대기 데이터베이스에 넣은 후, bin-log를 꺼내면 삭제되지 않은 이벤트를 제외하고 다른 이벤트가 순차적으로 재생됩니다. .

7. 왜 문으로 설정할 수 없나요?

대답: 실제 bin-log는 SQL 문을 저장합니다(특별히 삭제된 기본 키 ID는 아님). 이 경우 마스터-슬레이브 아키텍처인 경우 마스터와 슬레이브가 서로 다른 인덱스를 선택할 수 있습니다. 마스터-슬레이브 불일치.

답변: 이런 질문에 주의해 주세요. 핵심 포인트를 만드세요. 문제가 발생하여 해결책을 찾을 때 올바른 해결책을 처방해야 합니다. 즉, 어떤 상황에서 마스터-슬레이브 지연이 발생하는지 이런 식으로 생각해 볼 수 있습니다.
1. 메인 데이터베이스와 슬레이브 데이터베이스 서버 구성이 다르고 슬레이브 데이터베이스가 다른 경우 지연 시간이 길어질 수 있습니다. 이때는 동일한 서버 구성 서버로 변경하면 됩니다.
2. 노예 도서관에 대한 압박감이 너무 큽니다. 일반적으로 마스터-슬레이브 방식을 사용하며, 쿼리는 기본적으로 슬레이브 라이브러리를 사용한다. 예를 들어 운영자나 개발자는 슬레이브 라이브러리에 대해 일련의 SQL 연산을 수행할 수 있다. 그건 쉽습니다. 압력을 공유하기 위해 여러 개의 슬레이브 라이브러리(하나의 마스터와 여러 슬레이브)를 할당하십시오.
3. 큰 일. 예를 들어 삭제 문은 제한을 두어서는 안 됩니다. 데이터 양이 너무 많으면 메인 라이브러리를 실행한 후 슬레이브 라이브러리에 동기화하는 데 시간이 오래 걸립니다.

<strong>디자인 패턴</strong><strong>设计模式</strong>

你知道哪些设计模式，你平常有使用到吗？可以结合你的业务场景说下吗？

答 这里我先举例平常使用 Laravel，里面就用到大量设计模式，比如门面，组合，装饰，观察者…… 具体场景带入，然后根据之前业务上的场景说了下……., 最后也说了设计模式不是银弹，只有在合适的场景使用合适的模式才能体现它的价值。

<strong>手写算法</strong>

给定一个已排序的数组和一个指定值，返回指定值在数组中的下标位置，如果不存在，返回把给定值插入到数组之后的下标位置。注意时间复杂度。

比如给定有序数组 [1,3,5,6] 给定值5.那么返回下标2.
 给定有序数组[1,3,5,6] 给定值 7，返回下标4.

答:

    function searchInsert($nums, $target) {
        if (!count($nums))  return 0;
        $l=0;
        $r = count($nums)-1;
        while ($l <= $r){
            $middle = $l + (($r - $l) >> 1);
            if ($nums[$middle] == $target) return $middle;
            if ($nums[$middle] < $target){
                $l = $middle+1;
            }else{
                $r = $middle-1;
            }    
        }
        return $l;
    }

典型的可以使用二分，时间复杂度 O(log2n)。空间复杂度O(1)。

<strong>网络</strong>

1.传输层主要有哪些协议？

答：主要有 TCP 和 UDP 协议。他们的区别是 TCP 是需要连接的 会经过三次握手，而且可以保证消息的可靠性。UDP 是不需要连接的，不保证消息的可靠性。

2.你能大体说说 TCP 的三次握手吗？

答:首先服务器监听某个端口，客户端发起请求 携带syn数据包(第一次)，服务端接收到这个数据包，返回 syn/ack 的数据包给客户端(第二次)，最后客户端再次发送一个 ack 的数据包（第三次)。

4.为什么需要三次握手？

答:主要是为了确认双方接收是否正常。
第一次：客户端什么都不能确认。服务端能确认客户端的发送正常，自己的接收正常
第二次：客户端能确认自己的发送和接收正常，服务端的发送和接收正常。服务端能确认自己接收正常，客户端的发送正常。
第三次：全部都能确认了。

并发

假设现在有多个入口可以同时使用一个账户操作，这个账户只有十块钱，有哪些方法可以使得不超扣消费？开放性题目，只要能解决问题的就是好方案，没有唯一答案。

答：mysql：可以直接 where amount>=current_amount and amount>0 …… , 或者悲观锁 for update。redis:lua 脚本。php 层面可以利用文件锁，还可以使用队列的特性，只有一个消费的出口。

<strong>设计</strong>

如果我们公司有很多项目都有登录的功能，咋么设计？

答：需要把这个登录单独抽出来作为一个模块开发，类似于登录中心，所有的其他子系统登录都需要从这个系统中认证。

<strong>其他</strong>

답변: 먼저 파사드, 조합, 장식, 관찰자 ​​등 많은 디자인 패턴을 사용하는 일상 생활에서 Laravel을 사용하는 예를 들어 보겠습니다. 구체적인 장면을 소개한 다음 이야기하겠습니다. 이전 비즈니스 현장을 기반으로..., 마지막으로 디자인 패턴은 만병통치약이 아니라고도 말씀드렸습니다. 올바른 시나리오에서 올바른 패턴을 사용해야 그 가치가 반영될 수 있습니다.

🎜🎜🎜<strong>필기 알고리즘</strong>🎜🎜정렬된 배열과 지정된 값이 주어지면 배열에서 지정된 값의 아래 첨자 위치를 반환합니다(존재하지 않는 경우). 주어진 값을 배열에 삽입한 후의 인덱스 위치를 반환합니다. 시간 복잡도에 주의하세요. 🎜🎜🎜예를 들어, 순서 배열 [1,3,5,6]과 주어진 값 5가 주어지면 아래 첨자 2를 반환합니다.🎜 순서 배열 [1,3,5,6]과 값 7이 주어지면, return Subscript 4.🎜🎜🎜답변:🎜rrreee🎜일반적으로 이등분을 사용할 수 있으며 시간 복잡도는 O(log2n)입니다. 공간 복잡도 O(1). 🎜🎜🎜🎜<strong>네트워크</strong>🎜🎜1. 전송 계층의 주요 프로토콜은 무엇입니까? 🎜🎜🎜답변: 주로 TCP와 UDP 프로토콜이 있습니다. 차이점은 TCP가 연결하려면 3방향 핸드셰이크가 필요하고 메시지의 신뢰성을 보장할 수 있다는 것입니다. UDP는 연결이 필요하지 않으며 메시지 신뢰성을 보장하지 않습니다. 🎜🎜🎜2. TCP의 3방향 핸드셰이크에 대해 전반적으로 말씀해 주실 수 있나요? 🎜🎜🎜답변: 먼저 서버는 특정 포트를 수신하고 클라이언트는 처음으로 syn 데이터 패킷을 전달하라는 요청을 시작합니다. 서버는 이 데이터 패킷을 수신하고 클라이언트에 syn/ack 데이터 패킷을 반환합니다. (두 번째) 마지막으로 클라이언트는 ack 패킷을 다시 보냅니다(세 번째). 🎜🎜🎜4. 세 번의 악수가 필요한 이유는 무엇인가요? 🎜🎜🎜답변: 주로 양측이 정상적으로 수신하고 있는지 확인하기 위한 것입니다. 🎜처음: 클라이언트가 아무것도 확인할 수 없습니다. 🎜두 번째: 클라이언트는 자신의 송수신이 정상인지, 서버의 송수신이 정상인지 확인할 수 있습니다. 서버에서는 정상적으로 수신되고 있는지, 클라이언트에서는 정상적으로 송신되고 있는지 확인할 수 있습니다. 🎜세 번째: 모든 것이 확인되었습니다. 🎜🎜🎜🎜🎜동시성🎜🎜 하나의 계정으로 동시에 운영할 수 있는 여러 개의 입구가 있다고 가정합니다. 이 계정에는 어떤 방법이 있습니까? 초과 공제를 피하기 위해 사용됩니까? 개방형 질문의 경우 문제를 해결할 수 있는 한 좋은 해결책은 없습니다. 🎜🎜🎜답변: mysql: amount>=current_amount 및 amount>0... 또는 업데이트를 위한 비관적 잠금을 직접 사용할 수 있습니다. redis:lua 스크립트. PHP 수준에서는 파일 잠금 및 대기열 기능을 사용할 수 있습니다. 소비 콘센트는 하나만 있습니다. 🎜🎜🎜🎜🎜<strong>디자인</strong>🎜🎜우리 회사에 로그인 기능이 있는 프로젝트가 많다면, 어떻게 디자인해야 할까요? 🎜🎜🎜답변: 이 로그인은 로그인 센터와 유사하게 모듈로 별도로 개발되어야 합니다. 다른 모든 하위 시스템 로그인은 이 시스템에서 인증되어야 합니다. 🎜🎜🎜🎜🎜<strong>기타</strong>🎜🎜1. 프로젝트에서 swoole을 사용하고 일부 go도 작성한 것을 보면 코루틴의 차이점에 대해 말씀해 주실 수 있나요? ? 🎜🎜🎜답변: 디자인은 동일하며, 주요 차이점은 코루틴 스케줄러 모드입니다. Swoole의 코루틴 스케줄러는 단일 스레드이고 Go의 코루틴 스케줄러는 다중 스레드입니다. 이는 swoole에는 동시에 실행되는 코루틴이 하나만 있는 반면, go에는 동시에 여러 개의 코루틴이 실행될 수 있음을 의미합니다. 따라서 Swoole 코루틴에서 전역 변수를 잠글 필요가 없습니다. 더욱이 Swoole은 본질적으로 단일 스레드 및 다중 프로세스입니다. 즉, 슈퍼 전역 변수는 없고 프로세스 수준 변수만 있습니다. Go 멀티스레딩의 경우 멀티스레딩에서는 필연적으로 중요한 변수 잠금 문제가 발생합니다. 물론 Go는 기본적으로 동기화 읽기-쓰기 잠금을 제공하거나 대신 채널을 직접 사용할 수도 있습니다. 🎜

2. go의 gmp 스케줄링 모델에 대해 이야기해 주실 수 있나요?

답변: 오랫동안 명확하게 설명하지 못한 것 같은 느낌이 들었습니다. 글쎄요, 잘 이해가 안 되네요. 이때 면접관 입장에서는 그냥 모르겠다고만 하면 끝났을 것 같아요

3. 프로젝트에서 가장 어려웠던 부분과 이를 어떻게 해결했는지 알려주세요.

프로젝트에 대한 숙달도와 프로젝트의 골드 함량에 따라 다릅니다.

위 내용은 새로 출시된 PHP 고급 인터뷰 질문이 나왔습니다! [답변첨부]의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!