생산사고 최적화 경험

정상적인 이벤트 프로모션 이후 고객 서비스에서 잇달아 피드백을 보내기 시작했습니다. 사용자들이 입찰을 열었을 때 이미 입찰이 이루어지지 않은 상태였습니다. 처음에는 특히 관심이 많았습니다. 입찰 경쟁을 할 때도 그렇지 않습니까? 행사가 진행될수록 금리쿠폰이나 현금쿠폰을 받은 이용자들은 플랫폼이 사기라고 믿고 자원절약을 위해 고의로 사용을 막는 등 입찰에 실패하는 등 거세게 항의하는 이들이 늘었다.

분석 과정

사실 과거에도 줄지 않는 지속적인 사용자 피드백이 있었고, 이번에는 사용자 피드백을 예로 들어 샤오미를 이용해 휴대폰을 속이는 경우도 있었습니다. 너무 강해서 우리는 그것에 주의를 기울였습니다. 프론트엔드 제품은 앱, 공식 홈페이지, H5 총 3가지가 있는데, 그 중 앱이 가장 많이 사용되고, 공식 홈페이지가 두 번째로 일상생활에서는 거의 사용되지 않지만 트래픽이 급격히 증가할 것입니다. 이벤트 중(이벤트는 대개 H5 게임이 대부분이며 H5는 홍보 및 마케팅에도 편리합니다.) 세 가지 프런트엔드 제품은 모두 LV를 사용하여 두 개의 백엔드 웹서비스 서버에 로드됩니다(예: 아래 참조) 이번에는 사용자 피드백이 기본적으로 웹과 앱 측에 있으므로 이 4개의 서버를 관찰하는 데 집중하세요.

우선 네트워크 대역폭이 꽉 찼는지 의심했고, 입찰 과정에서 도구를 통해 모니터링할 네트워크 엔지니어를 찾았습니다. , 최대 대역폭 사용량은 약 70%에 불과했고, 이를 배제하기 위해 top 명령을 사용하여 두 서버의 부하를 확인했습니다. 공식 홈페이지에서는 입찰 당시에는 6~8 정도로 치솟았다가 입찰 이후에는 서서히 정상으로 돌아왔고, 앱의 두 서버는 10~12를 정점으로 한 뒤 다시 정상으로 돌아왔습니다. .

웹 서버 비즈니스 로그를 추적한 결과 데이터베이스 업데이트 계층에서 새 데이터베이스 연결을 요청할 수 없거나 데이터베이스 연결이 최대 개수를 모두 사용했다고 보고한 것으로 나타났습니다. 데이터베이스의 연결 수가 너무 적어서 조정했습니다. mysql 데이터베이스최대 연결 수는 이전의 3배입니다. 다음 입찰 시 계속해서 비즈니스 로그를 관찰하여 오류를 찾아보겠습니다. 데이터베이스 링크와 관련된 정보는 더 이상 보고되지 않지만, 많은 사용자는 여전히 입찰 중에 페이지를 열 수 없다고 보고합니다.

계속해서 웹서버를 추적하여 (ps -ef|grep httpd|wc -l) 명령어를 사용하여 httpd 연결 개수가 약 1,000개인지 확인하고, apache 설정에 설정된 최대 연결 개수를 무작위로 확인 file 1024(Apache의 기본 최대 연결 수는 256개입니다.) 입찰 과정에서 연결 수가 최대 연결 수에 도달한 것으로 나타났습니다. 많은 사용자가 입찰 중에 http 연결을 얻지 못했습니다. 프로세스가 진행되어 페이지가 응답하지 않거나 앱이 기다리고 있었습니다. 따라서 Apache 구성 파일의 최대 연결 수를 1024*3으로 조정하십시오.

입찰 과정을 계속 관찰해 보면 입찰 중에 Apache 연결 수가 여전히 2600~2800까지 치솟을 수 있다는 고객 서비스 피드백에 따르면 여전히 많은 사용자가 입찰 문제를 보고하고 있지만 약간 나아졌습니다. 이전보다 조금 있지만, 이미 목표를 잡았다가 결국 롤백했다는 사용자 피드백이 산발적으로 있습니다. 그런 다음 계속해서 데이터베이스 서버를 관찰하고 top 명령과 MySQL Workbench를 사용하여 mysql 메인 라이브러리와 슬레이브 라이브러리의 다양한 로드를 확인합니다. (아래 참조) mysql 서버 메인 라이브러리의 표시기가 해당 수준에 도달했습니다. 피크, 슬레이브 라이브러리는 거의 크지 않습니다.

코드를 추적해보니 세 끝의 비즈니스 코드는 모두 메인 라이브러리에 연결되어 있었고, 백그라운드 쿼리 비즈니스만 사용하고 있었던 것으로 나타났습니다. 슬레이브 라이브러리에서 즉시 변환이 시작되었습니다. 입찰 과정 중 쿼리를 제외하고 다른 페이지나 서비스의 모든 쿼리가 슬레이브 데이터베이스의 쿼리로 변환된 것을 확인했습니다. 마스터 데이터베이스에 대한 압력이 크게 줄어들었고 슬레이브 데이터베이스에 대한 압력이 증가하기 시작했습니다. 아래와 같습니다.

