컴퓨터 지식 네트워크 - 컴퓨터 시스템 - 기술 면접에서 기술적인 질문을 많이 합니까?

기술 면접에서 기술적인 질문을 많이 합니까?

사실 저도 면접에 갈 줄은 몰랐어요. 나는 방금 지련에서 이력서를 갱신했고, 많은 헤드헌터의 이메일과 전화를 속속 받았다. 나는 정말 면접을 볼 준비가 되지 않아서 여러 회사의 면접을 거절했다. 오랫동안 면접을 보지 못했기 때문에 나도 면접에 가서 공부하고 싶다. 우리 잡담은 그만하자. 필자 10 월 4 일 오전 18, 10: 30 과의 인터뷰 경험을 공유해 드리겠습니다.

우선 헤드헌터나 회사의 인적자원은 회사의 소개와 업무 요구를 당신의 이메일 (또는 QQ, 위챗) 으로 보냅니다. 다음은 헤드헌터가 보내준 직위에 대한 설명입니다. 직업 윤리를 위해 회사 소개 및 면접 통지 정보는 붙이지 않지만, 나는 직위 요구 사항을 붙일 것이다.

작업 설명:

1, 어플리케이션 서버의 설치, 구성, 최적화 및 유지 관리를 담당합니다.

2. 시스템 로그 정보의 백업, 관리, 유지 관리 및 분석을 담당합니다.

3. 애플리케이션 시스템의 일상적인 모니터링, 유지 관리, 문제 해결, 성능 분석 및 최적화를 담당합니다.

4. 애플리케이션 배포 시스템, 환경 구성 시스템 및 모니터링 시스템의 개발, 배포, 업그레이드 및 유지 관리를 담당하고 고성능 운영 및 유지 관리 플랫폼을 구축합니다.

작업 요구 사항:

1, Linux 운영 체제의 기본 사항을 숙지하고 Linux 공통 운영 명령을 능숙하게 사용합니다.

2. Nginx, HAproxy 등의 어플리케이션 관련 소프트웨어의 배포, 구성 및 최적화 유지 관리에 능숙합니다.

3. 네트워크의 기본 사항을 숙지하고, TCP/IP 의 작동 원리를 숙지하며, 스위치나 라우터를 장착하고, 네트워크 상황을 능숙하게 분석할 수 있습니다.

4. 셸/perl/python 에서 하나 이상의 개발 운영 및 유지 보수 프로그램에 익숙합니다.

5, Nagios, Ganglia 및 기타 모니터링 소프트웨어에 익숙합니다.

위의 요구 사항을 보면 요구 사항이 높지 않다고 생각하십니까? 자세히 살펴보면 이 회사는 인터넷 지식 (TCP/IP 에 익숙한 모든 회사가 이런 요구 사항을 쓸 수 있는 것처럼) 뿐만 아니라 기술 개발도 많이 요구한다는 것을 알 수 있다. 저는 많은 운영 및 유지 보수 형제들이 네트워크에서 골치 아픈 일이라고 믿습니다. 스위치와 라우터를 구성하고 관리하기가 쉽지 않습니다.

그런 다음 저자는 그들의 회사를 자세히 이해하고, 직무 요구 사항을 이해하며, 갑자기 질문할 수 있는 지식 포인트와 기술 포인트를 복습한다. 면접 당일 일찍 일어나 양치질을 하고, 특히 입냄새가 나는 형제. 면접 회사에 도착하기 전에 껌을 준비하고 껌 한 조각을 씹는 것이 좋다. 말투로 면접관에게 훈제되지 않도록 면접관의 마음에 실점을 주는 것이 좋다. 일찍 먹는 것을 기억하고 오후 면접이라면 점심도 먹어야 한다. 만약 네가 일찍 먹는다면, 너는 정력이 있을 것이다. 이력서와 펜을 챙겨야 하는데 이력서가 있을 수 있으니 만일을 대비해서 이력서를 준비해 주세요.

마지막으로, 요점은 면접관과 소통하는 것이다. 필기시험이 있는 회사는 너에게 몇 가지 면문제를 하게 할 것이다. 필기시험이 없다면 면접관을 직접 찾아가서 이야기할 수 있다. 다음은 면접관과 교류한 후 떠올린 몇 가지 질문입니다. 나는 너와 그것들을 공유할 것이다. 작가는 이미 7 개의 문제를 외웠지만, 아직 두 개의 문제를 기억할 수 없는 것 같다. 만약 당신이 더 적합한 답을 가지고 있다면, 반드시 토론을 게시하고 함께 발전해야 합니다.

1, 자기 소개? 거의 모든 회사에서 먼저 자신을 소개하라고 합니다. 마치 필수 과목인 것 같습니다.

