춘절이 다가옴에 따라 12306.cn 웹사이트의 티켓이 초 단위로 똑딱거리고 있으며 전국 각지에서 비난이 쏟아지고 있습니다. 12306 웹사이트의 성능과 구현에 대해 논의해 보겠습니다. .결제와 티켓 구매 및 주문을 분리하는 UI, 사용자 경험 또는 기능적 문제는 제외하고 성능 문제만 논의합니다.)
비즈니스
모든 기술은 비즈니스 요구와 불가분의 관계이므로 먼저 성능 문제를 설명하고 싶습니다. 그것에 대해 이야기하기 위해 비즈니스 문제.
1. 어떤 분들은 이것을 QQ나 온라인 게임과 비교하실 수도 있습니다. 하지만 둘은 다른 것 같아요. 온라인 게임과 QQ 온라인은 로그인 시 사용자 자신의 데이터에 더 많이 접근하는 반면, 티켓 예매 시스템은 센터의 티켓 수량 데이터에 접근한다는 점에서 다릅니다. 온라인 게임이나 QQ가 작동한다고 해서 똑같다고 생각하지 마세요. 온라인 게임과 QQ의 백엔드 로드는 여전히 전자상거래 시스템보다 간단합니다.
2. 설날 기차 예매는 마치 홈페이지 깜짝 세일 행사 같다고 하시는 분들도 계십니다. 그것은 실제로 매우 유사하지만 표면 너머로 생각하지 않으면 그것이 다소 다르다는 것을 알게 될 것입니다. 한편으로, 기차표 문제에는 수많은 쿼리 작업이 수반됩니다. 더욱 BT는 주문할 때 데이터베이스에 대한 많은 일관된 작업이 필요하다는 것입니다. 반면에 구매자는 노선, 기차, 시간을 다양하게 선택할 수 있으며 주문 방법도 끊임없이 변경됩니다. 플래시 판매의 경우 쿼리와 일관성 문제가 그리 많지 않습니다. 또한, 플래시 세일의 경우 최초 N명의 사용자 요청만 수락하도록 할 수도 있습니다(백엔드에서 데이터를 조작하지 않고 사용자의 주문만 기록하면 됩니다). 메모리 캐시는 100개의 제품에 대해 10개의 서버에 배치할 수 있으며, 이때 데이터베이스를 운영할 필요가 없습니다. 주문량이 충분해지면 플래시세일을 중단하고 일괄적으로 데이터베이스에 씁니다. 그리고 플래시 세일 품목도 많지 않아요. 기차표는 플래시 판매만큼 간단하지 않습니다. 춘절 여행 기간에는 거의 모든 티켓이 핫 티켓이며 거의 전국에서 사람들이 찾아오고 있으며 여러 노선의 재고를 처리해야 합니다. . 얼마나 어려운지 생각해 보시겠어요? (Taobao의 Double Eleven에는 사용자가 300만 명에 불과한 반면 기차표는 즉시 수천만 또는 수억에 도달할 수 있습니다.)
3. 이 시스템을 올림픽 티켓팅 시스템과 비교하는 사람들도 있습니다. 아직은 다른 것 같아요. 올림픽 티켓팅 시스템은 온라인화되자마자 폐지됐다. 하지만 올림픽은 추첨 방식을 사용하므로 선착순 방식이 없습니다. 게다가 이벤트가 끝난 후 추첨을 진행하기 때문에 사전에 정보만 받으면 되며 사전에 데이터 일관성을 확보할 필요도 없습니다. . 잠금 장치가 없으며 수평으로 확장하기 쉽습니다.
4.예약 시스템은 전자상거래 주문 시스템과 매우 유사해야 합니다, 둘 다 재고 관리가 필요합니다: 1) 재고 점유, 2) 결제 (선택), 3) 재고 차감 작업. 이를 위해서는 일관성 검사가 필요합니다. 즉, 동시성 중에 데이터를 잠가야 합니다. B2C 전자상거래 회사는 기본적으로 이 작업을 비동기식으로 수행합니다. 즉, 주문이 즉시 처리되지 않고 성공적으로 처리된 경우에만 시스템에서 주문이 성공적으로 완료되었음을 알려줍니다. . 많은 친구들이 주문 등록이 실패했다는 이메일을 받았다고 생각합니다. 이것은 데이터 일관성이 동시성에서 병목 현상을 일으킨다는 것을 의미합니다 .
5.철도의 매표업은 매우 비정상적입니다. 갑작스러운 승차권 발매로 인해 일부 승차권은 모두가 공유하기에는 턱없이 부족합니다. 다들 그냥 티켓을 잡는 관행이 있을 텐데, 이는 중국 특성을 지닌 장사다. 그래서 티켓이 공개되면 수백만, 심지어 수천만 명의 사람들이 서둘러 문의하고 주문할 것입니다. 수십 분 내에 웹 사이트에 수천만 건의 방문이 발생할 수 있습니다. 이는 무서운 일입니다. 12306의 방문 피크는 오전 8시부터 오전 10시까지 집중적으로 10억 PV로 최고조에 초당 수천만 PV가 발생한다고 합니다.
몇 마디 더 말해보세요:
웹사이트의 경우 웹 브라우징 부하가 높아 처리하기 쉽지만 쿼리 결과를 캐싱하면 처리할 수 있습니다. 가장 어려운 것은 주문 부하입니다. . 재고에 액세스해야 하기 때문에 주문은 기본적으로 비동기식으로 수행됩니다. 작년 Double 11 기간 동안 Taobao의 시간당 주문 수는 약 600,000건에 달했지만 JD.com은 하루 400,000건의 주문만 지원할 수 있었습니다(5년 전 Amazon은 시간당 700,000건의 주문을 지원할 수 있었습니다). 주문을 하는 작업이 우리가 생각하는 것만큼 고성능이 아니라는 것을 알 수 있다.
타오바오는 B2C 웹사이트보다 훨씬 간단합니다. 창고가 없기 때문에 B2C처럼 동일한 제품의 재고를 업데이트하고 업데이트할 수 있는 N 창고가 없기 때문입니다. . 쿼리 작업. B2C 웹사이트에서는 주문을 할 때 사용자와 가깝고 재고가 있는 창고를 찾아야 하므로 많은 계산이 필요합니다. 북경에서 책을 샀다고 가정해 보세요. 북경 창고에 재고가 없으면 주변 창고에서 물건을 옮겨야 합니다. 그러면 심양이나 시안 창고에 물건이 있는지 확인해야 합니다. , 강소 창고 등을 살펴 봐야합니다. 타오바오에는 물건이 그리 많지 않습니다. 각 가맹점은 자체 인벤토리를 갖고 있으며, 인벤토리는 단지 숫자에 불과하며, 이는 가맹점에 분배되므로 실적 확장에 도움이 됩니다.
데이터 일관성은 실제 성능 병목 현상입니다. 어떤 사람들은 nginx가 초당 100,000개의 정적 요청을 처리할 수 있다고 말합니다. 저는 의심하지 않습니다. 그러나 이는 이론적으로 대역폭과 I/O가 충분히 강력하고 서버의 컴퓨팅 성능이 충분하며 지원되는 동시 연결 수가 100,000개의 TCP 링크 설정을 견딜 수 있는 한 정적 요청일 뿐입니다. 괜찮아요. 그러나 데이터 일관성에 직면하여 이 100,000은 완전히 도달할 수 없는 이론적 값이 되었습니다.
너무 많이 말했지만 비즈니스 관점에서 말씀드리고 싶은 것은 비즈니스 관점에서 봄 축제 철도 티켓 예매 사업의 왜곡을 진정으로 이해해야 합니다.
프런트엔드 성능 최적화 기술
성능 문제를 해결하기 위해 다음과 같은 방법을 사용하는 일반적인 방법이 많이 있습니다. 기술은 성능에 있어서 질적인 도약을 가져올 것입니다.
1. 프런트 엔드 로드 밸런싱
DNS 로드 밸런서를 통해(일반적으로 라우팅 로드에 따라 라우터에서 리디렉션됨) 사용자 액세스가 여러 웹 서버에서. 이렇게 하면 웹 서버의 요청 부하가 줄어듭니다. http 요청은 짧은 작업이기 때문에 이 기능은 매우 간단한 로드 밸런서를 통해 완료될 수 있습니다. 사용자가 가장 가까운 서버에 연결할 수 있는 CDN 네트워크를 보유하는 것이 가장 좋습니다(CDN에는 일반적으로 분산 스토리지가 수반됩니다). (자세한 로드밸런싱 안내는 "백엔드 로드밸런싱" 참조)
2. 프런트엔드 링크 수 줄이기
12306을 살펴봤습니다. .cn을 열고 이를 열었습니다. 홈페이지는 60개 이상의 HTTP 연결을 설정해야 하며 티켓 예약 페이지에는 70개 이상의 HTTP 요청이 있습니다. 오늘날의 브라우저는 모두 동시 요청을 요구합니다(물론 브라우저 페이지에 대한 동시 요청 수는 제한되어 있습니다. 그러나 사용자를 중지할 수는 없습니다. 여러 페이지를 열면 백엔드 서버 TCP 연결이 프런트엔드에서 끊어지고 즉시 해제되거나 중요하지 않습니다. 따라서 100만 명의 사용자가 있는 한 6000만 개의 링크가 있을 수 있습니다(첫 번째 방문 후 브라우저 캐시를 사용하면 이 숫자는 감소하며 20%만 있어도 여전히 100만 수준의 숫자입니다). 링크), 너무 훨씬 더. 로그인 쿼리 페이지는 괜찮을 것입니다. 파일에 js를 입력하고, 파일에 CSS를 입력하고, 파일에 아이콘을 입력하고, CSS를 사용하여 블록으로 표시합니다. 링크 수를 최소한으로 유지하세요.
3. 웹 페이지 크기를 줄이고 대역폭을 늘리세요
이미지는 대역폭을 너무 많이 소모하기 때문에 세상의 모든 회사가 감히 이미지 서비스를 제공하는 것은 아닙니다. 오늘날의 광대역 시대에 그림 페이지를 만들 때 그림을 사용하는 것이 두려웠던 전화 접속 시대의 상황은 누구라도 이해하기 어렵습니다(휴대폰에서 탐색할 때도 마찬가지입니다). 12306 홈페이지에서 다운로드해야 할 총 파일 크기를 확인해 보니 약 900KB 정도 입니다. 방문하신 경우 브라우저에서 캐시를 많이 해주기 때문에 약 10K 파일만 다운로드하시면 됩니다. 그러나 극단적인 경우를 생각해 볼 수 있습니다. 100만 명의 사용자가 동시에 방문하고, 그들은 모두 처음으로 방문합니다. 120초 이내에 반환하려면 1M이 필요합니다. 1M /120 * 8 = 66Gbps 대역폭. 정말 놀랍습니다. 그래서 그날 12306의 혼잡은 기본적으로 네트워크 대역폭이 되어야 하므로, 무응답으로 보일 수도 있다고 추정합니다. 나중에 브라우저의 캐시는 12306이 대역폭 사용량을 많이 줄이는 데 도움이 되었기 때문에 부하가 즉시 백엔드로 이전되고 백엔드 데이터 처리 병목 현상이 즉시 제거되었습니다. 따라서 http 500 오류가 많이 표시됩니다. 이는 백엔드 서버가 다운되었음을 의미합니다.
4. 프런트 엔드 페이지의 정적화
자주 변경되지 않는 일부 페이지와 데이터를 정적화하고 gzip으로 압축합니다. 또 다른 왜곡된 방법은 이러한 정적 페이지를 /dev/shm에 두는 것입니다. 이 디렉터리는 메모리에서 직접 파일을 읽고 이를 반환하여 비용이 많이 드는 디스크 I/O를 줄일 수 있습니다. nginx의 sendfile 기능을 사용하면 이러한 정적 파일을 커널에서 직접 교환할 수 있어 성능이 크게 향상될 수 있습니다.
5. 쿼리 최적화
많은 사람들이 동일한 쿼리를 수행하고 있으며 역방향 프록시를 사용하여 이러한 동시 쿼리와 동일한 쿼리를 병합할 수 있습니다. 이 기술은 주로 쿼리 결과 캐싱을 사용하여 구현됩니다. 첫 번째 쿼리는 데이터를 얻기 위해 데이터베이스로 이동하고 모든 후속 쿼리는 캐시에 직접 액세스합니다. 각 쿼리를 해시하고 NoSQL 기술을 사용하여 이 최적화를 완료합니다. (이 기술은 정적 페이지로도 활용 가능)
기차표 금액 문의는 개인적으로 숫자를 표시하는 것보다 "예" 또는 "아니요"만 표시하면 훨씬 단순화할 수 있다고 생각합니다. 시스템 복잡성을 줄이고 성능을 향상시킵니다. 데이터베이스가 주문하는 사람들에게 더 나은 서비스를 제공할 수 있도록 데이터베이스에 대한 쿼리 로드를 오프로드합니다.
6. 캐싱 문제
캐시는 동적 페이지를 캐시하는 데 사용될 수 있으며 쿼리 데이터를 캐시하는 데에도 사용될 수 있습니다. 캐싱에는 일반적으로 여러 가지 문제가 있습니다.
1) 캐시 업데이트. 캐시 및 데이터베이스 동기화라고도 합니다. 여러 가지 방법이 있습니다. 하나는 캐시 시간을 초과하고 캐시를 무효화한 후 다시 확인하는 것입니다. 다른 하나는 백엔드가 변경되면 프런트엔드에 업데이트하도록 알리는 것입니다. 전자는 구현이 상대적으로 간단하지만 실시간 성능은 높지 않습니다. 후자는 구현이 더 복잡하지만 실시간 성능이 높습니다.
2) 캐시된 페이징. 메모리가 충분하지 않을 수 있으므로 일부 비활성 데이터를 메모리에서 교체해야 합니다. 이는 운영 체제의 메모리 페이징 및 메모리 교체와 매우 유사합니다. FIFO, LRU 및 LFU는 모두 비교적 고전적인 페이징 알고리즘입니다. 관련 콘텐츠는 Wikipeida의 캐싱 알고리즘을 참조하세요.
3) 캐시 재구성 및 지속성. 캐시는 메모리에 있으므로 시스템을 항상 유지해야 하므로 캐시가 사라지면 다시 구축해야 합니다. 이는 생산 환경에 영향을 미치므로 캐시 화학화의 지속성도 고려해야 합니다.
많은 강력한 NoSQL 시스템이 위의 세 가지 주요 캐싱 문제를 지원합니다.
백엔드 성능 최적화 기술
앞서 프론트엔드 성능 최적화 기술에 대해 논의한 바 있으므로, 프론트엔드에서는 병목 현상이 발생하지 않을 수도 있습니다. 그러면 백엔드 데이터에 성능 문제가 발생하게 됩니다. 다음은 몇 가지 일반적인 백엔드 성능 최적화 기술입니다.
1. 데이터 중복성
데이터 중복성은 즉, 데이터베이스의 데이터 중복성을 처리해야 하며, 이는 테이블 연결 작업의 오버헤드를 줄이는 것을 의미합니다. 그러나 이렇게 하면 데이터 일관성이 희생됩니다. 위험도가 상대적으로 높습니다. 많은 사람들이 데이터 처리를 위해 NoSQL을 사용합니다. 데이터가 중복되기 때문에 속도는 더 빠르지만 이는 데이터 일관성에 큰 위험을 초래합니다. 이를 다양한 비즈니스에 따라 분석하고 처리해야 합니다. (참고: 관계형 데이터베이스를 NoSQL로 이식하는 것은 쉽지만, NoSQL에서 관계형 데이터베이스로 반대로 전환하는 것은 어렵습니다.)
2. 데이터 미러링
거의 모든 주류 데이터베이스는 미러링, 즉 복제를 지원합니다. 데이터베이스 미러링의 장점은 부하 분산에 사용할 수 있다는 것입니다. 데이터 일관성을 보장하면서 하나의 데이터베이스 로드를 여러 플랫폼에 균등하게 분산합니다(Oracle의 SCN). 가장 중요한 점은 이것이 고가용성을 제공할 수 있다는 것입니다. 한 시스템에 장애가 발생하더라도 다른 시스템은 계속해서 작동됩니다.
데이터 미러링의 데이터 일관성은 복잡한 문제일 수 있으므로 데이터를 단일 데이터로 분할해야 합니다. 즉, 베스트셀러 제품의 재고를 다음과 같은 여러 서버에 균등하게 배포해야 합니다. a 베스트셀러 제품에는 10,000개의 재고가 있습니다. B2C 창고처럼 각각 1,000개의 재고가 있는 10대의 서버를 설정할 수 있습니다.
3. 데이터 파티셔닝
데이터 미러링으로 해결할 수 없는 문제 중 하나는 데이터 테이블에 레코드가 너무 많아 데이터베이스 작업이 너무 느려지는 것입니다. 따라서 데이터를 분할합니다. 데이터를 분할하는 방법에는 여러 가지가 있습니다. 일반적으로 다음과 같은 방법이 있습니다.
1) 일부 논리에 따라 데이터를 분류합니다. 예를 들어, 기차표 예매 시스템은 각 철도국별로, 다양한 모델별로, 출발역별로, 목적지별로 나누어질 수 있는데... 어쨌든 테이블을 같은 시트로 여러 장으로 나누는 것입니다. 필드는 다양한 유형의 테이블이므로 이러한 테이블은 로드를 공유하기 위해 여러 시스템에 존재할 수 있습니다.
2) 데이터를 필드별로 나눕니다. 즉, 테이블을 세로로 나눕니다. 예를 들어, 자주 변경되지 않는 일부 데이터를 하나의 테이블에 배치하고, 자주 변경되는 데이터를 여러 다른 테이블에 배치합니다. 이러한 방식으로 테이블을 1:1 관계로 전환하면 테이블의 필드 수를 줄이고 성능도 어느 정도 향상시킬 수 있습니다. 또한 필드가 너무 많으면 레코드 저장이 다른 페이지 테이블에 배치되어 읽기 및 쓰기 성능에 문제가 발생합니다. 하지만 복잡한 컨트롤이 많이 있습니다.
3) 평균점수표입니다. 첫 번째 방법은 반드시 균등하게 분할되는 것은 아니기 때문에 여전히 특정 유형의 데이터가 많이 있을 수 있습니다. 따라서 기본키 ID의 범위에 따라 테이블을 나누는 평균분배 방식도 있다.
4) 동일한 데이터 파티션. 이는 위의 데이터 미러링에서 언급되었습니다. 즉, 동일한 제품의 재고 값이 서로 다른 서버에 할당됩니다. 예를 들어 재고가 10,000개라면 10개의 서버에 할당할 수 있으며, 한 서버에는 1,000개의 재고가 있습니다. 그런 다음 로드 밸런싱을 수행합니다.
세 가지 파티션 유형 모두 장단점이 있습니다. 가장 일반적으로 사용되는 것은 첫 번째 것입니다. 데이터가 분할되면 프런트엔드 프로그램에 데이터를 찾을 위치를 알려줄 하나 이상의 스케줄러가 있어야 합니다. 열차표 데이터를 분할하여 여러 성, 시에 배치하는 것은 12306 시스템의 성능에 있어서 매우 의미 있고 질적인 향상을 가져올 것입니다.
4. 백엔드 시스템 로드 밸런싱
앞서 언급했듯이 데이터 파티셔닝은 어느 정도 로드를 줄일 수는 있지만 핫 로드의 로드를 줄일 수는 없습니다. 기차표의 경우 대도시의 일부 주요 노선의 티켓으로 간주될 수 있습니다. 이를 위해서는 로드를 줄이기 위해 데이터 미러링을 사용해야 합니다. 데이터 미러링을 사용하려면 로드 밸런싱을 사용해야 합니다. 백엔드에서는 트래픽이 서버의 사용량을 나타내지 않기 때문에 트래픽 균형을 맞추기 위해 라우터와 같은 로드 밸런서를 사용하는 것이 어려울 수 있습니다. 따라서 각 서버의 부하도 모니터링할 수 있는 작업 분배 시스템이 필요합니다.
작업 분배 서버에는 몇 가지 어려움이 있습니다.
많은 시스템이 정적 방법을 사용하여 할당하고, 일부는 해싱을 사용하고, 일부는 단순히 차례로 분석하는 것을 보았습니다. 이들 중 어느 것도 충분하지 않습니다. 하나는 완벽하게 로드 밸런싱을 할 수 없다는 것입니다. 정적 방법의 또 다른 치명적인 결함은 컴퓨팅 서버가 충돌하거나 새 서버를 추가해야 하는 경우 할당자가 이를 처리해야 한다는 것입니다. 또한 해시를 다시 계산해야 합니다. 일관된 해싱을 사용하면 이 문제를 부분적으로 해결할 수 있습니다.
또 다른 방법은 로드 밸런싱을 위한 선점형 방법을 사용하는 것인데, 다운스트림 컴퓨팅 서버가 작업 서버로 이동하여 작업을 가져옵니다. 이러한 컴퓨팅 서버가 작업을 원하는지 여부를 결정하게 하십시오. 이것의 장점은 시스템의 복잡성을 단순화할 수 있고, 컴퓨팅 서버를 실시간으로 줄이거나 늘릴 수도 있다는 점이다. 그러나 유일한 단점은 특정 서버에서만 처리할 수 있는 일부 작업이 있는 경우 이로 인해 약간의 복잡성이 발생할 수 있다는 것입니다. 그러나 전반적으로 이 방법이 더 나은 로드 밸런싱이 될 수 있습니다.
5. 비동기식, 제한 및 일괄 처리
비동기식, 제한 및 일괄 처리에는 모두 동시 요청 수에 대한 대기열 처리가 필요합니다.
비즈니스에서의 비동기식은 일반적으로 요청을 수집한 다음 처리를 지연시키는 것을 의미합니다. 기술적으로는 각 처리 프로그램을 병렬화할 수도 있고, 수평적으로 확장할 수도 있습니다. 그러나 비동기식의 기술적 문제는 다음과 같습니다. a) 호출 수신자가 반환한 결과에는 프로세스 스레드 간의 통신 문제가 포함됩니다. b) 프로그램을 롤백해야 하는 경우 롤백이 약간 복잡해집니다. c) 비동기식은 일반적으로 멀티스레딩과 멀티프로세스를 동반하며 동시성 제어가 상대적으로 까다롭습니다. d) 많은 비동기 시스템은 메시지 메커니즘을 사용하며, 메시지의 손실과 무질서도 복잡한 문제가 될 수 있습니다.
일괄 처리 기술은 기본적으로 동일한 요청을 일괄 처리하는 기술입니다. 예를 들어 모두가 같은 상품을 동시에 구매한다면 굳이 구매할 필요가 없고 한 번에 일정 개수의 요청을 데이터베이스에 기록해 두면 됩니다. 이 기술은 다양한 방법으로 사용될 수 있습니다. 예를 들어, 네트워크 대역폭을 절약하기 위해 네트워크의 MTU(최대 전송 단위)가 이더넷의 경우 1500바이트이고 광섬유의 경우 4000바이트 이상이면 네트워크 패킷 중 하나가 이 MTU를 채우지 못한다는 것을 모두 알고 있습니다. 네트워크 카드 드라이버는 블록 단위로만 효율적으로 읽을 수 있기 때문에 네트워크 대역폭이 낭비됩니다. 따라서 네트워크를 통해 패킷을 보낼 때 네트워크 I/O를 수행하기 전에 충분한 정보를 수집해야 합니다. 이 역시 일괄 처리 방법입니다. 일괄 처리의 적은 트래픽이 적다는 점입니다. 따라서 일괄 처리 시스템은 일반적으로 두 가지 임계값, 즉 작업량과 시간 초과를 설정합니다. 한 조건이 충족되면 제출 처리가 시작됩니다.
따라서 비동기식인 한 일반적으로 조절 메커니즘이 있고 일반적으로 대기열이 있으면 지속성이 있으며, 시스템은 일반적으로 일괄 처리를 사용합니다.
윤펑이 디자인한 '큐잉 시스템'이 바로 이 기술이다. 이는 전자상거래 주문 시스템과 매우 유사합니다. 즉, 내 시스템이 티켓 구매 주문 요청을 받았지만 아직 실제로 처리하지 않았습니다. 내 시스템은 자체 처리 능력에 따라 이러한 많은 숫자를 제한합니다. 요청은 조금씩 이루어지고 처리됩니다. 처리가 완료되면 이메일이나 문자 메시지를 보내 사용자에게 실제로 티켓을 구매할 수 있음을 알릴 수 있습니다.
여기에서는 Yunfeng의 대기열 시스템을 비즈니스 및 사용자 요구 관점에서 논의하고 싶습니다. 기술적으로는 이 문제를 해결하는 것처럼 보이지만 비즈니스 및 사용자 요구 측면에서는 여전히 일부 문제가 있을 수 있기 때문입니다. 깊이 생각해 볼 만한 것들:
1) 대기열 DoS 공격. 먼저 생각해보자. 이 팀은 단순한 큐인가? 이것은 스캘퍼를 제거할 수 없고 단순한 ticket_id는 DoS 공격에 취약하기 때문에 충분하지 않습니다. 예를 들어 N ticket_id를 시작하고 티켓 구매 프로세스에 들어가면 티켓을 구매하지 않으면 비용이 절반이 됩니다. 시간. 티켓을 구매하려는 사람들이 며칠 동안 티켓을 구매하는 것을 불가능하게 만드는 것은 쉽습니다. 어떤 사람들은 사용자가 줄을 서려면 ID 카드를 사용해야 하고, 구매하려면 이 ID 카드를 사용해야 한다고 말하지만, 그래도 여전히 스캘핑 대기열이나 계정 딜러를 제거할 수는 없습니다. N개의 계정을 등록해 대기열에 등록할 수 있지만 구매를 하지 않기 때문입니다. Scalpers는 현재 한 가지 작업만 수행하면 됩니다. 즉, 일반 사람들이 웹사이트에 접근할 수 없도록 만들어 사용자가 이를 통해서만 구매할 수 있도록 하는 것입니다.
2) 열 일관성? 이 대기열의 작업에 잠금이 필요합니까? 잠금이 있는 한 성능은 향상되지 않습니다. 100만명의 사람들이 동시에 위치 번호 할당을 요청한다고 상상해 보십시오. 이 대기열은 성능 병목 현상이 됩니다. 데이터베이스 성능이 좋지 않아서 지금보다 더 나빠질 수도 있습니다. 데이터베이스를 강탈하는 것과 대기열을 잡는 것은 본질적으로 동일합니다.
3) 큐 대기시간. 티켓 구매에 30분이면 충분합니까? 너무 많은가요? 해당 시간에 사용자가 인터넷에 접속할 수 없는 경우에는 어떻게 되나요? 시간이 짧으면 운영할 시간이 부족하다고 불평을 하게 되고, 시간이 길면 줄을 서서 기다리는 사람들도 불평을 하게 됩니다. 이 방법은 실제 운용에 있어서 많은 문제점을 안고 있을 수 있다. 또한 30분은 너무 길기 때문에 완전히 비현실적입니다. 15분을 예로 들어보겠습니다. 사용자는 1,000만 명인데 매 순간 10,000명만 투입할 수 있습니다. 이 10,000명의 사용자는 모든 작업을 완료하는 데 15분이 필요합니다. 그러면 이 1천만 명의 사용자를 모두 처리하려면 1000*15m = 250시간, 10일 반이 걸리고 열차는 일찍 출발하게 됩니다. (말도 안 되는 소리를 하는 것이 아니다. 철도부 전문가의 설명에 따르면 최근 며칠 동안 하루 평균 100만건의 주문이 접수돼 1000만명의 이용자를 처리하는 데 열흘이 걸린다. 계산이 좀 간단할 수도 있겠네요. 이런 저부하 시스템에서는 큐잉만으로는 비즈니스 문제를 해결할 수 없을 수도 있습니다)
4) 배분 대기열. 이 대기열 시스템은 대기열이 하나만 있습니까? 충분하지 않습니다. 왜냐하면 티켓을 구입할 수 있는 사람이 같은 기차에 대해 같은 유형의 티켓을 구입하는 경우(예: 기차의 침대칸) 그들은 여전히 티켓을 잡고 있기 때문에 시스템의 로드가 여전히 높을 수 있음을 의미합니다. 특정 서버에 집중되어 있습니다. 따라서 가장 좋은 방법은 사용자의 필요에 따라 출발지와 목적지를 제공하여 사용자를 대기열에 추가하는 것입니다. 이런 식으로 여러 개의 대기열이 있을 수 있으며, 여러 개의 대기열이 있는 한 수평으로 확장될 수 있습니다. 이렇게 하면 성능 문제를 해결할 수 있지만 사용자가 오랫동안 대기하는 문제는 해결되지 않습니다.
온라인 쇼핑을 통해 확실히 배울 수 있는 것 같아요. 대기열(주문) 시 사용자의 정보와 구매하려는 티켓을 수집하고 사용자가 티켓 구매 우선순위를 설정할 수 있도록 합니다. 예를 들어 A열차에서 침대칸을 구매할 수 없는 경우, B열차 침대칸. 그래도 구매할 수 없다면 B열차 침대칸을 구매하면 됩니다. 딱딱한 좌석 등을 구매하면 됩니다. 그런 다음 사용자가 필요한 돈을 먼저 충전한 다음 시스템이 주문을 완전히 처리합니다. 자동으로 비동기식으로. 성공 여부는 문자 메시지나 이메일을 통해 사용자에게 통보됩니다. 이러한 방식으로 시스템은 사용자 상호 작용 시간을 30분 절약하고 자동으로 처리 속도를 높일 수 있을 뿐만 아니라 동일한 티켓 구매 요청을 가진 사람들을 일괄 처리하기 위해 병합할 수도 있습니다(데이터베이스 작업 수 감소). 이 방법의 가장 좋은 점은 이러한 대기열 사용자의 요구 사항을 알 수 있다는 것입니다. 사용자의 대기열을 최적화하고 사용자를 다른 대기열에 배포할 수 있을 뿐만 아니라 철도부가 일부를 통해 Amazon의 위시리스트와 같은 열차 일정을 만들 수 있다는 것입니다. 계산 좌표 배열 및 조정(마지막으로 대기열 시스템(주문 시스템)은 메모리뿐만 아니라 데이터베이스에 저장되거나 지속되어야 합니다. 그렇지 않으면 기계가 다운될 때 꾸짖을 것입니다.)
요약
너무 많이 썼으니 요약해 보겠습니다.
0) 어떻게 디자인하든 시스템은 수평 확장이 쉬워야 합니다. . 즉, 전체 데이터 흐름의 모든 링크는 수평으로 확장될 수 있어야 합니다. 이렇게 하면 시스템에 성능 문제가 있을 때 "30배 더 많은 서버를 추가하는 것"이 비웃음이 되지 않을 것입니다.
1) 위에서 언급한 기술은 장기간의 축적 없이는 하루아침에 달성할 수 없습니다. 어떤 것을 사용하든 약간의 복잡성이 발생하고 디자인은 항상 균형을 이룬다는 것을 알 수 있습니다.
2) 중앙 집중식 티켓 판매는 처리하기 어렵습니다. 위의 기술을 사용하면 티켓 예매 시스템의 성능을 수백 배 향상시킬 수 있습니다. 다양한 지방, 시에 변전소를 건설하고 티켓을 별도로 판매하는 것은 기존 시스템의 성능을 질적으로 향상시키는 가장 좋은 방법입니다.
3) 춘절 여행을 앞두고 티켓을 구하는 비즈니스 모델은 수요에 비해 티켓 공급이 훨씬 적기 때문에 수천만, 심지어 수억 명의 사람들이 로그인할 수 있습니다. 아침 8시에 동시에 입장하여 티켓을 구합니다. 이 비즈니스 모델은 변태의 변태입니다. 비정상적인 사업 형태는 무엇을 하든 반드시 혼날 것이라고 판단한다.
4) 이런 대규모 시스템을 고작 1~2주만 구축하고 남은 시간을 헛되이 보내다니 안타깝습니다. 이런 일을 할 수 있는 건 철도뿐입니다. .
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
