Webアプリケーションでのデータのキャッシュ。 memcachedを使用する

ユーリ・クラスノシュチェック（Delphi LLC、Dell）

キャッシングについて少し説明します。 一般に、キャッシュはあまり面白くないので、取得してキャッシュするので、memcachedの非常に詳細な情報についても説明します。







キャッシングについては、オムノニウムトルシメーターの製造工場を開発することから始めましょう。 これは標準的なタスクであり、主なことは退屈な顔をして「工場の開発に典型的なスキームを適用します」と言うことです。



一般に、工場生産に近い、つまり 問題はどこから来たのですか？ 工場は非常に高速で動作し、トルシメーターを製造します。 また、各デバイスのキャリブレーションには、きれいなオムノニウムが必要です。このオムノニウムを遠くに飛ばす必要があります。したがって、このオムノニウムを抽出する過程で、デバイスはキャリブレーションされず、実際、すべての生産が停止します。 そのため、工場の近くに倉庫を建設しています。 しかし、それは無料ではありません。







用語に移ります。 1つの言語でキャッシュについて説明するために、かなり確立された用語があります。







ソースはoriginと呼ばれます。 倉庫量、すなわち キャッシュサイズ- キャッシュ サイズ 。 希望の形状のサンプルのために倉庫に行くと、ストアキーパーは私たちが要求したものを提供します-それはキャッシュ ヒットと呼ばれ、彼が言うなら：「そのようなことはありません」、それはキャッシュミスと呼ばれます。







データ-私たちのオムノニウム-は文字通り新鮮さを持っています -それは新鮮さです。 新鮮さがどこでも使われています。 データが本来の新鮮さを失うとすぐに、 古い データになります 。







データの有効性をチェックするプロセスは検証と呼ばれ、データが使用不可であり、ウェアハウスから破棄されると言う瞬間を無効化と呼びます。







スペースが残っていないときにこのような不快な状況が発生する場合がありますが、新鮮なオムノニウムを保管する方がよいため、何らかの基準で最も古いオムノニウムを見つけて捨てます。 これはエビクションと呼ばれます。







スキームは、ブラウザからバックエンドまで、チェーン内に多くのリンクがあるようなものです。 質問：どこにキャッシュしますか？ 実際、どこでも絶対にキャッシュする必要があります。 そして、あなたがそれを望むかどうかにかかわらず、データはキャッシュされます。 質問は、むしろ、どのようにこれに影響を与えることができますか？







まず、適切なキャッシュデータを見つける必要があります。 何らかのキャッシュを実行しているという事実により、チェーンにはさらに別の中間リンクがあり、キャッシュが物事を高速化する必要はありません。 データを適切に選択しなければ、せいぜい速度に影響せず、最悪の場合、システム全体の生産プロセスが遅くなります。



頻繁に変更されるデータをキャッシュすることは意味がありません。 頻繁に使用されるデータをキャッシュする必要があります。 データのサイズ、つまり ブルーレイメモリにムービーをキャッシュすることにした場合-クールです、非常にすばやくメモリから取り出しますが、ほとんどの場合、ネットワーク経由でどこかでポンプする必要があり、非常に遅くなります。 このような大量のデータは、配信の速度と釣り合っていません。 そのようなデータをメモリに保持することは意味がありません。 ディスクは保持できますが、速度を比較する必要があります。



ところで、プログラミングのレイテンシーをグーグルで検索できます。 そこで、サイトでは、CPUキャッシュへのアクセス速度、データセンターでのラウンドトリップパケットの送信速度など、すべての標準遅延が非常に適切に提供されます。 そして、あなたが何かを装ってデザインするとき、それは見るのが良いです。それはどれくらいの時間とそれがかかるかと比較してそこに非常にはっきりと示されています。



これらはキャッシュ用の既製のレシピです：







これらは関連するHTTPヘッダーです。