작성자 응답: 여기서는 작성자 자기 소개를 생략합니다. 나 자신을 소개하는 시간이 너무 길지 말고 3-4 분이 적당하다고 제안한다. 많이 말하면 면접관은 네가 너무 수다스럽다고 생각할 것이다. 너무 적게 말하는 것은 아무런 이득이 없다. 왜냐하면 사람들이 너의 체험이 너무 간단하고 공간이 없다고 생각하게 하기 때문이다. (존 F. 케네디, 경험명언) 일반적으로 네가 자신을 소개할 때 면접관은 이때 너의 이력서를 보고 있다. 그는 네가 자신을 소개하는 것을 들으면서 너의 이력서를 볼 필요가 있다. 세 마디로 자신을 소개하면, 그는 분명히 회복할 수 없을 것이고, 이미지는 떨어질 것이다. 동시에, 너는 사유와 논리적으로 명확해야 한다. 이력서에 적힌 경험에 따라 소개하는 것이 좋다. 이렇게 하면 면접관의 생각을 너에게 전해 주고, 그가 너를 따라가게 할 수 있다. 한 글자도 잡아당기지 말고 한 글자도 잡아당겨라. 나에게 너의 성격과 취미를 적게 말해라. 당신이 일했던 몇 개의 회사 (최대 3 개/현재 회사, 주의 순서 포함), 당신이 그 회사에서 어떤 일을 맡고 있는지, 어떤 기술을 사용했는지 간단히 나열할 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 일명언) 당신의 현재 회사가 어떤 일을 담당하고 있는지 중점적으로 소개하면 면접관을 곤혹스럽게 하지 않고 조금 자세히 소개할 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언)

그레이 스케일 게시를 달성하는 방법?

저자는 대답했다: 사실, 나는 이 질문에 잘 대답하지 않았고, 모두를 오도하기 위해 쓰지 않았다. 누구나 즐길 수 있는 좋은 방법이 있다. 그러나 사후에 한 네티즌의 건의를 보는 것이 좋다. 참고할 수 있습니다: /question/20584476

3.Mongodb 잘 아세요? 일반적으로 배포되는 단위는 몇 개입니까?

저자는 대답했다: 네, 이미 배치되었지만 심도 있는 연구는 하지 않았다. 일반 MongoDB 배포 마스터-슬레이브 또는 MongoDB 세그먼트 클러스터 3 ~ 5 대의 서버를 배치하는 것이 좋습니다. MongoDB 슬라이스의 기본 아이디어는 컬렉션을 작은 조각으로 자르는 것입니다. 이러한 블록은 여러 슬라이스로 분산되며 각 슬라이스는 총 데이터의 일부만 담당합니다. 클라이언트의 경우 데이터가 분할되었는지 또는 서버의 어떤 세그먼트가 어떤 데이터에 해당하는지 알 필요가 없습니다. 데이터를 분할하기 전에 mongos 라는 라우팅 프로세스를 실행해야 합니다. 이 라우터는 모든 데이터의 저장 위치와 데이터와 칩의 대응 관계를 알고 있다. 클라이언트의 경우 일반 mongod 가 연결되어 있다는 것만 알고 있습니다. 데이터를 요청하는 동안 라우터의 데이터와 칩의 대응을 통해 대상 데이터가 있는 칩으로 라우팅됩니다. 요청에 응답이 있는 경우 라우터는 응답을 수집하여 클라이언트로 다시 보냅니다.

4. 출시 및 롤백 방법, 젠킨스로 구현하는 방법?

저자는 Release: Jenkins 구성 코드 경로 (SVN 또는 GIT) 라고 대답한 다음 코드를 당겨 태그를 지정합니다. 필요에 따라 컴파일하고, 컴파일하고, 게시 서버로 푸시하고 (Jenkins 에서 스크립트를 조정할 수 있음), 배포 서버에서 비즈니스 서버로 아래로 배포합니다.

롤백: 버전 번호를 기준으로 해당 버전을 찾아 게시 서버에 푸시합니다.

5.Tomcat 작업 모드?

저자는 Tomcat 은 JSP/서블릿 컨테이너라고 대답했다. 서브렛 컨테이너로서 독립형 서브렛 컨테이너, 프로세스 내 서브렛 컨테이너 및 프로세스 외 서브렛 컨테이너의 세 가지 작동 모드가 있습니다.

Tomcat 의 작업 방식에 따라 Tomcat 에 대한 요청은 다음 두 가지 범주로 나눌 수 있습니다.

Tomcat 을 응용 프로그램 서버로 사용: 요청은 프런트 엔드 웹 서버 (Apache, IIS, Nginx 등) 에서 제공됩니다.

Tomcat 은 웹 브라우저에서 요청을 하는 독립형 서버입니다.

모니터링은 무엇을 달성 했습니까?

저자는 현재 회사의 업무가 모두 아리운에서 운영되고 있으며, 우리가 가장 선호하는 감시는 아리운 감시이다. 아리운 모니터링은 자체 ECS, RDS 등의 서비스를 제공하는 모니터링 템플릿으로, 맞춤형 경고 규칙과 함께 모니터링 프로젝트를 트리거할 수 있습니다. 마지막 회사의 사업은 zabbix 모니터링 프로그램을 사용하는 IDC 에 호스팅되어 있습니다. Zabbix 는 풍부한 그래픽 인터페이스와 많은 모니터링 템플릿, 특히 여러 파티션과 네트워크 카드를 자동으로 검색하고 모니터링합니다. 그러나 모니터링되는 각 클라이언트에 zabbix 에이전트를 설치해야 합니다.

