JSP는 대규모 웹사이트에 적합한데 왜 바이두 홈페이지는 여전히 PHP로 작성되나요?

PHP中文网
풀어 주다: 2016-07-30 14:02:13
원래의
4802명이 탐색했습니다.

일반적으로 Java는 기술적인 면에서 PHP를 훨씬 능가합니다. (대기업이 감당해야 하는 비용 문제에도 불구하고, Baidu의 홈페이지는 왜 JSP로 작성되지 않습니까?) 실시간 검색은 배포할 필요가 없나요? 그리고 일부 결과는 입력할 때 자동으로 로드됩니다.

답글 내용:

이 책을 보내주실 수 있나요?
이 게시자를 차단하고 싶습니다. 완하제.
우선 바이두 홈페이지가 실제로 php를 사용하는지 확인해보겠습니다. baidu,com/index.php 은 의심할 여지 없이 열릴 수 있지만 라우팅 설정을 HTTP 서비스 소프트웨어 수준에서 설정하여 이 주소를 실제로 정적 파일이나 기타 CGI 처리 리소스(예: 의사 파일)와 같은 다른 콘텐츠로 구문 분석할 수 있다는 것도 알고 있습니다. 정적 구현은 HTML을 PHP와 같은 다른 동적 리소스로 라우팅하는 것입니다(캐싱을 고려하면 정적 리소스일 수도 있음). 따라서 이것만으로는 PHP인지 여부를 판단하는 것이 불가능합니다.
그래서 크롬으로 바이두를 열었는데,

JSP는 대규모 웹사이트에 적합한데 왜 바이두 홈페이지는 여전히 PHP로 작성되나요?

JSP는 대규모 웹사이트에 적합한데 왜 바이두 홈페이지는 여전히 PHP로 작성되나요?

우리가 봐야 할 정보는 먼저 빨간색으로 표시된 내용입니다. Sever 값은 bfe/1.0.8.14로 설정됩니다. http 헤더의 서버 필드는 일반적으로 http 서버의 이름입니다. 예를 들어 Zhihu:
JSP는 대규모 웹사이트에 적합한데 왜 바이두 홈페이지는 여전히 PHP로 작성되나요?

Qnginx입니다. Nginx의 마법 수정일 수 있습니다. Baidu의 bfe는 자체 제품이거나 nginx 등의 소스 코드를 변경했을 수 있습니다. 이에 대해서는 Baidu 홈페이지에서 어떤 서버가 사용됩니까?
그럼 setcookie에 설정된 쿠키 내용을 살펴보겠습니다. 일반적으로 PHP 자체에서 설정한 쿠키에는 다음과 유사한 필드가 있다는 것을 알고 있습니다.
JSP는 대규모 웹사이트에 적합한데 왜 바이두 홈페이지는 여전히 PHP로 작성되나요?

그러나 Baidu의 경우를 살펴보겠습니다.
JSP는 대규모 웹사이트에 적합한데 왜 바이두 홈페이지는 여전히 PHP로 작성되나요?

바이두의 이름을 딴 토큰 필드는 PHP와 함께 제공되는 쿠키를 사용하지 않으며 나중에 설명할 많은 언어/프레임워크와 함께 제공되는 쿠키처럼 보이지 않습니다.
Baidu 홈페이지의 요청 필드를 다시 살펴보겠습니다.
JSP는 대규모 웹사이트에 적합한데 왜 바이두 홈페이지는 여전히 PHP로 작성되나요?

HHVM인 HPHP는 Baidu가 프록시

를 사용하지 않는 경우입니다. HTTP 서버 수준에서 헤더나 HHVM을 수정하려면(Baidu는 기밀이 아닌 항목을 변경하는 데 그리 게으르지 않을 것입니다) PHP를 사용해야 합니다. 그럼 왜 기본 쿠키를 사용하지 않는지 설명하겠습니다(기본 쿠키에는 PHPSESSID 필드가 있습니다)

session_start()
로그인 후 복사

