PHP, JSP 또는 .NET 환경인지에 대해서는 논의하지 않을 것입니다. 우리는 건축의 관점에서 문제를 살펴 봅니다. 언어 구현은 문제가되지 않습니다. 언어의 장점은 좋든 나쁘 든 구현에 있습니다. 어떤 언어를 선택하든 건축은 직면해야합니다.
1. 대규모 데이터 처리
우리 모두 알다시피, 비교적 작은 사이트의 경우 데이터의 양은 그리 크지 않습니다. 선택 및 업데이트는 우리가 직면 한 문제를 해결할 수 있습니다. 하중 자체는 크지 않으며 최대 몇 가지 인덱스를 수행 할 수 있습니다. 대규모 웹 사이트의 경우 하루에 데이터의 양은 수백만이 될 수 있습니다. 제대로 설계되지 않은 다중 관계가 초기 단계에서 문제가되지 않지만 사용자가 성장함에 따라 데이터의 양이 기하학적으로 증가합니다. 현재 테이블을 선택하고 업데이트 할 때 (여러 테이블의 공동 쿼리는 말할 것도없이) 비용이 매우 높습니다.
2. 데이터 동시성 처리
어느 시점에서 2.0 CTO에는 캐시 인 Shangfang Sword가 있습니다. 캐시의 경우 높은 동시성과 높은 처리가 수행되는 경우에도 큰 문제입니다. 전체 애플리케이션에서 캐시는 전 세계적으로 공유됩니다. 그러나 수정을 할 때 두 개 이상의 요청에 동시에 캐시에 대한 업데이트가 필요한 경우 응용 프로그램이 직접 죽습니다. 현재 좋은 데이터 동시성 처리 전략 및 캐싱 전략이 필요합니다.
또한 데이터베이스 교착 상태 문제입니다. 어쩌면 우리는 일반적으로 높은 동시성에서 교착 상태가 발생할 확률이 매우 높다고 생각하지 않으며 디스크 캐싱은 큰 문제라고 생각하지 않습니다.
3. 파일 저장 문제
파일 업로드 2.0을 지원하는 일부 사이트의 경우 하드 디스크 용량이 점점 커지고 있다는 것이 운이 좋으면 파일을 효과적으로 저장하고 인덱싱하는 방법을 더 고려해야합니다. 일반적인 솔루션은 파일을 날짜와 유형별로 저장하는 것입니다. 그러나 파일 볼륨이 방대한 경우 하드 디스크가 500g의 사소한 파일을 저장하면 디스크의 IO가 유지 보수 및 사용 중에 큰 문제입니다. 대역폭이 충분하더라도 디스크가 응답하지 않을 수 있습니다. 현재 업로드가 참여하면 디스크가 쉽게 끝날 것입니다.
아마도 RAID 및 전용 스토리지 서버를 사용하면 현재 문제를 해결할 수 있지만 다양한 장소에서 액세스 문제가있는 또 다른 문제가 있습니다. 어쩌면 우리 서버는 베이징, 아마도 윈난 또는 Xinteng의 액세스 속도에 있을까요? 배포되면 파일 인덱스와 아키텍처를 어떻게 계획해야합니까?
그래서 우리는 파일 스토리지가 매우 어려운 문제임을 인정해야합니다.
4. 데이터 관계 처리
우리는 세 번째 정상을 준수하는 데이터베이스를 쉽게 계획 할 수 있으며, 이는 다수의 관계로 가득 차 있으며 Indentify 열을 Guid로 대체 할 수도 있습니다. 그러나 다수의 관계가 침수되는 2.0 시대에 세 번째 정상은 버려야 할 첫 번째 정상입니다. 다중 테이블 조인트 쿼리를 효과적으로 최소화해야합니다.
5. 데이터 인덱싱 문제
우리 모두가 알고 있듯이 인덱싱은 데이터베이스 효율 쿼리를 개선하기위한 가장 저렴하고 가장 쉬운 솔루션입니다. 그러나 높은 업데이트의 경우 업데이트 및 삭제 비용은 높고 생각할 수 없습니다. 저자는 집중 인덱스를 업데이트 할 때 완료하는 데 10 분이 걸리는 상황을 만났으므로 사이트의 경우 기본적으로 견딜 수 없습니다.
인덱싱 및 업데이트는 한 쌍의 자연적인 적입니다. 질문 a, d 및 e는 아키텍처를 수행 할 때 고려해야 할 문제이며 가장 많은 시간이 걸리는 문제 일 수도 있습니다.
6. 분산 처리
2.0 개의 웹 사이트의 경우 상호 작용이 높기 때문에 CDN이 달성 한 효과는 기본적으로 0이며 컨텐츠는 실시간으로 업데이트됩니다. 이는 정기적 인 처리입니다. 다양한 장소에서 액세스 속도를 보장하기 위해서는 큰 문제에 직면해야합니다. 즉, 데이터 동기화를 효과적으로 실현하고 다양한 장소에서 서버의 실시간 통신을 실현하는 방법이 고려해야 할 문제입니다.
7. Ajax의 장단점 분석
성공은 Ajax이고, 실패는 Ajax, Ajax는 주류 트렌드가되었으며, 갑자기 XMLHTTP를 기반으로 한 게시물을 발견했습니다. 클라이언트는 데이터를 서버에 가져 오거나 게시하고 데이터 요청을 수신 한 후 서버가 반환됩니다. 이것은 매우 일반적인 Ajax 요청입니다. 그러나 Ajax를 처리 할 때 패킷 캡처 도구를 사용하면 데이터 리턴 및 처리가 한눈에 분명합니다. 계산량이 높은 일부 AJAX 요청의 경우 계약자를 구성하여 웹 서버를 쉽게 죽일 수 있습니다.
8. 데이터 보안 분석
HTTP 프로토콜의 경우 데이터 패킷이 일반 텍스트로 전송됩니다. 어쩌면 우리는 암호화를 사용할 수 있다고 말할 수 있지만 G 문제의 경우 암호화 프로세스는 일반 텍스트 일 수 있습니다 (예 : QQ는 암호화를 쉽게 판단하고 암호화 및 암호 해독 방법을 효과적으로 작성할 수 있습니다). 사이트 트래픽이 크지 않으면 아무도 당신을 신경 쓰지 않을 것이지만 트래픽이 나오면 소위 플러그인과 소위 대량 발송은 차례로 뒤 따릅니다 (QQ의 시작시 대량 발송에서 단서를 볼 수 있습니다). 아마도 우리는 더 높은 수준의 판단이나 HTTP를 사용하여이를 달성 할 수 있다고 말할 수 있습니다. 이러한 처리를 수행하면 많은 데이터베이스, IO 및 CPU 비용이 지불됩니다. 일부 대량 방송의 경우 기본적으로 불가능합니다. 저자는 이미 바이두 공간과 QQ 공간에 대한 대량 출판을 실현할 수 있습니다. 모든 사람이 시도하는 것은 어렵지 않습니다.
9. 데이터 동기화 및 클러스터 처리 문제
데이터베이스 서버 중 하나가 압도되면 데이터베이스 기반로드 및 클러스터를 수행해야합니다. 이것은 가장 번거로운 문제 일 수 있습니다. 데이터는 네트워크 전송을 기반으로합니다. 데이터 지연은 끔찍한 문제이며 불가피한 문제입니다. 이런 식으로, 우리는이 지연 후 몇 초 이상 내내 효과적인 상호 작용을 보장하기 위해 다른 수단을 사용해야합니다. 예를 들어, 데이터 해싱, 세분화, 컨텐츠 처리 및 기타 문제.
10. 데이터 공유 채널 및 OpenAPI 트렌드
OpenApi는 Google, Facebook, MySpace에서 집 캠퍼스에 이르기까지 불가피한 트렌드가되었습니다.이 문제는 고려되고 있습니다. 보다 효과적으로 사용자를 유지하고 더 많은 관심사를 자극하고 더 많은 사람들이 가장 효과적인 개발을 수행 할 수 있도록 할 수 있습니다. 현재 효과적인 데이터 공유 플랫폼의 경우 데이터 오픈 플랫폼은 필수 불가결 한 방법이됩니다. 열린 인터페이스로 데이터 보안 및 성능을 보장하는 것은 진지하게 고려해야 할 또 다른 문제입니다.