7. 데이터베이스 백업을 포함한 데이터를 어떻게 백업합니까?

저자는 프로덕션 환경에서 어플리케이션 데이터든 데이터베이스 데이터든 배포 시 마스터-슬레이브 아키텍처 또는 클러스터가 있습니다. 이것이 바로 데이터의 핫 백업입니다. 실제로 콜드 백업을 고려하고 전용 서버를 백업 서버로 사용할 수 있습니다. 예를 들어 rsync+inotify 를 사용하여 데이터의 콜드 백업을 수행할 수 있습니다. 분산 패키지 백업의 경우 일반적으로 게시 서버가 있으며 분산 패키지는 배포될 때마다 저장됩니다.

요약

면접에서 몇 가지 주의사항을 요약하면 저자도 틀릴 수 있다. 운비에서 일하는 형제들이 고임금을 받을 수 있도록, 우리는 함께 증언하고, 함께 진보하고, 함께 토론해야 한다.

먼저 이력서에 익숙해져야 한다. 이력서에 쓰는 기교에 대해 한두 가지 말을 할 수 있어야 한다. 면접관이 이력서에 적힌 문제를 고르기 때문이다. 예를 들어 이력서에 따르면 MySQL 데이터베이스의 배포, 설치 및 원리에 대해 잘 알고 있다고 합니다. 너는 바로 이런 기술을 썼다. 익숙하지 않다면 MySQL 의 원리를 이해하고 대략적인 아이디어를 제시해야 한다. 만약 면접관이 너에게 이 문장, 네가 대답할 수 없다면, 너는 그의 마음속에서 점수를 잃게 될 것이다. 기본적으로 이번 면접은 희망이 크지 않다.

둘째, 면접관이 당신이 이해하지 못하는 질문을 하면 익숙하지 않다고 말하고 자세히 연구한 적이 없다. 아는 척하지 말고 쓸데없는 화제를 한 무더기 잡아당겨 감추지 마라, 면접관에게 반감을 줄 뿐이다. (조지 버나드 쇼, 자기관리명언)

셋째, 충분히 준비하고, 가능한 한 원리 지식을 많이 기억해라. 일반 면접에서 묻는 비교 원칙. 특정 프로필이 어떻게 구성되어 있는지 묻는 사람은 거의 없습니다. 면접을 보기 전에' 직책 설명' 과' 직책 요구 사항' 도 알아야 한다. 때때로 대부분의 사람들은 업무 요구 사항에 대해 묻지 않지만, 잘 알고 있어야 한다. (존 F. 케네디, 일명언) (알버트 아인슈타인, 일명언)

넷째, 면접이 끝난 후 반드시 총결하고, 면접관이 묻는 모든 질문을 기억하고, 돌아가서 기록해야 한다. 만약 당신이 할 수 없는 질문을 한다면, 당신은 사후에 바로 바이두에 가거나 친구를 찾아 알아봐야 합니다. 그러면 당신은 이 일을 기억할 수 있고, 다음 면접에서 같은 질문을 다시 할 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 남녀명언)

면접이 끝난 후 면접관은 나에게 월급에 대해 이야기하면서 얼마나 많은 돈이 나의 요구를 충족시킬 수 있는지 물었고, 나는 공개할 수 없었다. 사적인 대화를 할 수 있어요. 하하. 이후 작가는 이전 면접 경력과 문제를 속속 갱신하며, 필요한 친구는 전재하거나 소장하여 함께 토론할 수 있다.

모두의 열렬한 분위기에 따라 필자는 또 한 오후 시간을 들여 2065438+2007 년 2 월 24 일 한 미디어회사와의 취재 경험을 정리했다. 장소는 동삼환 부근에 있었다. 다행히 저자는 필기하는 습관이 있어 이전 면접의 모든 문제를 기록했다. 이 인터뷰는 기억이 생생하다. 왜냐하면 이 회사는 이미 필자에게 보냈기 때문이다. 다음은 회사의 직무 요구 사항에 대한 설명입니다.

직무 역할:

1, 회사 제품의 버전 관리, 건설 및 릴리스 관리를 담당합니다.

2. 회사의 통합 구성 라이브러리 관리를 담당하고, 정확하고 적시에 권한을 관리 및 분배하며, 정기적으로 구성 백업을 완료합니다.

3. 회사 내 개발/테스트 서버의 운영 및 관리를 담당합니다.

4. 리눅스 운영 체제의 설치, 구성, 모니터링 및 유지 보수, 문제 처리, 소프트웨어 업그레이드, 데이터 백업, 비상 대응, 문제 해결 등을 담당합니다. , 온라인 환경의 안정적인 운영을 보장합니다.

5. 플랫폼 24×7 의 안정적인 운영을 지원하고 사전 예방 용량 계획을 수행합니다.

6. 회사실 서버의 일상적인 유지 관리와 네트워크 시스템의 설치, 배포 및 유지 관리를 담당합니다.

작업 요구 사항:

1, 컴퓨터 관련 학과 이상 학력, 2 년 이상 운영 유지 관리 또는 구성 관리 업무 경험

2. Nagios/zabbix/와 같은 하나 이상의 모니터링 시스템에 익숙합니다.