いくつかについて少しお話しますが、実際にはそれについて読む必要があります。 基本的に、Webでキャッシュに影響を与えることができる唯一の方法は、これらのヘッダーを正しくインストールすることです。







以前に使用された有効期限。 データに新鮮さを設定し、文字通り「このコンテンツはその日付まで有効です」と言います。 そして今、このヘッダーを使用する必要がありますが、フォールバックとしてのみ、 新しいヘッダーがあります。 繰り返しになりますが、このチェーンは非常に長く、このヘッダーのみを理解する何らかの種類のプロキシ（Expires）を使用できます。



キャッシュを担当する新しいヘッダーはCache-Controlです。







ここでは、鮮度、検証メカニズム、および無効化メカニズムの両方をすぐに指定し、これがパブリックデータであるかプライベートであるかを示し、それらをキャッシュする方法を指定できます...



ところで、キャッシュなしは非常に興味深いです。 名前で言うと、「キャッシュはどこでも、キャッシュなし」と言う場合は好きなようにキャッシュしてください。 ただし、このコンテンツのデータを使用するたびに、たとえばフォームがあり、このフォームで送信すると、キャッシュされたすべてのデータが関連していない場合は、再確認する必要があると言います。



一般に、コンテンツのキャッシュをオフにしたい場合、「ストアなし」と言います。







これらの「キャッシュなし」、「ストアなし」は、認証フォーム、つまり 認証されていないユーザーをキャッシュしたくないので、奇妙になったり、見すぎたり、誤解が生じたりすることはありません。 ところで、このCache-Controlについて：no-cache ...たとえば、Cache-Controlヘッダーがサポートされていない場合、その動作をシミュレートできます。 ヘッダーの有効期限を取得して、過去の日付を設定できます。



Content-Lengthを含むこれらのヘッダーはすべて、キャッシュに関連しています。 一部のキャッシングプロキシは、Content-Lengthがない場合、単にキャッシュさえしない場合があります。



実際、memcached、つまりバックエンド側のキャッシュにアクセスします。







繰り返しますが、さまざまな方法でキャッシュできます。 データベースからいくつかのデータを取得し、コードで何かを行いますが、実際にはキャッシュです。何度も再利用するために一度取得しました。 コード内のある種のコンポーネント、フレームワークを使用できます。 キャッシング用のこのコンポーネントが必要なのは、製品に合理的な制限が必要だからです。 それはすべて、ある種のオペレーティングエンジニアが来て、「製品の要件を説明してください」と言っているという事実から始まります。 そして、あなたは彼に、それが非常に多くのRAM、非常に多くのディスクスペース、そしてそのような予測されるアプリケーションの成長であることを伝える必要があります...したがって、何かをキャッシュする場合、制限が必要です。 簡単に提供できる最初の制限は、キャッシュ内の要素の数によるものだとします。 しかし、異なるサイズの要素がある場合は、一定量のメモリでそれを閉じます。 つまり 任意のキャッシュサイズを言います-これは最も重要な制限であり、最も重要な境界です。 このようなことができるライブラリを使用します。







さて、または、一般的にスタンドアロンの別個のキャッシングサービスを使用します。 なぜある種の個別のキャッシングサービスが必要なのですか？ ほとんどの場合、バックエンドはそれほどモノリシックではなく、1つのプロセスです。 いくつかの異なるプロセス、いくつかのスクリプトがあり、個別のキャッシングサービスがある場合、つまり、バックエンドインフラストラクチャ全体がこのキャッシュを参照し、そこからのデータを使用できます。 これは素晴らしい。



2番目のポイント-成長する機会があります。 たとえば、1つのサービスを投入し、現金を使い果たし、別のサービスを投入します。 当然、これは無料ではありません。 「そして今日、私たちはスケーリングすることを決めました」は起こりえません。 事前にそのようなことを計画する必要がありますが、別のキャッシングサービスがそのような機会を提供します。







