多くの場合、多数の部品、分散システムのインフラストラクチャにおけるこれらの支持システムをサポートするように設計された大規模な分散システム成熟音、後ろ。オートメーションシステムのインフラシステムアーキテクチャ設計に依存する、また、分散コンポーネントの連携および構成管理を含む、分散キャッシング・コンポーネント、永続ストレージ・コンポーネント、分散メッセージング・システム、検索エンジン、及びCDNシステム、負荷分散システム、運用保守などと同様に、リアルタイムコンピューティングシステム、オフラインコンピューティング・システム、分散ファイルシステム、収集システム、監視システムやデータウェアハウスを記録。ここでは主にシステム・コンポーネントのキャッシングについて話をします。
Cacheコンポーネント層
キャッシングシステムの利点：
- 読み取りおよび書き込み加速。キャッシュメモリは、Redisの、Memcacheのように、通常はいっぱいです。読むと、このようなMySQLの、はるかに優れたパフォーマンスなど、従来のストレージ層、よりメモリに直接書き込みます。単一のマシンの限られたメモリ資源に起因すると運搬能力、およびローカルキャッシュ多数の場合に使用されるが、それは分散キャッシングを出産したように、同じデータの複数のコピーが、メモリ資源の大きな浪費をもたらす、異なるノードに格納されて作ります。
- バックエンドの負荷を軽減します。並行性の高い環境では、読み取りおよび書き込み要求の数が多いデータベースに集まり、処理速度やメモリディスクは、データベース・システムの応答性からの圧力を軽減し、二つの角度、通常はデータベースの前に追加さを提供するために考慮すべき大きさの程度は明らかではありませんレベルのキャッシュ。
キャッシュシステムは、コストをもたらします：
- データの矛盾：分散環境で、同時読み取りおよび書き込みデータであり、上流の複数のアプリケーション、サービスの複数を配置することによって（可用性を確保するために、複数の部品を展開しなければならない）、同じデータ上で読んで、同時読み取りおよびデータベースレベルの書き込み完全な配列を保証するものではありません、それは読み取り要求を発行した後と言うことです完了する可能性がある（ダーティリード）
- コードのメンテナンスコストは：キャッシュを加えた後、キャッシュは、コード開発者のメンテナンスのコストが増加、処理ロジックとストレージ層に必要です。
- 運用コストとメンテナンスコスト：バッファ層が導入された、などのRedisなど。高可用性を確保するためには、高い同時実行からのショットを呼び出す必要があり、クラスタを実行する必要があります。
キャッシュの更新
キャッシュされたデータは、通常は寿命があり、それが再びアクセスしたときにリロードする必要があり、一定期間後に失敗します。キャッシュの無効化は、データソース、実際のデータがキャッシュ領域の一貫性と効率的な利用を確保するためにことを確認することです。一般的なキャッシュ更新戦略：
- / LFU / FIFOアルゴリズムLRU：キャッシュが十分でないときに3つのアルゴリズムを更新アルゴリズムを属します。ただ、要素のうちの選択されたルールは同じではありません：LRUは最長訪問の外にされていない、LFUは訪問の最小数、FIFO FIFOをなくします。適切なメモリスペースが限られている、データは、ビジネスの基本的なデータは存在しませんせずに、長期的には変更されません。例えば、いくつかの情報は、変更を許可しないように決定されています。特定のアルゴリズムによって与えられ、どのようなデータをクリーンアップするために、開発者はそのうちの一つ、比較的低い一貫性を選択することができます。
- 残業を除く：データをキャッシュするためには、手動で、このようなRedisの有効期限は、コマンドとして、有効期限を設定します。訪問は再びデータソースとセットバックキャッシュから再読み込み時が過ぎたら。開発とメンテナンスコストは、システムは、キャッシュ有効期限のAPIの多くが付属して、非常に高いではありません（Redisの有効期限が切れるような）。データの矛盾事業を許容することができる一定の期間に適したリアルタイムの一貫性を保証することはできません。
- 自動更新：データソースが更新されている場合は、キャッシュを更新するためのイニシアチブをとります。一貫性は限り正しいアップデートを決定するよう、一貫性を保証することができ、より良いです。一緒に結合された更新サービス・データ・キャッシュの更新、障害シナリオの更新プロセスのトラフィックデータのキャッシュ更新成功、キューを更新する方法を切り離すための一般的なメッセージが必要です。しかし、耐障害性を向上させるためには、通常、キャッシュの更新が失敗を避けるためにプログラムのタイムアウトをカリングと組み合わせて、キャッシュがシーンを更新することはできません。一般に、そのような取引システム、クーポンのシートの総数として、要求データの整合性に適用されます。
キャッシングシステムの一般的な問題とその解決方法
一般的に、以下のようにキャッシング機能に使用する：サービスシステムは、第1の特定のクエリ要求を開始し、バッファにデータがあるか否かを判断するとき、キャッシュが存在する場合、プロセスは直接にデータを返し、キャッシュが存在しない場合は、クエリをデータベースとデータを返します。
- キャッシュの浸透
- 説明：キャッシュが存在しないため、業務システムがクエリーを送信した場合、上記の処理によれば、最初のデータベースクエリに行き、その後、クエリキャッシュに単にそこに照会するデータ・サービス・システムになります。データは、単に存在しないので、データベースには、空を返します。これは、キャッシュの浸透です。高浸透キャッシュ同時シナリオの多数が、要求がストレート記憶層のデータベースに入る場合、バックエンド・システムはわずかに誤って粉砕します。
- 理由：要求は、データベース内の大規模な下落しているので、データは、キャッシュに存在しないため、悪意のある攻撃、故意に大量のデータを作成するには、サービスのために存在していません。
- 最適化のキャッシュの浸透のための
- ヌルオブジェクトキャッシュ：キャッシュはデータベースへのすべてのこれらの要求につながる、ダミーデータキーに格納されていないため、キャッシュの浸透が、発生します。その後のクエリがキーとキャッシュダイレクトリターンヌルの出現を要求するときに、データベースクエリの結果は、空のキーは、データベースを照会することなく、キャッシュに格納されていることができます。しかし、このプログラムはまだ高い同時実行の多数に対処することができないと明確なビジネスケースの下の有効範囲は、ないモーメントが同じ要求の多数を開始する場合、同じキャッシュを貫通していない、最初のクエリは、まだDBに浸透します。この解決策の別の欠点は、このている：データは、真に有効なキャッシュされないように、異なるオブジェクトの数をもたらす異なるキャッシュ浸透、空のオブジェクト・キャッシュは、空のキャッシュの多数の貫通たびに、メモリが無駄に多数によって占有されています。だから、このスキームのために行われる必要があります：最初、良いトラフィックフィルタリングを。要求は、クエリに直接移動していない、直接バックシステムをフィルタリングするために、ビジネスの範囲内に含まれません。第二に、短い有効期限を設定し、空のオブジェクト・キャッシュに、それが効果的かつ迅速にメモリ空間の外にクリアすることができます。
- ブルームフィルタ：ブルームフィルタは、ハッシュ関数とビットマップのデータ構造の組み合わせです。これは、実際には、ランダムなバイナリーベクターとマッピング機能の長いシリーズです。ブルームフィルタは、要素を取得するために使用することができますセットであり、それは利点のクエリ時間とスペース効率が一般的なアルゴリズムよりもはるかにありました、欠点は、特定のエラー認識率で、困難を取り除きます。ときは、ビジネスシステムのクエリ要求にない場合は、最初のブルームフィルタクエリにキーがあるかどうか、データベースは、データ内に存在しないので、キャッシュは、ダイレクトリターンヌルをチェックしませんが、存在する場合、従うことを続けますその後、データベースクエリに行っていない場合、プロセスは、まず、クエリキャッシュにキャッシュを行きます。
- 一般に、キー推奨事項について異なるダミーデータは、低い確率キーリピート要求シナリオは、それは、第2の実施形態を選択する必要があり、より高い確率の観点でヌルデータキー、キーリピート要求シナリオの限られた数の、あなたは最初のオプションを選択する必要があります。適切な場合には、ブルームフィルタとキャッシュオブジェクトを空にすることは組み合わせることも完全に可能である、ブルームフィルタは、ローカルキャッシュ実装、低メモリフットプリント、歩行のRedis / memcacheのこのリモートクエリキャッシュ・ミスでした。
- キャッシュの雪崩
- 説明：特定の期間に集中キャッシュの多数のキャッシュサーバの再起動や故障、障害は、アプリケーションサーバの雪崩を引き起こし、バックエンドデータベースに障害が発生し、その結果、（例えばDBなど）バックエンドシステムに多くの圧力をもたらすように。
- シナリオを表示されます：キャッシュサーバがハングアップし、ローカルキャッシュの失敗のピーク;キャッシュミスのホットスポットやその他の理由を
- 雪崩キャッシュ最適化プログラム：
- そのようなマスターマルチスレーブ、RedisのSentine機構などの高可用性サービス・キャッシュ層を、確実。
- そのようなNetflixのhystrixとして流量制限及び劣化の後端に依存分離アセンブリ。
- プロジェクトリソースの分離。システムアーキテクチャ全体に影響を及ぼし、バグにプロジェクトを避け、プロジェクト内に閉じ込められたという問題もあります。
- データの多くは現象を期限切れと同じ時間を防止するための集中管理の失敗、ランダムに設定キャッシュされたデータの有効期限を、キャッシングは避けてください。
- あなたができる場合は、無期限にホットデータを設定します。
- （キャッシュの内訳）ホットデータセットの失敗
- 説明：キャッシュの内訳は非常にホットキーを意味し、大規模な同時実行を運ぶ停止し、この時点までの同時大集中アクセス、現在進行中の大規模なキャッシュによって複雑キー障害が、直接のリクエストで、身に着けていた瞬間データベースの原因となるデータベースは、高並行性を運び、ダウンタイムが発生することはありませんでした。
- キャッシュの最適化の内訳：
- 現実には、データベース・サーバ上で抵抗置く圧力を粉砕することは困難であり、キャッシュは、同様の内訳はまれです。本当に、このようなケースがある場合は、最も簡単な方法は、一般的なデータキャッシュの有効期限が切れないようにすることです。
- ミューテックスを使用してください。キャッシュにデータがロックを取得し、ハングアップしたデータベースで、その結果、データベースに短時間に過度の要求を防ぐために、データベースからデータをフェッチし、ありません。
- キャッシュ底なしの問題（この問題はめったに、ここに記録されていない、Facebookの発見、非常に良いブログで書かれた記事を発生しませんします。https：//blog.csdn.net/yonggeit/article/details/72862134）
memcacheのは、分散キャッシュシステムを実現します
メモリキャッシュは、データベースへのアプリケーションのアクセスを減らすアクセス速度のアプリケーションを改善し、データベースの負荷を軽減するために、多くの大規模なサイトで使用される、高性能分散オブジェクトキャッシングシステムのオープンソースのコンテンツです。（1）、確実にするために、データクエリの複雑さのために時間がOに還元されるように、メモリに高速データを提供するために、キーと値の格納とアクセスデータを使用して、メモリキャッシュフォームを見つける能力は、メモリ内の巨大なハッシュテーブルを維持しますデータへの高性能アクセス。メモリ空間は、メモリが新しいデータを格納するためにこれ以上のスペースではないとき、memcacheのは、LRU（最低使用）アルゴリズムを使用しますが、常に限られている、アクセス頻度の低いデータは、最近ストアに部屋を作るために排除します新しいデータ。メモリキャッシュストレージサポートされるデータフォーマットは、シリアル化メカニズムオブジェクトを通して、オブジェクトは、現在の時刻エンドアプリケーションのニーズキャッシュサーバに格納されている、より高いレベルのバイナリデータに変換することができ、また、柔軟であり、バイナリコンテンツをデシリアライズすることができデータは元のオブジェクトに低減されます。memcacheのクライアントとサーバがTCP通信プロトコルの上でmemcacheのプロトコルを構成することによって行われ、プロトコルは、データ転送の2種類をサポートし、データは、2つのテキスト行と非構造化データです。テキスト行は、主にクライアントサーバからのコマンドと応答を運ぶために使用され、主に非構造化データ転送クライアントとサーバーのデータに使用されています。クライアントとサーバの間で送信され、格納されたバイトストリームの形で非構造化データので、そう使用は、特に制限はなく、ほぼ、キャッシュデータストア非常に柔軟であり、サーバが格納されている特定のコンテンツを気にする必要はなく、エンディアン。
memcacheの自体は達成するために、そのクライアントにアクセスすることにより、分散された分散キャッシュシステム、ではありません。単純な実装は、キャッシュハッシュキー、N個のキャッシュサーバの後端部、バッファの後端部の前端にマッピング要求をバランスさせることができるアクセスサーバハッシュ（キー）％N、に従って行われますサーバー。しかし、それはまた、キャッシュサーバのバックエンドがダウンしている、またはため、クラスタ圧力の大きすぎる、キャッシュサーバを追加する必要があると、キーのほとんどが再配布される、問題が発生します。非常に並行システムの場合、これはすべての要求は、バックエンドデータベースサーバーに狂った群れの氾濫なり、災害になるかもしれない、とデータベースサーバーが利用できない、それは、アプリケーション全体が使用できない、いわゆるの形成の原因となります「効果をアバランシェ。」
ある程度以上の問題点を改善することができ、一貫したハッシュアルゴリズムを使用してください。このアルゴリズムは、1997年に紙早期コンシステントハッシュ法とランダム木で提示されたとき、それはのキーの再マッピングの多数を避けるために、わずかすでに存在している可能なキーマッピング関係として変化し、キャッシュサーバを追加/削除することができます。一貫性のある原理をハッシュすることハッシュ関数は、リングに編成空間、ハッシュ関数は、範囲空間（32目-12）0と仮定される範囲であるようなものである、すなわち、32ビットのハッシュ値でありますunsigned int型、全体空間は、対応するハッシュサーバノード次いで、時計方向に従って編成ハッシュ環へのマッピングは、それらは、4台のサーバノード1、ノード2、ノード3、ノード4が存在すると仮定されています図に示される環上の位置。
次に、同じハッシュ関数を用いて、対応する環上のキーハッシュ値に対応する位置を算出します。したがって、一貫性のあるハッシュアルゴリズムが、時計回り方向に、ノード1とノード2との間の鍵配布は、そのアクセス要求はNODE2に配置され、キーとノード4ノード2との間に、アクセス要求がノード4に配置されます。、で新しいノードNODE5の増加があると仮定すると、影響を受けるだけノード2とNODE5間のキーそして、それはノード2とノード4の間でハッシュであると仮定すると、彼らはNODE5に再マッピングされ、他のキーマッピング関係はないでしょうしたがってのキーの再マッピングの多数を避け、変更されます。
もちろん、上に示した理想的な場合の知識は、リング上の各ノードは、非常に均一に分布します。通常の状況下では、より少ないノードのデータがある場合、ノードは、チルト・データ・アクセス、同じサーバーにマッピングされたキーの多数で、その結果、非常に不均一な分布とすることができます。各位置は、リング上のノードのハッシュ値に対応する、このような状況を回避するために、機構は、仮想ノード、算出したハッシュ値の複数のサーバノードを導入することができ、そのノードが仮想ノードと呼ばれ、キー同じようにマッピングするが、実際のノードのノードへの仮想からの再マッピングの過程でよりステップ。このように、仮想ノードの数が十分であれば、さらに実際のノードのごくわずか場合、キーは比較的バランスのとれた分布させることができます。