PHP는 석가장 PHP 교육 기관에서 무료로 제공하는 시스템의 자동 실행 메커니즘에 의존하지 않습니다.

시스템이나 Yii 거래 메커니즘에 의존하지 않는 경우 인간 트리거링이 고려됩니다. 트리거는 전체 공용 페이지에 작성할 수 있지만 데이터베이스 및 WWW 서버에 대한 부담과 프로그램의 지연 문제를 고려하여 일부 실행 기능의 최적화가 필요합니다.

우선, 페이지를 클릭할 때마다 모니터링 시스템이 트리거되도록 하여 데이터베이스에 대한 부담을 고려합니다. 이때 모니터링 시스템은 먼저 작업 대기열을 업데이트해야 하는지 여부를 결정해야 합니다. 시간(작업 큐에 추가했습니다) 캐시 파일), 업데이트할 필요가 없다면 캐시 파일에 있는 실행 큐를 시간별로 정렬하고 타임아웃된 큐만 실행하면 됩니다. 그러나 시스템에 대한 부담을 줄이기 위해 큐 파일을 업데이트할 시기와 업데이트 방법을 고려해야 합니다.

제 생각에는 우선 캐시 파일이 수동으로 삭제되거나 시간 초과 후 만료될 수 있으므로 먼저 캐시 파일이 매번 존재하는지 확인(작업/사용자/유형별로 캐시를 별도로 생성)해야 합니다. , 데이터베이스를 다시 쿼리하고 캐시 파일을 생성합니다(시간 초과된 파일은 직접 실행되고, 실패한 파일은 캐시 큐에 던져집니다).

다음 단계는 각 액세스마다 캐시 파일이 있는 경우 해당 파일의 타임아웃 작업이 먼저 처리된 후 캐시 파일이 업데이트됩니다. 이때 작업 중 캐시 큐에 영향을 미치는 문제가 발생하는데, 이 경우 캐시 큐의 시작 부분이나 중간에 실행할 큐를 삽입해야 할 수도 있습니다. 기존 큐를 삭제합니다. 다음에 트리거되면 캐시 파일을 찾을 수 없으므로 최신 캐시 큐가 다시 생성됩니다.

작업 실행이 끝나면 대기열의 항목이 삭제됩니다. 대기열이 비어 있으면 쿼리가 다시 쿼리되고 대기열이 생성되므로 최소한의 액세스가 보장됩니다. 데이터베이스. 주문 접수 자동 확인 모니터링 등의 문제도 있는데, 사용자 프런트 데스크에 대한 업데이트인 경우 해당 사용자의 캐시와 해당 백엔드 관리자의 캐시를 삭제해야 한다. 사용자는 관련 직원이 주문을 검색하고 있는지 확인하기 위해 최신 상태만 볼 수 있습니다. 마찬가지로 백엔드 관리자의 수정 명령도 모든 관련 인력의 캐시 큐를 삭제해야 합니다.

위에서는 PHP를 포함하여 시스템에 의존하지 않는 PHP의 자동 실행 메커니즘을 소개했으며, PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.