Ansi ble/salt stack; 과 같은 하나 이상의 클러스터 관리 도구에 익숙합니다.

4. 통합 게시 도구를 사용하여 게시 및 빌드한 경험이 있는 사람이 선호됩니다. 예: 대나무 또는 젠킨스; 을 눌러 섹션을 인쇄할 수도 있습니다

5, 유닉스/리눅스 운영 체제, Weblogic/tomcat 과 같은 미들웨어에 익숙하고, 쉘 스크립트를 작성할 수 있으며, 소프트웨어 개발 프로세스 및 프로세스 제품에 익숙하며, 네트워크 기반이 있습니다.

6. 로그 수집 및 처리 시스템 (예: rsyslog, flume) 에 익숙합니다

7. 비교적 강한 안전의식, 비교적 강한 소통, 조정, 학습능력, 양호한 팀워크 정신, 적극적인 업무 활동을 가지고 있습니다.

지난 후, 프론트 데스크에 있던 아가씨가 나를 그들 회사의 지하실로 데려갔다. 나는 주위를 힐끗 보았는데, 옆에 기계실이 있는 것 같았다. 왜냐하면 나는 서버의 소리를 들었기 때문이다. 몇 분을 기다리다가 면접관이 내려왔다. 시각적 면접관은 비교적 날씬해서 나와 비슷해 보인다 (120 미만). 그는 그가 운영 및 유지 보수 부서를 책임지고 있다고 말했고, 먼저 자신을 소개하겠습니다. 이것은 관례적인 공무이므로 불가피하게 자기소개를 해야 하기 때문에 형제들은 반드시 자기소개를 연습해야 한다. 그런 다음 나에게 질문하기 시작하고 면접관과 이야기를 나누며 10 개 이상의 질문을 할 수 있습니다. 다음과 같은 10 개의 질문을 기억합니다.

1 의 원리는 LVS 및 Nginx 부하와 어떻게 다릅니까?

작가는 인터뷰 소송이 이 문제에 대해 인사하지 않았다고 생각한다. 일반적으로 "LVS 로드 밸런싱 기술 및 스케줄링 알고리즘은 무엇입니까?" 라고 묻습니다. 。 나의 대답은 내가 말한 질문에 근거한 것이다. 어차피 그는 자주 고개를 끄덕였다. 물론, 저자의 대답은 내가 아래에 정리한 것만큼 상세하지 않을 수도 있다. 나는 이미 분명히 말했다.

LVS 는 Liunx 가상 서버의 약어입니다. LVS 및 Linux 운영 체제에서 제공하는 로드 밸런싱 기술을 활용하여 고성능, 고가용성 서버 클러스터를 구현할 수 있습니다. 일반적으로 LVS 는 전체 클러스터 시스템의 전면에 위치하며 응용 프로그램 서버에 분산되는 하나 이상의 로드 스케줄러로 구성됩니다. 레이어 4 (TCP/IP 의 전송 계층) 에서 작동하며, LVS 는 다음과 같이 IP 로드 밸런싱 기술을 기반으로 하는 IPVS 모듈에 의해 구현되며 IPVS 에는 NAT, TUN, DR 이라는 세 가지 로드 밸런싱 메커니즘이 있습니다.

VS/NAT: 예 (네트워크 주소로 변환된 가상 서버)

즉, 네트워크 주소 변환 기술은 가상 서버를 구현합니다. 사용자가 스케줄러에 도착하도록 요청하면 스케줄러는 요청 메시지의 대상 주소 (즉, 가상 IP 주소) 를 선택한 실제 서버 주소로 다시 작성하며, 메시지의 대상 포트도 선택한 실제 서버의 해당 포트로 변경됩니다. 결국 메시지 요청을 선택한 실제 서버로 보냅니다. 서버에서 데이터를 가져온 후 실제 서버는 사용자에게 데이터를 반환할 때 로드 스케줄러를 통해 메시지의 소스 주소와 포트를 가상 IP 주소와 해당 포트로 다시 변경한 다음 사용자에게 데이터를 전송하여 전체 로드 스케줄링 프로세스를 완료해야 합니다.

NAT 모드에서는 사용자 요청과 응답 메시지를 모두 Director 서버 주소로 다시 작성해야 합니다. 사용자가 점점 더 많이 요청하면 스케줄러의 처리 능력을 병목 현상이라고 합니다.

VS/TUN: 예 (IP 터널을 통한 가상 서버)

즉, 가상 서버를 구현하는 IP 터널 기술입니다. 접속 일정 및 관리는 VS/NAT 와 동일하지만 메시지 전달 방법이 다릅니다. VS/TUN 에서 스케줄러는 IP 터널링 기술을 사용하여 사용자의 요청을 실제 서버로 전달합니다. 이 서버는 프런트 엔드 스케줄러를 거치지 않고 사용자의 요청에 직접 응답합니다. 또한 실제 서버의 지리적 위치에 대한 요구 사항은 없으며 Director 서버와 동일한 네트워크 세그먼트 또는 독립 실행형 네트워크에 있을 수 있습니다. 따라서 TUN 모드에서 스케줄러는 사용자의 메시지 요청만 처리하고 클러스터 시스템의 처리량이 크게 증가합니다.