キャッシュはまた、ほぼ無料で可用性を提供します。 キャッシュにデータがあり、このデータをキャッシュから取得しようとしているとします。 何かが私たちのどこかに落ち、何も落ちなかったふりをして、キャッシュからデータを提供します。 この時点で何らかの形で解除される可能性があり、可用性もあります。



実際、memcachedに到達しました。 Memcachedは典型的なnoSQLです。







noSQLキャッシングが優れているのはなぜですか？



構造によって。 通常のハッシュテーブルがあります。 待ち時間が短くなります。 memcachedなどのキーと値のストレージの場合、遅延が少ないだけでなく、大規模な表記では、ほとんどの操作が複雑になります。これは1つの定数です。 したがって、何らかの一時的な制約があると言えます。 たとえば、リクエストには10​​ミリ秒しかかかりません。 これらの待ち時間に基づいて何らかの契約に同意することもできます。 これはいいです。



ほとんどの場合、恐ろしいものは何でもキャッシュします-CCSとJSが混ざった写真、レンダリングされたフォームの一部、その他のもの。 どのデータが明確ではないため、キーと値の構造により、非常に簡単に保存できます。 account.300.avatarがあることを記すことができます。これは写真であり、そこで機能します。 この例では、300がアカウントIDです。



重要な点は、キーと値のnoSQLがある場合、ストレージコード自体が単純化されることです。最悪の場合は、何らかの方法でデータを台無しにしたり失ったりするからです。 データを処理するコードが少ないほど、データを損なう可能性が低くなるため、単純な構造の単純なキャッシュが適しています。







memcached Key-Valueについて。 有効期限データで指定できます。 一定量のメモリでの作業をサポートしました。 16ビットフラグには任意の値を設定できます-memcachedに対して透過的ですが、ほとんどの場合、一部のクライアントからmemcachedを使用します。おそらく、このクライアントは既にこれらの16ビットを取得しています。 彼は何とかそれらを使用します。 そのような機会があります。



memcachedはvikshinsのサポート、つまり スペースが不足すると、最も古いデータをプッシュし、最新のデータを追加します。 または、「データを削除しない」と言うことができます。新しいデータを追加すると、メモリ不足エラーが返されます-これは「-M」フラグです。







memcachedには構造化された統一されたドキュメントはありません。プロトコルの説明を読むことをお勧めします。 基本的に、Googleで「memcachedプロトコル」と入力すると、これが最初のリンクになります。 プロトコルは、コマンドの形式だけでなく、送信するもの、応答するものを記述します...このコマンドは、このように動作する、つまり いくつかのコーナーケースがあります。



コマンドの概要：







get-データを取得します。



設定/ 追加/ 削除/ 置換 -このデータを消去する方法、つまり：

• 設定は、保存、新規追加、または置換です。
  
  
• addは、そのようなキーがない場合にのみ追加することです。
  
  
• 削除 -削除;
  
  
• replace-そのようなキーが存在する場合のみ置換し 、そうでない場合はエラー。
  
  

シャードがある環境です。 クラスターがある場合、これは一貫性を保証しません。 ただし、1つのインスタンスでは、これらのコマンドで一貫性をサポートできます。 そのような制約を構築することは、多かれ少なかれ可能です。



prepend / append-これを取得して、データの前にピースを挿入するか、データの後にピースを挿入します。 それらは、memcached内にあまり効率的に実装されていません。 新しいメモリが割り当てられたままになり、それらとsetの間に機能的な違いはありません。



保存するデータにある種の有効期限を示すことができます。その後、タッチコマンドを使用してこのデータに触れることができ、このキーに特に寿命を延ばします。 彼は削除されません。



増分コマンドと減分コマンドがあります-incr / decrです。 それは次のように機能します：文字列としていくつかの数字を消去してから、 incrと言って値を与えます。 まとめると。 デクリメントは同じですが、減算します。 興味深い点があります。たとえば、memcachedの観点からは2-3 = 0です。 アンダーフローは自動的に処理されますが、負の数を作成することはできません。いずれにしても、ゼロが返されます。







