Java 기반 대량 트랜잭션 웹 응용 프로그램

Question

대량 거래 웹 사이트를 다루는 경험이 전혀 없으며 최근에이 흥미로운 질문을 접하게되었습니다. Java 웹 애플리케이션의 병목 현상이 높은로드 (초당 수천 개의 요청)에서 발생하는 위치를 파악하는 데 관심이 있습니다. 누군가 내게 다음 질문에 대해 생각해 볼 수있는 높은 수준의 접근 방식을 제공 할 수 있다면 좋을 것입니다.

memcached를 사용하여 데이터베이스 조회를 캐싱하는 방법 밖에 없지만 각 요청에 소요되는 시간을 계산하는 방법을 모르므로 시스템에서 초당 요청 수를 계산하지 못합니다. 처리 할 수 ​​있을지도 모른다.

질문 : 인터넷 규모 응용 프로그램은 많은 양의 트랜잭션을 처리하도록 설계되어야합니다. 초당 평균 30,000 개의 HTTP 요청을 처리해야하는 시스템을위한 설계를 설명하십시오. 각 요청에 대해 시스템은 URL 쿼리 문자열을 통해 전달 된 키워드를 사용하여 5 천만 단어 사전에 조회를 수행해야합니다. 각 응답은 단어의 정의 (100 바이트 이하)가 포함 된 문자열로 구성됩니다.

시스템의 주요 구성 요소를 설명하고 사용자 지정 구성 요소 및 타사 응용 프로그램을 활용할 수있는 구성 요소를 기록하십시오. 각 구성 요소에 대한 하드웨어 예상치를 포함하십시오. 최소 하드웨어/소프트웨어 라이센스 비용으로 최대 성능을 포함해야합니다.

추정치가 나오기까지의 근거를 문서화하십시오.

정의가 각각 10 킬로바이트 인 경우 디자인이 어떻게 변경되는지 설명하십시오.

Answer 1

배경으로 specmarks과 같은 bechmark가있을 수 있습니다. 시나리오와 비교해 볼 때 훨씬 많은 처리가 이루어 지지만 30,000 req/sec가 비교적 높지만 미친 것은 아닙니다.

Joines et al이 유용 할 수도 있습니다. (면책 조항 : 그들은 동료입니다.) 시나리오 I 비용의 내림차순으로 기대에

:

1. 데이터베이스 검색
2. 네트워크 활동 읽기 및 반환 요청
3. 간단한 처리

을

복잡한 처리 (예 : 그래픽 렌더링 또는 로켓 과학 유형 계산)를 수행하지 않습니다. 첫 번째 추측 : 당신의 사전이 데이터베이스라면 쿼리를하는 비용이 다른 모든 것을 지배하게 될 것입니다. 전통적으로 Web/App 서버 계층에서 병목 현상이 발생하면 더 많은 인스턴스를 추가하여 확장 할 수 있지만 병목 현상이 문제가 될 수 있습니다. 그래서 한 방향 : 30k tps가 실현 가능한 데이터베이스 엔진에서 기대할 수있는 성능은 무엇입니까?

첫 번째 관찰 : 캐시 물건은 일반적으로 사용되는 상태입니다. 여기에 (아마도) 임의의 히트가 전체 사전에 있으므로, 최근의 asnwers를 캐싱하는 것이 아마 도움이되지 않을 것입니다. 그렇지 않으면 ... 모든 것을 캐시 할 수 있습니까?

50000000 * (100 + 오버 헤드) == ??

64 비트 OS의 64 비트 JVM에 맞습니까?

데이터가 크면 (아마도 데이터가 커지면 아마도 그렇지 않을 것입니다.) 그렇다면 크기를 조정해야합니다. 따라서 캐시를 슬라이싱하는 전략을 사용할 수 있습니다. A-F, G-M, N-P, T-Z를 각각 제공하는 4 개의 서버 (예 : 4 개의 개별 캐시 또는 4 개의 개별 데이터베이스)가 있습니다. 디스패처에게 요청을 지시하게하십시오.

Answer 2

제가 할 첫 번째 일은 숫자에 질문하는 것입니다. 영어에는 약 17 만 단어가 공통적으로 사용됩니다. 다른 모든 공통 언어를 추가하면 2 천만 개를 초과하지 않게됩니다. 그렇지 않은 경우 가장 일반적인 단어를 빠른 캐시에 캐시하고 덜 일반적인 단어는 더 느린 캐시에 캐시 할 수 있습니다. 초당 30K 요청시에도 모든 unqiue 단어를 가져 오는 데 약 30 분이 걸립니다.

기본적으로 숫자가 실제 값이 아닌 경우 큰 시스템을 설계 할 필요가 없습니다.

64 비트 JVM에서 이것은 쉽게 맞습니다. 50,000,000 * (100 + 오버 헤드)는 약 10GB입니다 (오버 헤드는 키가 있어야하고 데이터를 색인해야하므로 높음). 12GB 서버의 비용은 약 2,500 달러입니다.

문제는 요청 수와 같습니다. 여러 대의 기계가 있어야하지만 다른 포스터가 제시 한 것처럼 실제 수치가 될 가능성은 희박합니다. 나는이 서비스가 페이스 북만큼 비쌀 것이라고 상상하지는 않지만,이 많은 요청들을 지원하기 위해서는 수십에서 수백 개의 서버가 필요할 것 같다.