VS/DR: 예 (직접 라우팅을 통한 가상 서버)

즉, 가상 서버는 직접 라우팅 기술을 통해 구현됩니다. 접속 스케줄링 및 관리는 VS/NAT 및 VS/TUN 과 동일하지만 메시지 전달 방법이 다릅니다. VS/DR 은 요청 메시지의 MAC 주소를 다시 작성하여 Real Server 에 요청을 보내고, Real Server 는 고객에게 직접 응답을 반환하므로 VS/TUN 의 IP 터널 오버헤드를 방지합니다. 이 방법은 세 가지 로드 스케줄링 메커니즘 중 성능이 가장 높지만 Director Server 와 Real Server 모두에 동일한 물리적 네트워크 세그먼트에 연결된 네트워크 카드가 있어야 합니다.

응답 로드 스케줄링 알고리즘, IPVS 는 8 가지 로드 스케줄링 알고리즘에서 구현되며, 일반적으로 사용되는 스케줄링 알고리즘에는 네 가지 (루프 스케줄링, 가중 루프 스케줄링, 최소 링크 스케줄링, 가중 최소 링크 스케줄링) 가 있습니다. 일반적으로 이 네 가지 알고리즘으로 충분하므로 이 네 가지 알고리즘을 자세히 설명할 필요가 없다. 위의 세 가지 로드 균형 조정 기술을 명확하게 설명하기만 하면 면접관은 이 문제에 만족한다. 다음으로 nginx 와의 차이점에 대해 간단히 이야기하겠습니다.

LVS 의 이점:

내부하 능력이 강하고, 작업이 레이어 4 에서만 배포되며, 트래픽이 발생하지 않으며, 이는 로드 밸런싱 소프트웨어에서 가장 성능이 뛰어나다는 것을 결정합니다. 트래픽이 없고 이퀄라이저 IO 의 성능이 큰 트래픽의 영향을 받지 않도록 합니다.

LVS+Keepalived, LVS+heartbeat 와 같은 완벽한 핫 스페어 체계를 갖춘 안정적인 작업 을 눌러 섹션을 인쇄할 수도 있습니다

응용 프로그램 범위가 비교적 넓어서 모든 응용 프로그램이 로드 밸런싱을 할 수 있습니다.

구성이 비교적 낮은 것이 단점이자 장점이다. 구성할 것이 많지 않기 때문에 너무 많은 접촉이 필요하지 않아 인위적인 실수의 확률을 크게 낮췄다.

LVS 의 단점:

소프트웨어 자체는 일상적인 처리를 지원하지 않으며 정적 분리를 할 수 없으므로 Nginx/HAProxy+Keepalived 의 장점을 강조합니다.

LVS/DR+Keepalived 는 웹 사이트 응용 프로그램이 큰 경우 더욱 복잡해질 수 있습니다. 특히 Windows Server 응용 프로그램이 뒤에 있는 시스템에서는 구현, 구성 및 유지 관리 프로세스가 더욱 까다로울 수 있습니다. 상대적으로 Nginx/HAProxy+Keepalived 는 좀 더 간단합니다.

Nginx 의 장점:

OSI 계층 7 에서 작업하면서 http 어플리케이션을 위한 전환 전략을 개발할 수 있습니다. 예를 들어 도메인 이름과 디렉토리 구조의 경우 그 정규화는 HAProxy 보다 더 강력하고 유연합니다.

Nginx 는 네트워크에 대한 의존도가 매우 적다. 이론적으로 ping 을 통해 로드 기능을 수행할 수 있다는 점도 장점이다.

Nginx 설치 구성이 간단하고 테스트가 용이합니다.

고부하 압력과 안정성을 견딜 수 있으며 일반적으로 수만 개 이상의 동시성을 지원할 수 있습니다.

Nginx 는 서버를 기준으로 웹 페이지에서 반환된 상태 코드 처리, 시간 초과 등 포트를 통해 서버의 내부 장애를 감지할 수 있습니다. 를 클릭하고 오류를 다른 노드로 반환하는 요청을 다시 제출합니다.

Nginx 는 우수한 로드 밸런서/리버스 에이전트 소프트웨어일 뿐만 아니라 강력한 웹 어플리케이션 서버이기도 합니다. LNMP 도 현재 유행하는 웹 환경이며 LAMP 환경과 경쟁력이 있습니다. Nginx 는 특히 높은 동시성에 저항하는 정적 페이지 처리에 있어서 Apache 보다 우세하다.

Nginx 는 웹 역방향 가속 캐시로서 기존 Squid 서버보다 빠르게 성숙해지고 있습니다. 필요한 친구는 그것을 리버스 프록시 가속기로 사용하는 것을 고려해 볼 수 있다.

Nginx 의 단점:

Nginx 는 URL 감지를 지원하지 않습니다.

Nginx 는 http 와 이메일만 지원할 수 있습니다. 이것이 약점입니다.

Nginx 의 세션 유지 관리, 쿠키의 부팅 능력은 상대적으로 부족합니다.

2.redis 클러스터의 원리, redis 조각화를 실현하는 방법, 귀사의 redis 는 어떤 환경에서 사용됩니까?