고객센터 피드백에 따르면 전환 후 입찰이 반환되는 데 거의 문제가 없으며 페이지가 열리지 않거나 열릴 수 있습니다. 입찰 과정에서 다소 완화되었으나, 일부 사용자들은 여전히 ​​이 문제를 보고하고 있습니다. 위 프로젝트의 분석 결과에 따르면

• 1 로드 중인 두 서버가 처리 제한에 도달했으며 로드하려면 서버 구성이 더 필요합니다.

• 2 mysql 메인 데이터베이스에 대한 부담이 크게 줄었지만, 슬레이브 데이터베이스에 대한 부담이 커졌습니다. 현재 마스터 1개와 슬레이브 1개를 마스터 1개로 변경해야 합니다. 여러 슬레이브 패턴 .

• 3 이러한 문제를 완전히 해결하려면 비즈니스 최적화(비즈니스 내 핫스팟 제거), 캐싱 추가 등 플랫폼 전체의 최적화를 종합적으로 고려해야 합니다. , 부분 페이징정적(Yahoo 및 Google의 프런트엔드 최적화 규칙을 사용할 수 있으며 인터넷에는 평가를 위한 많은 테스트 웹사이트가 있습니다) 등이 있습니다.

저는 이러한 상황을 바탕으로 최적화 보고서를 작성했습니다. 아래를 참조하세요.

최적화 보고서

1 배경

회사의 지속적인 사업 발전에 따라 사업 규모와 사용자 수가 급증했으며, 공식 웹사이트 PV도 초기 xxx-xxx에서 현재 xxx-xxxx로 증가했으며, APP의 활성 사용자도 증가했습니다. 따라서 이는 현재 플랫폼에도 큰 영향을 미칩니다. 기술

건축은 더 큰 과제를 안고 있습니다. 특히 최근 플랫폼의 입찰 소스가 타이트해지면 입찰을 완료하는 데 걸리는 시간이 점점 짧아지고 있습니다. 서버에 대한 부담도 증가하고 있으므로 더 많은 수의 사용자와 비즈니스 볼륨을 지원하려면 현재 시스템 아키텍처를 업그레이드해야 합니다.

2 사용자 액세스 다이어그램

현재 플랫폼에는 사용자가 접하는 세 가지 제품, 즉 플랫폼 공식 웹사이트, 플랫폼 APP, 플랫폼 작은 웹페이지가 있습니다. , 플랫폼 공식 웹 사이트 및 플랫폼 APP 압력이 상대적으로 높습니다.

3가지 문제점

입찰 경쟁 시 다음과 같은 부분에 문제가 발생합니다

1. 웹페이지나 앱이 열리지 않습니다
2. 오픈
3. 입찰 과정에서 전송이 성공한 후, 서버의 과도한 압박으로 인해 업데이트가 실패하여 다시 환불이 진행되었습니다
4. 데이터베이스 연결 수가 소진되어 결과적으로 입찰 만석 후 투자기록 추가 실패, 입찰진행 롤백

4. 분석

최근 서버 파라미터, 동시성, 시스템 로그 심층 분석을 통해 , 결론은 다음과 같습니다.

1. 플랫폼 공식 웹사이트와 플랫폼 APP의 입찰 과정에서 서버 압력이 엄청납니다. 그 중 플랫폼 APP 문제는 최대 입찰 기간 동안 더욱 두드러집니다. 단일 APP 서버의 Apache 연결 수가 2600에 가까워졌습니다. 이는 Apache의 최대 처리 용량에 거의 근접한 수치입니다

2. 데이터베이스 서버에 엄청난 압박이 가해지고 있습니다. 데이터베이스 압력은 주로 두 기간에 두드러집니다

1) 플랫폼이 활동을 할 때 공식 웹 사이트, 소규모 웹 페이지, APP에 대한 방문 횟수가 급격히 증가하여 데이터 쿼리량이 크게 증가합니다. 데이터베이스 처리 한도에 도달하면 웹 사이트 개설 속도가 느려지는 등의 문제가 발생합니다.
2) 사용자가 입찰 경쟁을 벌이는 경우 입찰 전과 입찰 중 두 단계로 나누어집니다. 입찰 전에는 입찰이 매우 빨리 마감되기 때문에 사용자는 미리 입찰 페이지를 열고 지속적으로 새로 고침을 해야 합니다. 이로 인해 입찰을 위해 경쟁하는 사용자 수가 매우 많으면 데이터베이스 연결 수가 증가합니다. 입찰 전에 모두 사용됩니다. ; 단일 구매에는 변경 및 쿼리를 위한 약 15개의 테이블이 포함될 것이며, 각 입찰에는 1천만 개의 공유가 있으며, 각각 약 100-200명이 구매하고 전체 입찰을 완료합니다. 시간은 150명의 중앙값을 기준으로 계산되며, 일정 기간 내에 데이터를 2000~
3000회 업데이트해야 하므로(업데이트만, 쿼리 제외) 이로 인해 업데이트 실패 또는 연결 시간 초과가 발생하여 사용자 입찰 및 정상적인 시스템 용량 표시에 영향을 미칠 수 있습니다.

