대규모 웹사이트 아키텍처를 설계하고 제작할 때 고려해야 할 10가지 문제_HTML/Xhtml_웹페이지 제작

여기서는 PHP, JSP 또는 .NET 환경에 대해 이야기하는 것이 아닙니다. 구현 언어는 문제가 아닙니다. 언어의 장점은 품질보다는 구현에 있습니다. 어떤 언어를 선택하든 아키텍처는 직면해야 합니다.

　1. 대량 데이터 처리

우리 모두 알고 있듯이 상대적으로 작은 일부 사이트의 경우 데이터 양이 그리 크지 않습니다. 선택 및 업데이트로 우리가 직면한 문제는 부하 자체가 크지 않으며 몇 가지를 추가하면 해결할 수 있습니다. 인덱스는 많아야 합니다. 대규모 웹 사이트의 경우 하루에 발생하는 데이터 양이 수백만 개에 달할 수 있습니다. 다대다 관계를 제대로 설계하지 않으면 초기 단계에는 문제가 없습니다. 데이터는 기하학적으로 증가할 것입니다. 이때 테이블을 선택하고 업데이트하는 비용(여러 테이블의 공동 쿼리는 말할 것도 없고)이 매우 높습니다.

　2. 데이터 동시 처리

어떤 경우에는 2.0 CTO가 캐싱하는 Shang Fang 검을 가지고 있는 경우도 있습니다. 캐싱은 동시성이 높고 처리량이 높은 경우에도 큰 문제가 됩니다. 캐시는 애플리케이션 전체에서 전역적으로 공유됩니다. 그러나 수정 시 두 개 이상의 요청이 동시에 캐시에 대한 업데이트를 요청하면 애플리케이션이 직접 종료됩니다. 이때 좋은 데이터 동시성 처리 전략과 캐싱 전략이 필요합니다.

또한 데이터베이스에 교착 상태가 발생하는 문제가 있습니다. 동시성이 높은 상황에서는 교착 상태가 발생할 확률이 매우 높습니다.

　3. 파일 저장 문제

파일 업로드를 지원하는 일부 2.0 사이트의 경우 다행스럽게도 하드 디스크 용량이 점점 커지고 있는 경우 파일을 어떻게 저장하고 효과적으로 색인화해야 하는지에 대해 더 많이 고려해야 합니다. 일반적인 해결책은 날짜와 유형별로 파일을 저장하는 것입니다. 그러나 파일 볼륨이 대용량인 경우, 하드 디스크에 500G의 작은 파일을 저장하면 유지 관리 및 사용 시 디스크의 Io가 큰 문제가 되지만, 대역폭이 충분하더라도 디스크가 응답하지 않을 수 있습니다. 이때 업로드도 포함되면 디스크가 쉽게 오버될 수 있습니다.

RAID와 전용 스토리지 서버를 사용하면 현재의 문제를 해결할 수 있지만 여전히 다양한 장소에서 액세스하는 데 문제가 있을 수 있습니다. 액세스 속도를 어떻게 해결할 수 있을까요? 그렇다면 파일 인덱스와 아키텍처를 어떻게 계획해야 할까요?

그래서 파일 저장이 매우 어려운 문제라는 점을 인정해야 합니다

　4. 데이터 관계 처리

다대다 관계로 가득한 세 번째 패러다임에 맞는 데이터베이스를 쉽게 계획할 수 있고, INDENTIFY COLUMN을 GUID로 대체할 수도 있습니다. 그러나 다대다 관계가 존재하는 2.0 시대에는 세 번째 패러다임은 첫 번째 패러다임을 폐기해야 한다는 것입니다. 다중 테이블 공동 쿼리는 효과적으로 최소한으로 줄여야 합니다.

5. 데이터 인덱스 문제

우리 모두 알고 있듯이 인덱싱은 데이터베이스 쿼리 효율성을 향상시키는 가장 저렴하고 쉬운 방법입니다. 하지만 높은 UPDATE의 경우 업데이트 및 삭제 비용이 상상할 수 없을 정도로 높을 것입니다. 작성자는 집중된 인덱스 업데이트를 완료하는 데 10분이 소요되는 상황에 직면했기 때문에 이러한 기본은 견딜 수 없습니다.