저자는 다음과 같이 대답했다: reids 클러스터 원리:

사실, 그 원리는 세 마디로 명확하게 설명할 수 있는 것이 아니다. Redis 버전 3.0 이전에는 클러스터가 지원되지 않았습니다. 공식적으로 권장하는 최대 노드 수는 1000 이며 클러스터를 구축하려면 최소 3 (마스터) +3 (슬레이브) 이 필요합니다. 여러 노드 간에 데이터를 공유할 수 있는 중앙 집중식 분산 스토리지 아키텍처로 redis 3.0 의 고가용성 및 확장성 문제를 해결합니다. 클러스터는 데이터를 여러 노드로 자동 분할할 수 있으며 redis 는 클러스터의 한 노드가 실패할 경우 클라이언트 요청을 계속 처리할 수 있습니다.

Redis 조각:

파티션은 데이터를 Redis 인스턴스로 나누는 프로세스이므로 각 인스턴스에는 모든 키의 하위 세트만 포함됩니다. 데이터 양이 많으면 데이터가 여러 데이터베이스에 저장되어 단일 노드의 연결 압력을 줄여 대용량 데이터 저장소를 구현합니다. 분할 배포 방법은 일반적으로 다음 세 가지 유형으로 나뉩니다.

(1) 클라이언트 슬라이스에서 이 메서드는 클라이언트에서 연결할 redis 인스턴스를 식별하고 해당 redis 인스턴스에 직접 액세스합니다.

(2) 슬라이스 시약; 이렇게 하면 클라이언트는 redis 인스턴스에 직접 액세스하거나 액세스할 redis 인스턴스를 알지 않고 에이전트가 요청 및 결과를 전달합니다. 작업 프로세스는 다음과 같습니다. 클라이언트가 먼저 에이전트로 요청을 보내고, 에이전트는 슬라이스 알고리즘을 통해 액세스할 redis 인스턴스를 결정한 다음 해당 redis 인스턴스로 요청을 보내고, redis 인스턴스는 결과를 에이전트로 반환하고, 에이전트는 결국 결과를 클라이언트로 반환합니다.

(3) redis 서버에서 슬라이스; 이 방법을 질의 라우팅이라고 합니다. 이렇게 하면 클라이언트는 임의로 redis 인스턴스를 선택하여 요청을 보냅니다. 요청된 내용이 현재 redis 인스턴스에 없는 경우 요청을 올바른 redis 인스턴스로 전달할 책임이 있습니다. 일부 구현에서는 redis 인스턴스가 요청을 전달하지 않고 올바른 redis 에 대한 정보를 클라이언트로 보내고 클라이언트는 요청을 올바른 redis 인스턴스로 보냅니다.

Redis 는 어떤 환경에서 사용됩니까?

Redis 는 Java 및 PHP 환경에서 사용되며 주로 로그인 사용자 정보 데이터, 장치 상세 정보 데이터, 회원 로그인 데이터 등을 캐시합니다.

현재 방문 중인 IP 를 어떻게 통계하고 분류합니까?

작성자 응답: awk 를 사용하여 uniq 와 sort 를 결합하여 액세스. log 로그를 필터링하면 사용자의 액세스 IP 를 집계하고 정렬할 수 있습니다. 보통 이렇게 대답하면 충분하다. 물론, 당신은 다른 통계 방식도 말할 수 있습니다. 이것들은 모두 당신의 가산점입니다.

4. 어떤 가상화 기술을 사용하시겠습니까?

저자는 VMware vsphere 와 KVM, VMware vsphere 가상화를 많이 사용하고, 프로덕션 환경에서 VMware vsphere 와 KVM 을 사용하는 책이 몇 권 있는데, 테스트 환경에서 사용하고 있습니다. Vmware 는 하드웨어에서 직접 실행할 수 있는 기본 아키텍처 가상화 기술입니다. Kvm 은 상주 아키텍처의 가상화 기술로, 시스템에서 실행됩니다. Vmware vcenter

관리가 편리하고 그래픽 관리 인터페이스가 강력하고 안정적이며 일반적으로 기업에 적합합니다. KVM 의 관리 인터페이스는 약간 나쁘기 때문에 관리 담당자는 유지 관리 및 관리 기술을 익히는 데 약간의 시간을 할애해야 합니다.

5. 만약 누군가가 반응하여 백엔드 인터페이스 검색이 특히 느리다면, 당신은 어떻게 검사할 것입니까?