5가지 솔루션

1. 웹 서버 솔루션

단일 사용자가 웹 서비스에 접속하는 구성도

현재 웹사이트 및 플랫폼 APP는 균형 잡힌 책임을 위해 두 가지 서비스를 사용합니다. 각 서버는 서버측 처리를 위해 Apache와 함께

설치됩니다. 각 Apache는 최대 약 2,000개의 연결을 처리할 수 있습니다. 따라서 이론적으로 현재 웹사이트나 앱은 4,000개 이상의 사용자 요청을 처리할 수 있습니다. 동시에 10,000개의 요청을 지원하려면 이를 지원하기 위해 5개의 아파치 서버가 필요하므로 현재 6개의 웹 서버가 부족합니다. 서버 업그레이드 후 접속도

2. 데이터베이스 솔루션

현재 데이터베이스 구축 계획

1) 마스터-슬레이브 별도 메인 데이터베이스의 쿼리 부담을 80% 해결합니다. 현재 플랫폼의 공식 웹사이트와 앱은 MySQL 메인 데이터베이스에 연결되어 있어 메인 데이터베이스에 대한 부담이 두 배로 늘어나고 있습니다. 서비스의 모든 쿼리를 슬레이브 데이터베이스로 마이그레이션하면 메인 데이터베이스에 대한 부담을 크게 줄일 수 있습니다.

2) 캐시 서버를 추가합니다. 슬레이브 데이터베이스 쿼리가 최대치에 도달하면 마스터-슬레이브 동기화에도 영향을 미쳐 트랜잭션에 영향을 미칩니다. 따라서 사용자가 자주 사용하는 쿼리를 캐시하여 데이터베이스에 대한 요청 부담을 줄입니다.

redis 클러스터를 구축하려면 세 개의 캐시 서버를 추가해야 합니다.

3. 기타 최적화
1) cnzz 통계에 따르면 홈페이지는 전체 웹사이트 방문의 약 15%를 차지하며, 홈페이지에서 자주 변경되지 않는 데이터입니다. 공식 웹사이트를 원활하게 열 수 있도록 개선하기 위해 정적으로 처리됩니다.

2) Apache 서버 최적화, gzip 압축 활성화, 합리적인 수의 링크 구성 등

3) 투자 과정에서 업데이트 핫스팟을 제거합니다. 목표 일정. 입찰이 성공하거나 실패할 때마다 입찰 일정을 업데이트해야 합니다. 멀티 스레드 업데이트 중에 낙관적 잠금과 같은 문제가 발생할 수 있습니다. 프로세스 중에 업데이트를 제거하고 입찰이 가득 찬 후에만 입찰 일정에 입찰 진행 정보를 저장하여 투자 프로세스 중 데이터베이스에 대한 압력을 최적화합니다.

6 서버 업그레이드 계획

1. 플랫폼의 가장 큰 부담은 데이터베이스에서 나오며, 이를 마스터 1개와 슬레이브 1개에서 마스터 4개로 변경해야 합니다. 공식 웹사이트/앱/소규모 웹페이지에서 생성된 대량의 쿼리는 가상 IP를 통해 3개의 슬레이브 데이터베이스로 분산되고, 백그라운드 관리 쿼리는 다른 슬레이브 데이터베이스로 이동됩니다. 데이터베이스는 3개의 새로운 서버를 추가해야 합니다
데이터베이스 업그레이드 후 회로도

2. 데이터 부담을 줄이기 위해 캐시를 늘려 대용량 메모리를 갖춘 2개의 새로운 캐시 서버를 추가해야 합니다

3. 사용자 액세스 요청을 분해하려면 3개의 새로운 웹 서버를 추가해야 합니다

앱에 2개의 새로운 서버를 추가해야 합니다
부담 입찰 과정에서 앱 서버에서 구성이 완료된 후 최대 2개의 새로운 서버를 추가해야 합니다.

공식 웹사이트에서 서버를 1개 더 추가해야 합니다.
공식 홈페이지도 입찰 과정에서 어려움을 겪고 있습니다. 압박으로 인해 새로운 서버가 필요합니다. 완성된 다이어그램은 다음과 같습니다.

총 8개입니다. 서버를 구입해야 하며 그 중 두 개는 대용량 메모리(64G 이상)

또는버전

으로 최적화 보고서를 다운로드하려면 클릭하세요.

참고: 모든 최적화 솔루션이 생산에 투입되면 문제가 해결되므로 입찰 경쟁을 할 필요가 없습니다.

---

저자: Pure Smile
출처: http://www.php.cn/
저작권 저작자 소유이므로 재인쇄시 출처를 밝혀주세요

위 내용은 생산사고 최적화 경험의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!