인덱싱과 업데이트는 천적입니다. 문제 A, D, E는 아키텍처를 수행할 때 고려해야 할 문제이자 가장 많은 시간이 걸리는 문제일 수도 있습니다.

　6. 분산처리

2.0 웹사이트의 경우 높은 상호작용성으로 인해 CDN의 효과는 기본적으로 0입니다. 콘텐츠는 실시간으로 업데이트되며 관례적으로 처리됩니다. 다양한 장소에서 접속 속도를 보장하기 위해서는 큰 문제에 직면해야 하는데, 이는 어떻게 하면 다양한 장소에 있는 서버의 실시간 통신을 효과적으로 구현하는가 하는 문제입니다.

7. Ajax 장단점 분석

AJAX는 성공하고 AJAX는 실패합니다. AJAX가 주류 트렌드가 되었는데 갑자기 XMLHTTP 기반의 게시물과 가져오기가 너무 쉽다는 것을 알게 되었습니다. 클라이언트는 데이터를 가져오거나 서버에 게시하고, 서버는 데이터 요청을 받은 후 이를 반환합니다. 이는 일반적인 AJAX 요청입니다. 그러나 AJAX 처리 중에 패킷 캡처 도구를 사용하면 데이터 반환 및 처리가 한눈에 명확해집니다. 일부 계산 집약적인 AJAX 요청의 경우 웹 서버를 쉽게 종료할 수 있는 패킷 전송 시스템을 구성할 수 있습니다.

8. 데이터 보안 분석

HTTP 프로토콜의 경우 데이터 패킷은 암호화를 사용할 수 있다고 말할 수 있지만 G 문제의 경우 암호화 프로세스가 일반 텍스트(예: 우리가 알고 있는 QQ)일 수 있습니다. 암호화를 쉽게 판단하고 그의 것과 유사한 암호화 및 암호 해독 방법을 효과적으로 작성합니다. 사이트 트래픽이 그다지 크지 않을 때는 아무도 신경 쓰지 않지만 트래픽이 증가하면 소위 플러그인, 소위 대량 메시지가 차례로 따라옵니다(대량 메시지에서 단서를 볼 수 있습니다) QQ의 시작). 아마도 이를 구현하기 위해 더 높은 수준의 판단이나 심지어 HTTPS를 사용할 수 있다고 안전하게 말할 수 있습니다. 이러한 프로세스를 수행하면 막대한 데이터베이스, IO 및 CPU 비용을 지불하게 됩니다. 일부 대량발송의 경우 기본적으로 불가능합니다. 저자는 Baidu 공간과 QQ 공간에 대한 대량 메시징을 달성할 수 있었습니다. 실제로 시도해 볼 의향이 있다면 어렵지 않습니다.

　9. 데이터 동기화 및 클러스터 처리 문제

데이터베이스 서버 중 하나가 과부하되면 이때 데이터베이스 기반 로드 및 클러스터링을 수행해야 합니다. 이는 현재 가장 골치 아픈 문제일 수 있는데, 데이터는 네트워크를 통해 전송됩니다. 데이터베이스의 설계에 따라 데이터 지연은 심각한 문제이며, 이 경우 이를 해결하기 위해 다른 수단을 사용해야 합니다. 몇 초 이상의 지연 시간 내에 효과적인 상호 작용이 이루어지도록 하십시오. 데이터 해싱, 세분화, 콘텐츠 처리 및 기타 문제 등이 있습니다.

　10. 데이터 공유 채널 및 OPENAPI 동향

Openapi는 구글, 페이스북, 마이스페이스부터 국내 학교까지 모두가 이 문제를 고려하고 있습니다. 이를 통해 사용자를 더 효과적으로 유지하고 더 많은 사람들을 유치할 수 있습니다. 개발. 현재 효과적인 데이터 공유 플랫폼과 데이터 오픈 플랫폼은 필수 불가결한 요소가 되었습니다. 개방형 인터페이스의 경우 데이터 보안과 성능을 보장하는 것도 진지하게 고려해야 할 문제입니다.