저자는 대답했다: 사실 이 질문에는 구체적인 답이 없다. 다만 너의 대답과 면접관의 적합성을 보고 있을 뿐이다. 네가 그가 원하는 점을 말할 수 있는지 없는지, 주로 네가 근심을 풀고 어려움을 푸는 사고방식에 달려 있다. 나는 이렇게 말했다: 응답한 사람에게 어떤 서비스 앱이나 인터페이스 액세스 페이지가 느렸는지 물어보면, 그가 페이지 또는 관련 홈페이지를 너에게 보내게 할 것이다. (존 F. 케네디, 공부명언) 첫째, 가장 직관적인 분석은 브라우저를 사용하여 F 12 를 누르고 어떤 내용이 너무 느리는지 확인하는 것입니다 (DNS 분석, 네트워크 로드, 큰 그림, 파일 내용 등). ), 그리고 만약 있다면, 증상에 대한 치료 (사진이 느리면, 그림을 최적화하고, 네트워크가 느리면) 둘째, 백엔드 서비스 로그를 본다. 실제로 대부분의 문제에 대한 로그를 보는 것이 가장 효과적인 분석입니다. Tail -f F 추적 로그를 사용하는 것이 가장 좋습니다. 물론 Test 를 클릭하여 인터페이스 로그를 액세스해야 출력할 수 있습니다. 마지막으로 SQL 을 제외하고 SQL 을 찾아 MySQL 에서 실행하여 시간이 오래 걸리는지 확인합니다. 시간이 오래 걸리면 SQL 문제를 튜닝해야 합니다. Expain SQL 을 보고 인덱스를 본 다음 그에 따라 최적화합니다. 데이터 양이 너무 많으면 테이블을 분할하거나 데이터베이스를 분할할 수 있습니다. SQL 에 문제가 없는 경우 작성한 논리 코드에 문제가 있을 수 있습니다. 코드를 한 줄씩 검사하여 시간이 많이 걸리는 부분을 찾아 논리를 변환하고 최적화합니다.

6.mysql 데이터베이스는 마스터-슬레이브 읽기-쓰기 분리를 사용하고 마스터 라이브러리는 라이브러리에서 읽고 씁니다. 도서관에서 읽을 수 없거나 도서관에서 읽는 것이 특히 느리다면 어떻게 해결할 수 있습니까?

저자는 대답했다: 나는 이 질문에 대한 답이 그다지 좋지 않다고 생각한다. Mysql 을 잘하는 친구는 조언을 해주고 싶어한다. 문제 해결을 전제로, 먼저 라이브러리 수를 늘리고, 일시적으로 문제를 해결한 다음 느린 로그를 잡고, SQL 문을 분석하고, 튜닝하면 최적화됩니다. 속도가 느리거나 하드웨어가 따라갈 수 없으므로 업그레이드가 필요합니다. 소프트웨어가 디버깅 최적화를 필요로 하거나 문제를 상세히 해결하고 있다.

싱글 코어와 멀티 코어 CPU 의 차이점은 무엇입니까?

작가는 면접관이 이런 질문을 하는 경우는 거의 없고, 있어도 솔직하게 대답해야 한다고 대답했다. 다행히도, 전에 CPU 를 배웠습니다. 나는 이렇게 말한다: 듀얼 코어 CPU 는 여러 작업을 처리할 수 있고, 그것들을 잘 처리하기 위해 줄을 서 있다. 싱글 코어 CPU 는 한 번에 하나의 작업을 처리하고 각 프로그램 작업을 차례로 처리합니다. 듀얼 코어의 장점은 주파수가 아니라 여러 가지 일을 동시에 처리하는 것이다. 단핵구는 한 가지 일만 할 수 있습니다. 예를 들어, 백그라운드에서 BT 를 동시에 다운로드할 수 있습니다. 프런트에서는 영화를 보면서 파일, QQ 를 복사할 수 있습니다.

8. 기계식 디스크와 솔리드 스테이트 드라이브의 차이점은 무엇입니까?

저자는 대답했다: 젠장, 몇 살이야, 접시 질문도 했어. 이 면접관은 좀 웃긴다. 그것도 대답해야 한다.

HDD 는 기계식 하드 드라이브를 나타내고 SSD 는 솔리드 스테이트 드라이브를 나타냅니다. 우선, 성능면에서 SSD 는 기계 하드 드라이브보다 거의 낫습니다. SSD 는 기계 하드 드라이브보다 읽기 및 쓰기 속도가 빠릅니다. SSD 와 기계 하드 드라이브의 구조가 완전히 다르기 때문입니다 (구체적인 구조는 설명 할 필요가 없습니다). 둘째, 솔리드 스테이트 디스크는 소음이 거의 없고 기계식 디스크는 소음이 있습니다. 또한, 현재의 시장 상황에 따르면, 일반적인 기계 디스크 용량은 크고 가격은 낮습니다. 솔리드 스테이트 디스크는 용량이 작고 가격이 높다. 그러나 기업들은 여전히 솔리드 스테이트 디스크를 선호한다.

9. 어떤 모니터링 시스템을 사용하셨습니까?

저자는 이 감시 문제가 또 물었다. 2065 438+08 10 월 4 일에도 비슷한 질문을 했습니다. 나는 zabbix, Nagios, cacit 등을 사용했다. 하지만 이번 인터뷰에서는 자비X 와 나지오스만 사용했다고 말했다. (윌리엄 셰익스피어, 자비엑스, Northern Exposure (미국 TV 드라마), 남녀명언) 그 후 면접관은 두 가지 모니터링의 차이점에 대해 이야기하라고 했습니다.

웹 기능 및 그리기:

Nagios 는 간단하고 직관적이며, 경고와 데이터는 같은 페이지에 있으며, 빨간색은 문제 항목입니다. Nagios 웹에서 어떠한 구성도 하지 마십시오. Nagios 에는 추가 플러그인이 필요합니다. 플러그인이 제대로 그려지지 않았습니다.

