ダミーのキャッシュ

「ティーポット」の目を通してキャッシュ：


キャッシュは統合システムです。 したがって、異なる角度では、結果は実領域と虚領域の両方に存在する可能性があります。 待っているものと本当に持っているものの違いを理解することは非常に重要です。

状況を丸ごとスクロールしてみましょう。

Tl; dr：アーキテクチャにキャッシュを追加するとき、キャッシュは負荷のかかったシステムを不安定にする手段になり得ることを明確に認識することが重要です。 記事の最後をご覧ください。

為替レートを返すデータベースにアクセスできるとします。 rates.example.com/?currency1=XXX¤cy2=XXXに問い合わせると、それに応じてコースのプレーンテキスト値を取得します。 たとえば、データベースへの1000クエリごとに1ユーロセントかかります。

それで、私たちのウェブサイトでドルからユーロへの為替レートを表示したいと思います。 これを行うには、コースを取得する必要があります。そのため、このサイトでは、便利に使用できるAPIラッパーを作成しています。

たとえば、次のように：

<?php //      :) function get_current_rate($currency1, $currency2) { $api_host = "http://rates.example.com/"; $args = http_build_query(array("currency1"=>$currency1, "currency2"=>$currency2)); $rate = @file_get_contents($api_host."?".$args); if ($rate === FALSE) { return $rate; } else { return (float) $rate; } } 

そして、適切な場所のテンプレートに次のようなものを挿入します。

  {{ get_current_rate("USD","EUR")|format(".2f") }} USD/EUR 

（まあ、あるいは<?=sprintf(".2f", get_current_rate("USD","EUR"))?>ですが、これは最後の世紀です）。

Naive実装は、考えられる最も単純なことを行います。各ユーザーからリモートシステムを要求し、その答えを直接使用します。 これは、現在、私たちのページのユーザーによる1000回のビューごとに、さらに多くの費用がかかっていることを意味します。 それは見えるだろう-ペニー。 しかし、プロジェクトは成長しています。毎日1,000人のユーザーが毎日サイトにアクセスし、それぞれ20ページを閲覧しています。これは既に月額6ユーロです。これにより、サイトは無料から最も安価な専用仮想サーバーへの支払いに完全に匹敵します。

Ma下キャッシュ

一般に、この情報がそれほど頻繁に必要とされない場合、ページの更新ごとに各ユーザーのコースを尋ねる必要があるのはなぜですか？ リフレッシュレートを、たとえば5秒に1回に制限してみましょう。 ページからページに移動するユーザーには新しい番号が表示され、1000分の1の金額が支払われます。