Facebook은 Sina Weibo와 Tencent와 마찬가지로 여전히 PHP로 작성되었습니다. 아직도 Zhihu에서 Python을 사용하시나요? 제목 게시물에 게시된 정보의 정확성 여부와 관계없이
바이두 홈페이지의 PHP는 결과 렌더링에만 사용되며, 검색 엔진 자체는 PHP를 기반으로 해서는 안 됩니다. 닦아드릴게요. .
바이두 직원으로서 한밤중에 이 질문을 보고 순간 기운이 났습니다. .
한 사람은 웃고 있고, 다른 사람은 마음 속 깊은 곳에서 불평을 하지 않을 수 없습니다. .
학생이신가요? 또는 나는 매우 큰 프로젝트에 노출된 적이 없습니다. 만약 대기업에 가서 연락을 해볼 기회가 있다면 이 질문이 정말 어리석다는 것을 알게 될 것입니다. .
회사가 요즘 나쁜 놈들을 끌어들이고 있어서 사람들과 논쟁하기에는 너무 게으른 관계로 익명으로 하겠습니다.

우선 PHP는 페이지 렌더링을 할 수 있지만, 프레임워크 작업을 해본 적이 있다면 이 URL 요청이 분산된다는 점, 어디서든 독립적으로 작동할 수 있는 여지가 많다는 점을 알아야 합니다. 배포.

일단 중간 배포는 확실히 생각만큼 간단하지 않습니다. 매일 수억 건의 요청이 들어오고, 전국에 분산된 다양한 캐시, 클러스터 등이 있을 것입니다.
게다가 홈페이지 로딩 속도를 빠르게 하기 위해서는 C 최적화로 변경해야 합니다.

그런 다음 입장하면 해당 검색 클러스터에 배포됩니다.
코드는 C인데 왜죠? 왜냐면 제가 직접 바꿨거든요. .
여러 모듈로 나누어져 있습니다. .

예를 들어 검색창에 단어를 입력하는 순간부터 데이터를 검색하는 과정은 참으로 간단합니다. .

크롤러는 데이터를 크롤링한 후 해당 데이터를 기반으로 인덱스를 구축합니다.
문제는 모든 세부 사항에 최선을 다하는 복잡성이 매우 높다는 것입니다.

단어를 더 정확하게 분류하려면 어떻게 해야 하나요? 오픈소스 라이브러리를 직접 사용하시겠습니까? 농담하는 거야? 이를 담당하는 전문팀이 있는 것이 가장 좋고, 좀 더 연구 중심적이기 때문에 이를 위해서는 박사 학위와 대학원생을 많이 모집해야 합니다.
자, 이제 단어를 나누었으니 색인을 가져와야 합니다.
수천억 개의 결과 중에서 해당 데이터를 밀리초 내에 어떻게 찾을 수 있나요?
그런 다음 이를 정렬하고 사용자가 원하는 결과를 반환합니까? 복잡하게 들리나요?

사실 이렇게 말하면 별로 번거롭지 않습니다. 그냥 지퍼를 거꾸로 씌우고 좋은 캐시를 만들어보세요. 사실 검색어의 90%가 10%입니다.
그런데 데이터의 양이 좀 많아서 이 인덱스를 전부 메모리에 담을 수 없고, 그 중 일부를 하드디스크에 넣어야 하는 것도 문제입니다. 최적화 좀 해?

그렇다면 사용자에게 가장 적합한 것을 선택하는 방법은 무엇일까요? 이 전략에는 많은 최적화 포인트가 있으며, 잘 수행하면 한 무리의 사람들을 얻게 됩니다.

이것은 단지 검색일 뿐입니다.
크롤러의 경우 우리가 매일 크롤링하는 데이터는 일반 사람들의 상상을 초월합니다. 효율적으로 크롤링하는 방법은 검색 끝까지 더욱 신뢰할 수 있는 데이터를 제공할 수 있습니다.
이것도 여러 사람이 하는 일입니다.

그런데 또 문제가 발생합니다. 데이터의 양이 너무 많다는 것을 알게 되었는데, 이 데이터를 어떻게 저장해야 할까요? 어떻게 하면 더 잘 관리할 수 있나요?
이 모든 작업에 많은 인력이 필요한 것은 아닙니다. .

아, 그리고 Fengchao, 이건 매일 당신이 해킹하는군요.
돈이 들어가기 때문에 다양한 전략과 데이터 최적화에 많은 인력이 투자됩니다.

