머리말
지난 밤 두 세, 아침에 7 개 이상에 화재가 일어나 일어나 오픈 SQL 빠르게 지난 밤에 실행 된 명령의 결과를보고 점점 여전히 희미 컴퓨터를 찾을 수 있습니다. 지난 밤에 알리 구름 RDS를 업그레이드 할 수 있기 때문에, 여전히 아침에 거의 2 시간 강등을 기다리고, 알리 구름이 업그레이드 과정에서 해당 프로세스를 강화하고 이상 반응이있다. . . 비트 보링
프로젝트
이 프로젝트는 WEB, WEB-관리자, WEB-API, APP (안드로이드, IOS)으로 구분된다.
주요 개발 언어는 ASP.NET이다
MySQL 데이터베이스
아키텍처는 DDD를 사용하여 ASP.NET + EF + ORM 유니티 의존성 주입의 연습의 일부를 사용
ORM은 AutoMapper를 사용하여
사용 레디 스 캐시
Log4net 기록 로그 파일은, 단지, MongoDB의 로깅을 사용하기 시작 후 취소 약간의 시간을 보냈다.
웹 최종 사용 AngularJS와
사용자의 상태에 의해 송신 access_token은 APP와 상호 작용하여 API 층 JSON 데이터
현재 데이터베이스 층 기반 스토리지 (Repositor) 모드 달성
검색 Linq에 + 람다 방법을 채택하는 것이 가장 열망 라인에서 첫 번째 항목에서 연습하는 과정에서 요청에 구조 조정의 이상 비즈니스 및 신속한 대응을 찾아 Context.DataBase.SqlQuery에 의해 실행되는 네이티브 SQL로 쿼리의 복잡성,
다른 기술이 도입되지
APP 다량으로 현재 액세스이를 최대 동시 1,300 +
주요 압력 API는 50 개 인터페이스보다, 현재 Windwos 서버 2012에 배포 일일 평균 100W + 요청, API 비교적 큰
독립형 데이터베이스를 MySQL의 RDS에게 클라우드 알리의 5.6 버전, 10 박스 (12G), 연결 2000 번호를 사용하여, 6000 IOPS
현재 가장 큰 단일 테이블 8000W + 데이터입니다. 실제 파일 300G, APIlog 매일, API 및 비즈니스 시스템이 DBLog뿐만 아니라, 완전히 독립적 인 100W + 거기 Log4g.net 파일 생성 된 로그를 기록합니다.
알리가 현재 클라우드 부하에 사용되는 마스터 - 슬레이브 알리 구름이 CDN 10M 대역폭과 리소스 파일에 두 개의로드 응용 프로그램이 8 상자 16G입니다 구입했습니다.
WEB은 API 위에서, 주요 터미널 및 웹 관리 배경 위에 배치했다.
데이터베이스 병목 경우
최근 사용자가 많은 오류가 SQL의 이행 명령 선도, 때로는까지 중요한 포인트의 100 %, CPU의 높은 전날 밤의 시작 부분에서 10 개 이상의 + 1300 + 최대 동시 데이터베이스를 초과, 링크는 거부했다. 알리 클라우드 알람 메시지는 내가 MySQL 데이터베이스를 중지하지 않는 응용 프로그램 복구 어렵 기 때문에 즉시 정상으로 데이터베이스 다시 후 약 5 분, IIS 응용 프로그램을 중지하고 응용 프로그램을 IIS 열고 자른했다. 계란 고통을 알리 클라우드 상태 검사는 또한 비정상적인 부하를 제안하지만, 약간은 비정상적인 상태를 보여 배포 계속 계속 요청이 의아해 매우 의아해. 나는 즉시 응용 프로그램 풀 재활용, 정지를 IIS 다음 IIS 응용 프로그램 풀은 응용 프로그램을 IIS 떨어져 중지하는 가장 좋은 시간이다 다시 시작한 다음 응용 프로그램 풀을 IIS 다시 시작하라는 메시지를 보내려면 여기를 다시 시작합니다, 경우 그렇지 않으면 셰레 메티 예보입니다 어려움은 시작. 몇 분 제대로로드 디스플레이에서 건강 검진 후.
알리 클라우드는 다양한 모니터링 지표를 읽은 후, 쇼는 내가 불쾌감을 줄 알았는데, 한 시간 갑작스러운 서지 과거의 흐름을하기 시작했다,하지만 트랙은 여러 연결 요청을 발견 일반적으로하지만, 방어 보조 디스플레이 (360)는 몇 가지 공격을해야합니까 공격 횟수가 너무 많은 것이 아니라 내용과 여러 종류의 매개 변수에 대한 주요 공격 :하지만, 아마 요청의 수십, 몇 가지 간단한의 XSS 공격에 여기에 게시 데이터베이스에서 여러 요청을 당겨하는 것만으로는 충분하지 않습니다
URL / & APOS; % / 22 % 3E % 3C / 스크립트 % 3E % 3Cscript % 3Ealert () %의 3C / 스크립트 % 3E
URL / & APOS; 22 % + onMouseover와 = 경보 () + D = APOS; 22 %
URL / matrix_callback.php
? URL / 옵션의 index.php = com_fields & A, 뷰 필드 = & A, 레이아웃 및 A = 모달;리스트 % 5Bfullordering % 5D = updatexml (0x3a, CONCAT (1, MD5 (233)), 1)
나중에 데이터베이스의 위기로 발견, CPU를 여러 번 활성 및 비활성 연결의 수는 평소보다 훨씬 높은 것으로, 연결을 100 %되는했다. 현재 8000W를 통해 데이터의 테이블이 가장 큰 데이터베이스는 300W 울트라 또한 더 다스보다, 우리가 완료 0.03 초 내에 SQL 쿼리 클래스 요구 사항을 개발하는 데 필요한 보통 때, 데이터베이스 쿼리의 붕괴가 발생했습니다. 그러나 이것은 우리가 수익의 0.5 초 이내에 설정 몇 가지 큰 테이블 쿼리를 포함한다. 오늘, 0.5 초 이상 체크 확실히한다
나는 이제 약간 정상적인 시스템 작동, 그들은 그 느린 SQL 최적화의 일을했다, 느린 SQL 알리 클라우드 콘솔에서 로그를 확인, 즉시 SQL 코드를 재 작성하지 버전을 할 수 없습니다 만 인덱스에서 최적화 할 수 있습니다 . 그래서 하나의 느린 SQL에 하나 다시 실행 20 개의 초 이상에 대해가 가장 느린 도달 10 초, 해결 라인의 최대 수는 헤이 다음 형제 SQL 느슨한 작성해야한다, 더 10W 라인보다 도달 그렇지 않으면, 초 10W +의 수는 줄을 구문 분석,하지만 형제 파고 구덩이 내 울고 채워 가야 할 필요가 없습니다. 그래서 테이블 스페이스의 채택은 한 번 최적화했다되기 전에, 다시 하나 방법의 하나 인덱스를 조정에 대해 설명합니다.
지난 밤 높은 동시성, 데이터베이스에 가서 경찰에 신고하지만, 다행스럽게도 나를 경보를 충돌 포기하지 않았다. 데이터베이스 확장하기로 결정이 내려 고객과 통신. 이제 연결 16 14000 iops16000로 확장 카세트 64G.
지금 두에서 석사이며, 일부 응용 프로그램을 추가합니다
그것은 몇 시간 동안 유지한다
별도의 읽기 및 쓰기에 진행해야 할 다음으로, 대형 테이블 및 데이터베이스에 대한 분할 코드를 최적화하는 것입니다. 최선을 다하려고합니다.
그리고 수 있습니다 경우 마케팅을 기반으로하기 때문에 분산 아키텍처의 진화의 아래 진행, 우리는 다시 갈 수 없어하지만 너무 전에 시장에 올 수 없습니다
주말은 최악의 연기 상대적으로 짧은 시간에 작성되었습니다