すぐに言ってやった！ いくつかの行を追加します。

 <?php function get_current_rate($currency1, $currency2) { $cache_key = "rate_".$currency1."_".$currency2; //   https://cloud.google.com/appengine/docs/php/memcache/ $memcache = new Memcache; $memcache->addServer("localhost", 11211); $rate = $memcache->get($cache_key); if ($rate) { return $rate; } else { $api_host = "http://rates.example.com/"; $args = http_build_query(array("currency1"=>$currency1, "currency2"=>$currency2)); $rate = @file_get_contents($api_host."?".$args); if ($rate === FALSE) { return $rate; } else { $memcache->set($cache_key, (float) $rate, 0, 5); return (float) $rate; } } } 

これはキャッシュの最も重要な側面です。 最後の結果を保存します。

そして出来上がり！ このサイトは再び無料になります...月末まで、外部システムから4ユーロの口座を発見するまで。 もちろん、6ではありませんが、大幅な節約が期待できます。

幸いなことに、外部システムを使用すると、見越し額を確認できます。ここでは、出席率のピーク時に正確に5秒ごとに100以上の要求のバーストが表示されます。

これが、キャッシュの2番目の重要な側面であるクエリ重複排除を導入した方法です。 実際のところ、値が古くなったら、結果がキャッシュにあるかどうかを確認してから新しい値を保存するまでに、すべての着信要求は実際に外部システムへの要求を同時に実行します。

memcacheの場合、これは、たとえば次のように実装できます。

 <?php function get_current_rate($currency1, $currency2) { $cache_key = "rate_".$currency1."_".$currency2; $memcache = new Memcache(); $memcache->addServer("localhost", 11211); while (true) { $rate = $memcache->get($cache_key); if ($rate == "?") { sleep(0.05); } else if ($rate) { return $rate; } else { //  ,     ,    if ($memcache->add($cache_key, "?", 0, 5)) { $api_host = "http://rates.example.com/"; $args = http_build_query(array("currency1"=>$currency1, "currency2"=>$currency2)); $rate = @file_get_contents($api_host."?".$args); if ($rate === FALSE) { return $rate; } else { $memcache->set($cache_key, (float) $rate, 0, 5); return (float) $rate; } } } } } 

そして最後に、消費は予想と同等でした-5秒で1リクエスト、費用は1か月あたり2ユーロに削減されました。

なぜ2ですか？ 何千人もキャッシュなしで6つありましたが、すべてをキャッシュしましたが、3回しか減少しませんでしたか？ はい、早めに計算する価値がありました... 5秒に1回= 1分あたり12 = 1時間あたり72 = 1か月あたり576 = 1か月あたり1万7,000人で、誰もがスケジュールに沿っているわけではなく、夜遅くに見ている奇妙な人がいます...何百ものコールの代わりに、ピークが1つだけあり、静かな時間に、以前と同様に、ほとんどすべてのコールのリクエストが通過します。 それでも、最悪の場合でも、スコアは31×86400÷5 = 5.36ユーロである必要があります。

そこで、別の側面に出会いました。キャッシュはを助けますが、負荷を排除しません 。

しかし、私たちの場合、人々はプロジェクトに来て立ち去り、ある時点でブレーキについて不平を言い始めます。数秒間ページがフリーズします。 また、午前中にサイトがまったく応答しない場合があります... サイトのコンソールを表示すると、午後に追加のインスタンスが起動されることがあります。 同時に、クエリの実行速度はリクエストごとに5〜15秒に低下します-これが起こるためです。

読者のための練習：前のコードを注意深く見て、理由を見つけてください。

はい、はい、はい。 もちろん、これはif ($rate === FALSE)ブランチにあります。 外部サービスがエラーを返した場合、ロックを解除しませんでした...という意味で「？」 記録されたままで、誰もがそれが陳腐化するのを待っています。 これは簡単に修正できます。

  if ($rate === FALSE) { $memcache->delete($cache_key); return $rate; } else { 

ちなみに、このレーキは単なるキャッシュではなく、分散ロックの一般的な側面です。デッドロックを回避するために、ロックを解除してタイムアウトを設定することが重要です。 「？」を追加した場合 寿命がないと、外部システムとの通信の最初のエラーですべてがフリーズします。 残念ながら、memcacheは分散ロックを作成するための良い方法を提供しません。行レベルのロックを備えた本格的なデータベースを使用する方が優れていますが、それは単にこのレーキを踏んだために必要な叙情的な余談でした。

そのため、問題を修正しましたが、何も変わっていません。ブレーキがまだ時々起動しました。 注目に値するのは、彼らが技術システムに関する外部システムからのニュースレターと時間的に一致したことです...

さあさあ...ちょっと休憩して、今集めたもの、キャッシュができることを振り返りましょう。

1. 最後の既知の結果を覚えておいてください。
2. 結果がまだまたは不明である場合のクエリの重複排除。
3. エラーが発生した場合に正しいロック解除を確認してください。

気づいた？ キャッシュは、エラーの場合にポイント1〜2を提供する必要があります。 最初は、これは明らかなようです。何が起こったのか分からず、1つの要求が落ち、次の要求が更新されます。 しかし、次のものもエラーを返すとどうなりますか？ そして次は？ 10件のリクエストがあり、最初のリクエストがロックを取得し、結果を取得しようとしましたが、落ちてしまいました。 次のものはチェックします-そのため、ブロッキングも値もありません。結果を求めます。 左折しました。 だから皆のために。 まあ、愚かなこと！ 良い10が来て、1つが試されました-みんな落ちました。 そして、次のものをもう一度試してみましょう！

そのため、キャッシュはしばらくの間否定的な結果を保存できなければなりません。 単純な初期の仮定は、本質的に0秒間ネガティブな結果を保存することを意味します（ただし、この否定を既に待っているすべての人に送信します）。 残念ながら、Memcacheの場合、ゼロレイテンシの実装は非常に問題があります（厄介な読者の宿題として残します。アドバイス： CASメカニズムを使用します。はい、AppEngineでMemcacheとMemcachedを使用できます）。

負の値を1秒の寿命で保存するだけです。

 <?php function get_current_rate($currency1, $currency2) { $cache_key = "rate_".$currency1."_".$currency2; $memcache = new Memcache(); $memcache->addServer("localhost", 11211); while (true) { $flags = FALSE; $rate = $memcache->get($cache_key, $flags); if ($rate == "?") { sleep(0.05); } else if ($flags !== FALSE) { //   ,   ,   , //       ,  false. return $rate; } else { if ($memcache->add($cache_key, "?", 0, 5)) { $api_host = "http://rates.example.com/"; $args = http_build_query(array("currency1"=>$currency1, "currency2"=>$currency2)); $rate = @file_get_contents($api_host."?".$args); if ($rate === FALSE) { //          $memcache->set($cache_key, $rate, 0, 1); return $rate; } else { $memcache->set($cache_key, (float) $rate, 0, 5); return (float) $rate; } } } } } 

今ではそれだけで 、落ち着くことができますか？ どんなに。 私たちが成長している間、私たちの最愛の外部サービスも成長していました、そしてある時点で、それは時々遅くなり、一瞬でも反応し始めました...そして驚くべきこと-それとともに、私たちのウェブサイトも遅くなり始めました！ そして再び皆のために！ しかし、なぜですか？ エラーが発生した場合、すべてをキャッシュし、エラーを記憶し、それにより、待機中の全員を一度に解放しますか？

...そしてここにあります。 もう一度コードをよく見てください： file_get_contents()が許可する限り、外部システムへのリクエストは実行されます。 リクエストの実行時には他の全員が待機しているため、キャッシュが廃止されるたびに、すべてのスレッドがメインスレッドの実行を待機し、到着したときにのみ新しいデータを受信します。

まあ、待機する代わりに、 memcache->add ...の周りの条件にelse{}ブランチをmemcache->addます。本当です。最後の既知の値を返す必要がありますよね？ 結局、新しい情報がない場合、古い情報を受信することに同意したことを正確にキャッシュします。 そのため、もう1つのキャッシュ要件があります。要求が1つだけ遅くなるようにします。

すぐに言ってやった：

 <?php function get_current_rate($currency1, $currency2) { $cache_key = "rate_".$currency1."_".$currency2; $memcache = new Memcache(); $memcache->addServer("localhost", 11211); while (true) { $flags = FALSE; $rate = $memcache->get($cache_key, $flags); if ($rate == "?") { sleep(0.05); } else if ($flags !== FALSE) { return $rate; } else { if ($memcache->add($cache_key, "?", 0, 5)) { $api_host = "http://rates.example.com/"; $args = http_build_query(array("currency1"=>$currency1, "currency2"=>$currency2)); $rate = @file_get_contents($api_host."?".$args); if ($rate === FALSE) { //      ,    //  .  ,   . $memcache->set($cache_key, $rate, 0, 1); return $rate; } else { //      _stale_ ,     // - : , ,    //    . $memcache->set("_stale_".$cache_key, (float) $rate); $memcache->set($cache_key, (float) $rate, 0, 5); return (float) $rate; } } else { //    ,      — //     ,      . //    ,   false,    . return $memcache->get("_stale_".$cache_key); } } } } 

それで、私たちは再び勝ちました。外部サービスが遅くなっても、1ページしか遅くなりません...つまり、平均応答時間が短縮されたように、ユーザーはまだ少し不満です。

注：通常のPHPはデフォルトでセッションをファイルに書き込み、同時リクエストをブロックします。 この動作を回避するには、read_and_closeパラメーターをsession_startに渡すか、必要なすべての変更が行われた後、session_closeでセッションを強制的に閉じます。そうしないと、1つのページが遅くなるのではなく、1人のユーザー：値を更新するスクリプトが同じからの別の要求によってセッションの開始をブロックするためユーザー。 AppEngineで実行されると、memcacheのセッションストレージはデフォルトで有効になります。つまり、ロックなしであるため、問題はそれほど目立ちません。

したがって、ユーザーはまだ不満です（ああ、これらのユーザー！）。 サイトで最も時間を費やしている人は、これらの短いハングにまだ気づいています。 そして、彼らはこれがめったに起こらないという事実にまったく満足しておらず、単に幸運ではありません。 この場合、要件をさらに厳しくする必要があります 。 要求は応答を待つべきではありません 。

この質問の定式化では何ができますか？ できること：

1. 「 応答後の実行 」トリックを実行してみてください。つまり、値を更新する必要がある場合は、スクリプトの残りの実行後にこれを行うハンドラーを登録します。 アプリケーションと実行環境に依存します。 最も信頼できる方法はfastcgi_finish_request ()を使用することfastcgi_finish_request () 。これにはphp- fastcgi_finish_request ()サーバー構成が必要です（したがって、AppEngineでは使用できません）。
   
   
2. 個別のスレッドで更新を行います（つまり、 pcntl_fork()実行するか、 system()または他の何かを介してスクリプトを実行します）-再び、サーバーで機能し、場合によってはセキュリティをあまり気にしない共有ホスティングサービスでも機能します。しかし、もちろん、妄想的なセキュリティのサービスでは機能しません。つまり、AppEngineは適切ではありません。
   
   
3. キャッシュを更新するために常に実行されているバックグラウンドプロセスがあります。プロセスは、キャッシュ内の値が古くなっているかどうかを所定の頻度で確認する必要があります。また、存続期間が終了し、キャッシュの存続中に値が必要になった場合、更新します。 この点については、為替レートで貧弱なサイトにうんざりし、より楽しいものに移るときに少し後で説明します。

実際のところ、データを常にホットな状態に維持することは、ほんの数行のPHPコードよりも少し複雑なタスクです。そのため、単純なケースでは、ある種のリクエストが定期的に「考え直される」という事実に耐える必要があります（ランダムではなく、いくつか;つまり、 randomではなく、 任意です。 タスクを試すには、このアプローチの適用性が常に重要です！

そのため、データプロバイダーは成長していますが、すべての顧客がハブを読み取るわけではないため、正しいキャッシングを使用せず（まったく使用しない場合）、ある時点で膨大な数の要求を発行し始めます。彼はゆっくりとだけでなく、 非常にゆっくりと答え始めます。 数十秒以上。 もちろん、ユーザーはF5キーを押すかページをリロードできることをすぐに発見し、すぐに表示されます-外部の応答を単に待っているがリソースを消費するプロセスがハングし始めたため、ページのみが再び無料の制限に達し始めました。

他の副作用の中でも、時代遅れのコースを示すケースがより頻繁になっています。 [うーん...一般的に、私たちのケースについてではなく、陳腐化が肉眼で見えるより複雑なものについて話していると想像してください:)実際には、単純な場合でも、そのような完全に明白な妨害に気付くユーザーがいるはずです]。
何が起こるか見てください：

1. リクエスト1が来ました。キャッシュにデータがないため、トークン「？」を追加しました。 5秒間、コースに行きました。
2. 1秒後、リクエスト番号2が届き、マーカー「？」が表示され、古いレコードからデータが返されました。
3. 3秒後、リクエスト番号3が到着し、マーカー「？」が表示され、古い状態が返されました。
4. 1秒後、マーカー「？」 要求1がまだ応答を待機している場合でも非推奨です。
5. さらに2秒後、リクエスト番号4が到着し、マーカーはありません。新しいマーカーを追加して、コースに進みます。
6. ...
7. 要求1が応答を受信し、結果を保存しました。
8. リクエストXが到着し、最初の質問のキャッシュから現在の回答を受け取りました（そして、いつその回答を得ましたか？リクエストの時点で、または回答の瞬間に？-誰も知りません...）。
9. リクエスト番号4は回答を受け取り、結果を保存しました-そして、この回答がより新しいか古いかは明確ではありません...

もちろん、ここではstream_context_create ini_set("default_socket_timeout")使用して必要なタイムアウトを設定するか、 stream_context_create使用するstream_context_createます。そのため、別の重要な側面があります 。 動作に対する一般的な解決策はありませんが、原則として、キャッシュ時間は計算時間より長くする必要があります。 計算時間がキャッシュの有効期間を超える場合、 キャッシュは適用されません 。 これはもはやキャッシュではなく、信頼できるストレージに保存されるべき事前計算です。

それでは、小計を要約しましょう。 常識では、キャッシュは次のことを行います。

1. 既知の回答に対するほとんどの要求を置き換えます。
2. 高価なデータのリクエスト数を制限します。
3. クエリ時間をユーザーに見えなくします。

ただし、実際には：

1. キャッシュライフウィンドウからの一部のリクエストを保存された値に置き換えます（たとえば、メモリ不足や贅沢なリクエストなどにより、キャッシュはいつでも失われる可能性があります）。
2. 要求の数を制限しようとしています（ただし、発信要求の頻度の制限を特別に実装しなければ、「一度に最大1つの発信要求」タイプの特性のみを提供することが実際に可能です）。
3. クエリの実行時間は一部のユーザーにのみ表示されます（さらに、「幸運なユーザー」は決して均等に分散されていません）。

キャッシュは、保存されたデータの「一時性」を意味するため、キャッシングシステムは、一般的にライフタイムとデータを保存するリクエストの事実を自由に処理できます。

• キャッシュはいつでも失われる可能性があります。 実行ロックマーカーも「？」です。 同じキャッシュサーバー上にあるセッションに何か（多くの場合、サイトへの最後のアクセスの時間）を保存しながら、さらに1万人のユーザーがサイトを歩き回ると、失われる場合があります。 トークンが失われた（「キャッシュポイズニング」）後、次のリクエストは再びキャッシュ内の値を更新するプロセスを開始します。
• リモートシステムでリクエストが高速に実行されるほど、キャッシュポイズニングの場合に重複排除されるリクエストが少なくなります。

したがって、単にキャッシュを適用するだけで、保留中のアクションの鉱山を置くことがありますが、これは確かに爆発します-しかし、今ではなく、将来、決定にはるかに費用がかかります。 システムのパフォーマンスを計算するときは、肯定的な応答をキャッシュすることによる実行時間の短縮を考慮せずに考慮することが重要です。

最も単純なケースを考えてみましょう。

• 穏やかな状態のシステムを見ると、平均実行時間は0.05秒です。
• 結論：1つのプロセスで1秒あたり20のリクエストを処理できます。つまり、1秒あたり100のリクエストでは5つのプロセスで十分です。
• ただし、リクエストの更新時間が2秒に増加した場合のみ、次のようになります。
• 1つのプロセスが更新中です（2秒以内）。
• この2秒間で利用できるプロセスは4つだけで、1秒あたり80リクエストです。

また、負荷が高い場合、キャッシュはポイズニングされ、リクエストは5秒間キャッシュされませんが、1秒間のみキャッシュされます。つまり、2つのリクエストが常にビジー状態になります（最初のリクエストを実行し、 ）、メンテナンスの残りの容量は1秒あたり60リクエストに削減されます。 つまり、1分あたり6000リクエスト（平均に基づく）の有効容量は、3600に急落します。 つまり、毎分5,000リクエストでポイズニングが発生すると、負荷が5,000から3,000に低下するまで、システムは不安定になります。 つまり、トラフィックの急増は、長期的なシステムの不安定を引き起こす可能性があります。

これは、新機能を備えたニュースレターの後に、ユーザーの波がほぼ同時に届く場合に、特に素晴らしく見えます。 定期的なマーケティングhabraeffectの一種。

これはすべて、キャッシュを使用できない、または使用することが有害であることを意味するものではありません！ , , , .