何らかの一貫性を持たせることができる唯一のコマンドはcasです （これはアトミックな比較およびスワップ操作です）。 2つの値を比較し、これらの値が一致する場合は、データを新しい値に置き換えます。 比較する値は内部のグローバルカウンターです

memcached、そこにデータを追加するたびに、このカウンターが増加し、キーと値のペアが何らかの値を取得します。 getsコマンドを使用してこの値を取得し、 casコマンドで使用できます。 このチームには、通常の原子が抱えている問題と同じ問題があります。 特にmemcachedにはコマンドの実行順序が保証されていないため、多くのレイズ条件を興味深いものにすることができます。



Memcachedには「-C」キーがあり、 casをオフにします。 つまり どうしたの このカウンタはキーと値のペアから消えます。「-C」キーを追加すると、各値が64ビットカウンタであるため、8バイトを節約できます。 値が小さい場合、キーは小さいため、大幅に節約できます。



memcachedを効率的に使用するには？







多くのセッションで動作するように設計されています。 多くは数百です。 つまり 数百から始まります。 そして事実は、RPS（1秒あたりのリクエスト）の観点から、2〜3セッションを使用してmemcachedから多くを得ることはありません。 それを揺るがすには、多くの接続が必要です。 セッションは長時間実行する必要があります。memcached内にセッションを作成するのはかなり費用のかかるプロセスであるため、一度フックするとそれだけなので、このセッションを維持する必要があります。



リクエストはバッチでなければなりません。 要求をバッチで送信する必要があります。 getコマンドでは、いくつかのキーを転送する機会があります。これを使用する必要があります。 つまり getとkey-key-keyと言います。 他のチームにはそのような可能性はありませんが、バッチを実行できます。 いくつかのコマンドを使用して、クライアント側でローカルにリクエストを作成し、このリクエスト全体を送信できます。



memcachedはマルチスレッドですが、あまりマルチスレッドではありません。 彼女は内部に多くのロックを持ち、非常にアドホックなので、4つ以上のスレッドが内部で非常に強い競合を引き起こします。 信じる必要はありません。すべてを自分で再確認する必要があります。ライブシステムでライブデータを使用して実験する必要がありますが、非常に多くのスレッドが機能しません。 いろいろ試して、「-t」キーで最適な数値を選択する必要があります。



memcachedはUDPをサポートしています。 これは、facebookによってmemcachedに追加されたパッチです。 facebook memcachedの使用方法-すべてのセットを作成します。 すべてのデータ変更はTCP経由で行われ、UDP経由で取得されます。 また、データ量が非常に大きい場合、パケットサイズが小さいため、UDPが大幅に向上することがわかります。 彼らは、グリッドを通してより多くのデータを送り出すことに成功しています。



incr / decrについて説明しました-これらのコマンドは、バックエンドの統計を保存するのに理想的です。







HighLoadの統計はかけがえのないものです。 統計がなければ、特定の問題の原因、原因、発生場所を理解することができません。30分間の作業の後、「システムが奇妙に動作する」ためです。次に統計。 統計が多いほど良いです。 そして、原則として、問題があることを理解するためには、統計が必要です。 たとえば、バックエンドは30ミリ秒でページを返し、40で開始し、見た目で区別することはできませんが、パフォーマンスは4分の1低下しました-ひどいです。



Memcached自体も統計をサポートしています。インフラストラクチャで既にmemcachedを使用している場合、memcached統計は統計の一部です。したがって、そこを見て、バックエンドがキャッシュを正しく使用しているか、データを適切にキャッシュしているかを確認する必要があります。



