높은 동시성으로 간주되는 qps는 얼마입니까?

네 가지 측면의 높은 동시성

동시성만 있는 것은 아닙니다. 유용성을 향상시키는 것은 불량하게 행동하는 것입니다. 이 문제는 네 가지 관점에서 논의될 수 있다.

우선, 무상태 프런트엔드 머신은 요청 트래픽을 처리하기에 충분하지 않으며 일반적으로 QPS는 수천 수준으로 확장되어야 합니다. 그러면 관계형 데이터베이스는 최대 읽기 또는 쓰기를 처리할 수 없으며 일반적으로 수천~만 수준의 데이터베이스 확장 또는 NoSQL 도입이 필요합니다. 그 이후에는 nosql을 단일 시스템에서 호스팅할 수 없으며 nosql을 수평으로 확장해야 합니다(보통 100,000에서 100만 QPS까지). 마지막으로, 단순히 NoSQL을 수평적으로 확장하는 것은 어렵습니다. 예를 들어 Weibo는 다중 레벨 캐시 아키텍처를 도입했습니다. 이 아키텍처는 일반적으로 NoSQL에 대한 수백만에서 수천만 개의 QPS 액세스를 처리할 수 있습니다. 물론 사용자 측 인터페이스 요청은 일반적으로 이 수준에 도달하지 않습니다. QPS의 증가는 대부분 높은 동시성 아키텍처에서도 고려되는 읽기 증폭으로 인한 압력 때문입니다.

영상강좌 추천→: "천만급 데이터 동시성 솔루션(이론+실기)" #🎜🎜 #

PV 및 QPS

예를 들어, 매일 1억 개가 넘는 PV를 제공하는 Weibo의 시스템은 일반적으로 1500QPS에 불과하며 최대 5000QPS입니다. .

예를 들어 누군가 이렇게 말했습니다.

2C4G 기계는 일반적으로 기계당 1000QPS입니다.

8C8G 기계는 7000QPS만 견딜 수 있습니다.

뒤에 쓰기

QPS의 특정 개수는 비즈니스와 밀접한 관련이 있습니다. 읽기 전용 인터페이스는 캐시를 읽고 넣습니다. 3000개 이상의 단일 머신의 캐시에 대한 압박입니다. 1000개 이상의 쓰기 요청이 있는 것은 정상이지만, 더 복잡하다면 몇백 QPS에 불과할 수도 있습니다.

그래서 QPS는 비즈니스 시나리오 및 설계와 밀접한 관련이 있습니다. 예를 들어, QPS는 브라우저 로컬 캐싱, 핫 데이터 쿼리용 캐시 사용, 트랜잭션 MQ 비동기 처리 작성 등을 통해 향상될 수 있습니다.

자세한 내용은

FAQ을 참조하세요. PHP 중국어 웹사이트를 방문하세요.

위 내용은 높은 동시성으로 간주되는 qps는 얼마입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!