Zabbix 모니터링 데이터와 경보는 분리되어 있습니다. 문제 항목을 보려면 트리거가 필요하고, 데이터는 최신 데이터에서 확인해야 합니다. 또한 zabbix 에는 다른 많은 구성 항목이 있습니다. Zabbix 에는 한 그림에 여러 모니터링 항목을 수동으로 표시할 수 있는 그리기 기능이 있습니다.

모니터링 서비스의 경우:

Nagios 와 함께 제공되는 모니터링 프로젝트는 거의 없습니다. 여러 파티션 및 여러 네트워크 카드와 같은 일부 변경 사항을 모니터링하려면 수동 구성이 필요합니다.

Zabbix 에는 많은 모니터링 콘텐츠가 포함되어 있습니다. Zabbix 는 처음부터 많은 일을 해 온 것 같다. 특히 여러 파티션과 여러 개의 네트워크 카드를 자동으로 발견하고 모니터링할 때 그 순간은 즐겁고 안심이 된다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 자신감명언)

대량 구성 및 경고의 경우:

Nagios, 호스트 배치 모니터링의 경우 스크립트를 사용하여 서버측에 호스트를 추가하고 서비스 파일을 복제해야 합니다. Nagios 는 스크립트를 사용하여 모든 호스트의 서비스 파일을 수정하고 새 서비스를 추가합니다.

Zabbix 는 서버측에서 자동 등록 규칙을 구성합니다. 규칙이 구성되면 클라이언트의 후속 추가는 서버측에서 조작할 필요가 없습니다. Zabbix 는 템플릿에 모니터링 항목을 수동으로 추가하기만 하면 됩니다.

일반적으로 다음과 같습니다.

Nagios 는 플러그인을 작성하는 데 많은 시간을 소비하고, Zabbix 는 함수를 탐색하는 데 많은 시간을 보냅니다.

Nagios 는 비교적 쉽게 시작할 수 있고, Nagios 는 이틀 만에, Zabbix 는 2 주 만에 완성된다.

Zabbix 그래픽 기능은 Nagios 보다 강력합니다.

Zabbix 는 대량 모니터링 및 서비스 변경에 대해 더욱 간결합니다. Nagios 가 자동화된 스크립트를 작성한다면 매우 간단합니다. 문제는 자동화 스크립트를 작성하는 것이 매우 힘들다는 것이다.

10. 주어진 환경 그룹, 당신은 어떻게 고가용성, 높은 동시 아키텍처를 설계할 것입니까?

작가는 이 환경이 클라우드 (예: 아리운) 에 배포되면 하드웨어 설계는 고려하지 않아도 된다고 대답했다. 아리운 SLB+ECS+RDS 에 직접 액세스할 수 있는 표준 고가용성 동시 아키텍처. 외부 서비스는 알리의 SLB 에서 백엔드 ECS 호스트로 배포되는 SLB 로드 밸런싱 기술을 직접 로드합니다. 여러 ECS 호스트를 배포하고 애플리케이션 분할을 서로 다른 ECS 호스트에 적용하여 가능한 한 서비스를 세분화합니다. 데이터베이스는 RDS 고가용성 버전 (1 차 1 차 1 차 1 차 기존 고가용성 아키텍처) 또는 RDS 금융 버전 (1 차 2 차 3 노드 아키텍처) 을 사용합니다. 알리의 다른 서비스와 함께, 완전히, 비즈니스 볼륨, 호스트 부족, ECS 호스트 수직 및 수평 확장입니다.

이 환경이 IDC 에서 호스팅되는 경우 하드웨어와 소프트웨어 (어플리케이션 서비스) 를 모두 고려해야 합니다. 하드웨어의 고가용성과 높은 동시성을 달성하기 위해 회사는 중복해야 하는 네트워크 하드웨어 장치 (예: 로드 장치 F5, 방화벽, 코어 스위치 및 액세스 레이어 스위치) 를 여러 대 구입해야 합니다. 특히 네트워크 설계에서는 장치 간에 이중선 연결이 있어야 합니다. 모든 장비가 독립 실행형이고 그 중 하나가 끊어지면 전체 네트워크가 마비되고 고가용성과 동시성은 말할 수 없다. 둘째, 응용 서비스를 고려해 보겠습니다. 성숙한 오픈 소스 시나리오 LVS+Keepalived 또는 Nginx+Keepalived 대외 서비스, redis 클러스터 및 Mongodb 클러스터를 캐시 계층으로, Kafka 및 zookeeper 를 미들웨어로, fastDFS 또는 MFS 를 미러 스토리지로 사용합니다. 데이터 양이 많은 경우 Hadoop 을 사용할 수 있습니다. 백엔드 데이터베이스는 "마스터-슬레이브 +MHA" 를 사용할 수 있습니다. 이러한 환경에서 고가용성, 고가용성, 동시 아키텍처는 절대적으로 충족됩니다.

上篇: 새 휴대폰 배터리를 처음 충전하는 데 얼마나 걸립니까? 下篇: 무적제왕 빙설의 결말은?
관련 내용