まず、各チームにヒットとミスがあります。 キャッシュに目を向け、データが提供されたとき、このコマンドのヒットが増加しました。 たとえば、削除キーを作成しました。削除ヒット1があるため、コマンドごとに削除します。 当然、ヒットは100％である必要があり、ミスはまったくありませんでした。 見なければなりません。 非常に高いミス率を持つことができるとしましょう。 最も一般的な理由は、間違ったデータを単純に調べていることです。 キャッシュに少しのメモリを割り当て、キャッシュを絶えず再利用するようなオプションがあるかもしれません。 データを追加し、追加し、追加しました。ある時点で、最初のデータがキャッシュから落ち、それらを追いかけて、それらはもう存在していません。 私たちは他の人の後に登りました、彼らもそこにいません。 そして、それがすべてを変える方法です。 つまり バックエンド側から、memcachedの負荷を減らす必要があります。または、「-m」パラメーターで使用できるメモリの量を増やすことができます。



立ち退きは非常に重要なポイントです。 私が話している状況は、立ち退き率が非常に高いという事実から明らかです。 これは、適切なデータの有効期限が切れていないときの量です。 それらは新鮮で、良いものはキャッシュから排出され、その後、立ち退きの回数が増えます。



バッチを使用すべきだと言った。 batch'aのサイズの選択方法は？ 特効薬はありません。これをすべて実験的に選択する必要があります。 すべては、インフラストラクチャ、使用するネットワーク、インスタンスの数、およびその他の要因に依存します。 しかし、非常に大きなバッチがある場合は...バッチを実行していて、他のすべての接続が立っており、バッチが完了するのを待っていると想像してください。 これは飢starと呼ばれます-断食、すなわち 残りの支持者が飢えていて、脂肪分の多いものが完了するのを待っているとき。 これを回避するために、memcached内には強制的にバッチ実行を中断するメカニズムがあります。 これは非常に無作法に実装され、キー「-R」があります。これは、1つの接続を連続して実行できるチームの数を示します。 デフォルト値は20です。また、統計を見ると、conn_yields統計が何らかの理由で非常に高い場合、memcachedを噛むことができるよりも多くのバッチを使用することを意味し、この接続のコンテキストを頻繁に強制的に切り替える必要があります。 ここでは、「-R」キーを使用してバッチのサイズを増やすか、バックエンド側からそのようなバッチを使用しないことができます。







また、memcachedはメモリから最も古いデータを消去すると述べました。 だから、私は嘘をついた。 これは実際にはそうではありません。 Memcachedには、これらのアトムを破棄するためにこのメモリを効果的に使用するための独自のメモリマネージャがあります。 スラブ（文字通り「スタブ」）を持つように設計されています。 これは、メモリの一部に対してメモリマネージャをプログラミングする際に確立された用語です。 大きなメモリチャンクがあり、それがページに分割されています。 memcached内のページはMBなので、複数のMBのKey-Valueデータをそこに作成することはできません。 これは物理的な制限です-memcachedは複数ページのデータを作成できません。 そして、最終的には、すべてのページがチャンクに分割されます。これは、96、120の写真に表示されているものです-特定のサイズです。 つまり 96 MBのピースがあり、次に32から1 MBまでの1.25倍の120のピースがあります。 . - , memcached ( + + + + , memcached ( 24-50 )), . head. - , memcached head. .., , , tail, .



, memcached . list recently used , .. - , — 96 120 120- .. memcached , .







slab'. memcached — , Telnet' , stats, Enter, «». stats slabs, stats items — , , stats slabs , , stat' — , memcached , stat items — , , . , , .







. , memcached — . ? - . , . availability, — , , -, , Round Robin', . - , , memcached, .



? . , - - , . , .



latency. 90% — round trip, .. memcached — , . , , .. . , memcached , . , , , memcached ? , , memcached — .



, , , , , — .







— consistent hashing ring. つまり ? , , int32, . だから — , - - . , . , , .. , , , , — , .



. , -, . , . — , — , , , . , , , — .



memcached consistancy - , .. availability, , - cas' - .

» cachelot@cachelot.io

» http://cachelot.io/

— HighLoad++ Junior .



また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。 私たちの教科書にはすでに30以上のユニークな資料があります。 接続してください！



— " - ", , HighLoad++ Junior .