그래서 질문을 봤습니다. . . .
정말 어쩌겠어요, 다음 초대형 프로젝트에 뛰어들자고 생각해요.
기본적으로 어떤 순간에 자신에게 가장 적합한 언어가 있다는 것을 알게 될 테니 그냥 사용해 보세요.
바이두는 초기에는 몇 명만 있고, 사용자가 수십만 명이면 좋을 것 같아요. 그냥 웹사이트에 가서 빠르게 사용하면 효율성을 고려할 필요가 없어요. 백엔드 인덱싱은 처음에 하둡이 없었을 때 항상 기계 유지 관리에 문제가 있어서 매일 몇 명을 보내서 수동으로 유지 관리를 했습니다.
그러다가 나중에 php가 사용하기 쉽지 않다는 걸 알게 되어서 최적화를 생각하게 됐어요.
어쨌든 사업이 자리잡고 돈도 벌고, 인재들을 잔뜩 고용해서 열심히 일하면 분명 해결책이 나올 겁니다.

물론, 검색 엔진은 여전히 ​​기술적으로 매우 까다롭습니다. 지금은 다양한 프레임워크와 클라우드 컴퓨팅이 성숙해졌기 때문에 그 당시에는 실제로 그렇게 하는 데 큰 기술적 장벽이 있었습니다.
웹사이트를 구축하는 것보다 적어도 수십 배는 더 어렵습니다.

하지만 언어가 가장 큰 문제는 절대 아닙니다. .

여기서는 여전히 언어 문제로 어려움을 겪고 있다는 것을 알게 될 것입니다. PHP에서 제공하는 데이터베이스 인터페이스는 균일하지 않습니다. . . . . . 몇 년 전. . . pdo 나오자마자 해결됐네요. 질문 작성자가 표현한 많은 의견은 일방적이고 시대에 뒤떨어진 것입니다. 일반적으로 말하면, PHP는 현재 WEB 비즈니스에서 지배적인 위치를 차지하고 있지만, 일반적으로 대규모 비즈니스에서는 PHP가 이미 JSP와 경쟁할 수 있습니다. 많은 측면. 게다가. . . Baidu의 검색 엔진이 PHP라고 누가 말했습니까? . . 홈페이지는 단지 하나의 스킨일 뿐입니다. 무엇을 사용하여 작성하든 큰 차이는 없습니다. 물론 검색도 배포되지만 서비스로 제공되며 홈페이지와는 아무런 관련이 없습니다. 일부 결과를 자동으로 로딩하는 경우에는 JS에서 요청을 보내고, 백그라운드도 서비스로 제공됩니다. 백엔드 서비스에 관해서는 Baidu가 어떻게 구현하는지 모르겠습니다. 선택할 수 있는 언어와 솔루션이 다양하므로 자신에게 맞는 것을 선택하세요. 실제로 Java를 기반으로 한 검색 솔루션은 많이 있지만 Java 없이는 할 수 없다는 의미는 아닙니다. php와 jsp 사이에는 업그레이드나 대체 관계가 없습니다. php가 약해 보이는 이유는 중국에서 php를 쓰는 사람들이 대부분 약하기 때문입니다. 페이스북이 hhvm 이전에 PHP로 전환하더라도 하루에 10억 건의 요청을 쉽게 지원할 수 있고, 서버를 많이 사용하지도 않습니다. 구체적인 데이터는 없지만, 당시 fb의 php 독립형 qps가 3000~5000 정도였다고 추측하는 사람들도 있는데, 이는 jsp 독립형과 큰 차이가 없는 수준이었습니다. 제가 일하는 회사에서 단일 PHP 시스템의 최대 성능은 약 700qps입니다. 이는 주로 혼란스러운 코드 작성과 열악한 성능 때문입니다. Taobao의 공유에 따르면 일부 PHP 비즈니스 클러스터의 단일 시스템 QPS는 200-300에 불과합니다. 이것은 인간의 문제라는 것을 의미할 뿐입니다. 마지막으로, 건축에 관한 기사를 더 읽어보는 것이 좋습니다. 그러한 질문에 대한 답이 자연스럽게 담겨 있습니다. Baidu 검색 엔진에 홈페이지가 하나만 있다고 생각하시나요? PHP는 세상에서 가장 아름다운 언어입니다 맙소사~

위의 내용은 JSP가 대형사이트에 적합한데 왜 아직도 바이두 홈페이지는 PHP로 작성되어 있는 걸까요? 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 주목해주세요!


관련 라벨:
원천:php.cn
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