PHP はシステムの自動実行メカニズムに依存しません。PHP システムの自動実行メカニズム_PHP チュートリアル

PHP はシステムの自動実行メカニズムに依存しません。PHP システムの自動実行メカニズム

はシステムに依存せず、Yii トランザクション メカニズムにも依存しません。トリガーは公開ページ全体に記述できますが、データベースやWWWサーバーへの負荷、プログラムの遅延問題を考慮すると、実行機能のある程度の最適化が必要です。

まず第一に、データベースへの負荷を考慮します。ページをクリックするたびに、監視システムがその時点でタスクキューを更新する必要があるかどうかを最初に判断する必要があります。更新する必要がない場合は、キャッシュファイル内の実行キューを時間順に並べ替えて、タイムアウトしたキューを実行するだけで済みます。ただし、システムへの負荷を軽減するために、キュー ファイルを更新するタイミングと更新方法を考慮する必要があります。

私の考えは、まず第一に、キャッシュファイルが時間の経過とともに手動で削除されるか期限切れになる可能性があり、そのたびに、まずキャッシュファイルが存在するかどうかを確認します（存在しない場合は、タスク/ユーザー/タイプごとにキャッシュを生成します）。 、データベースに再クエリを実行し、キャッシュ ファイルを生成します (タイムアウトしたファイルは直接実行され、失敗したファイルはキャッシュ キューにスローされます)。

次のステップは、アクセスごとに行われます。キャッシュ ファイルがある場合は、まずファイル内のタイムアウト タスクを処理してから、キャッシュ ファイルを更新します。このとき、動作中のキャッシュ キューへの影響という問題が発生します。この場合、実行するキューをキャッシュ キューの先頭または途中に挿入する必要がある場合があります。既存のキューを削除します。次にトリガーされたとき、キャッシュ ファイルが見つからないため、最新のキャッシュ キューが再生成されます。

タスクの実行が終了すると、キュー内のエントリが削除され、キューが空の場合は、クエリが再クエリされてキューが生成され、データベースへのアクセス数が最小限に抑えられます。また、注文受付の自動確認の監視など、ユーザーのフロントへの更新の場合、このユーザーのキャッシュと、そのユーザーが登録しているバックエンド管理者のキャッシュを削除する必要があるなどの問題もあります。関係者が注文を閲覧していることを確認するため、最新のステータスのみが表示されます。同様に、バックエンド管理者の変更命令では、すべての関連担当者のキャッシュ キューも削除する必要があります。