1. 군중을 대면
사이트 아키텍처가 다음 사항을 충족한다면 이 기사의 최적화 계획이 매우 적합할 것입니다.
1) 다음과 같은 스크립트 언어를 사용합니다. php를 개발 언어로 사용
2) RPC 서비스, Memcache 또는 Redis 등 백엔드 서비스에 연결해야 합니다.
3) 트래픽이 매우 많습니다
2. 해결해야 할 문제
일반적인 웹 아키텍처는 위와 같습니다.
1) 프런트엔드는 APP 또는 웹페이지입니다
2) 서버의 상위 레이어는 접속을 위한 웹 서버입니다
3 )php 스크립트 언어는 백엔드 데이터를 호출하고 비즈니스 로직을 완성하며 페이지를 연결합니다
4) 마지막 끝은 서비스, 캐시 및 데이터베이스입니다
php는 C++/Java와 달리 스크립트 언어입니다. 프로세스는 상주할 수 있으므로 짧은 연결을 사용하여 백엔드 서비스에 연결합니다.
위 그림은 일반적인 시나리오입니다. PHP는 머신 A에 배포되고 Memcache를 캐시합니다. 프로세스는 다음과 같습니다.
1) php는 tcp 짧은 연결을 설정합니다
2) memcache 프로토콜에 따라 데이터를 보냅니다
3) memcache에서 반환된 데이터를 받습니다
4) PHP는 tcp를 닫습니다 짧은 연결
사이트 트래픽이 적을 때 위 프로세스는 문제가 없습니다. 사이트 트래픽이 매우 크고 QPS가 매우 높을 때 PHP는 Memcache의 TCP 설정 오버헤드 + TCP 짧은 연결 종료를 수행할 수 없습니다. 이를 무시하면 성능 병목 현상이 발생할 수 있습니다. 이를 최적화하는 방법이 이 문서의 핵심입니다.
3. 유닉스 도메인 소켓 소개
이야기를 바꿔서 유닉스 도메인 소켓 기술을 살펴보겠습니다.
UNIX 도메인 소켓은 프로세스 간 IPC 통신 메커니즘으로, 네트워크 프로토콜 스택을 통과할 필요가 없고, 패키징 및 언팩, 체크섬 계산, 시퀀스 번호 및 응답 유지 등이 필요하지 않습니다. 프로세스의 애플리케이션 계층 데이터를 전송하고 다른 프로세스로 복사합니다. 동일한 호스트에서 관련되지 않은 두 프로세스에 사용할 수 있으며 전이중이므로 안정적인 메시지 전달을 위한 IPC 메커니즘을 제공합니다(메시지가 손실되거나 반복되거나 혼동되지 않음).
4. 최적화 계획
UNIX 도메인 소켓의 효율성은 tcp short 연결보다 훨씬 높음을 알 수 있지만, 동일 간의 프로세스 통신에만 사용할 수 있습니다. 호스트, PHP 애플리케이션 및 백엔드 서비스는 종종 다른 시스템에 배포됩니다. 현재로서는 이를 최적화에 사용할 수 있습니까? 대답은 '예'입니다.
간단한 아키텍처 다이어그램은 위와 같습니다. PHP 애플리케이션 서버에 로컬 프록시가 배포되어 있으며, PHP와 로컬 프록시 간의 통신에 사용됩니다. local -프록시는 TCP 긴 연결을 통해 백엔드 서비스와 통신하므로 통신 효율성이 크게 향상되고 각 요청에 대해 TCP 짧은 연결을 설정하고 닫는 오버헤드가 제거됩니다.
5. local-proxy의 핵심 포인트
위의 최적화 계획을 구현하기 위해서는 local-proxy를 구현할 때 몇 가지 포인트를 지불해야 합니다. 주의
1) 프로토콜 설계: local-proxy 자체에는 비즈니스 로직이 없으며, 업스트림에서는 memcache 프로토콜을 전송하고 이를 백엔드 memcache로 투명하게 전송합니다. 이 경우 업스트림 클라이언트는 코드를 수정할 필요가 없습니다
2) 통신 방법: 위에서 언급한 것처럼 local-proxy는 UNIX 도메인 소켓을 사용하여 업스트림과 통신하고 tcp 긴 연결을 사용하여 클라이언트와 통신합니다. 다운스트림
3) 효율적인 프레임워크: 이 솔루션은 TCP 짧은 연결 문제를 해결하기 위한 것입니다. 연결의 효율성 손실로 인해 로컬 프록시에 대한 효율성 요구 사항이 매우 높으며 성숙하고 효율적인 네트워크 프레임워크를 사용할 수 있습니다.
을 달성하려면 (예: libevent) 및 TCP 긴 연결 연결 풀 기술이 필요합니다.
4) 요청 매핑: 업스트림에서 보낸 요청과 다운스트림으로 보낸 요청을 하나씩 매핑하여 업스트림 요청이 패킷과 응답 패킷이 올바르게 매핑될 수 있습니다.