大規模分散ウェブサイトアーキテクチャ: 分散システムにおけるキャッシュの応用

キャッシュは分散システムの重要なコンポーネントであり、主に高同時実行性およびビッグデータシナリオでのホットデータアクセスのパフォーマンス問題を解決するために使用されます。高性能で高速なデータアクセスを提供します。

[[252441]]

1. キャッシュの概要

1.1 キャッシュの原理

（１）データの書き込み・読み取り速度が速いストレージ（デバイス）

（２）アプリケーションに最も近い場所にデータをキャッシュする。

（３）ユーザーに最も近い場所にデータをキャッシュする。

1.2 キャッシュの分類

分散システムでは、キャッシュが広く使用されています。展開の観点から見ると、キャッシュアプリケーションにはいくつかの側面があります。

（１）CDNキャッシュ

（２）リバースプロキシキャッシュ

（３）分散キャッシュ

（４）ローカルアプリケーションキャッシュ

1.3 キャッシュメディア

一般的なミドルウェア: Varnish、Ngnix、Squid、Memcache、Redis、Ehcache など。

キャッシュコンテンツ: ファイル、データ、オブジェクト。

キャッシュメディア: CPU、メモリ (ローカル、分散)、ディスク (ローカル、分散)

1.4 キャッシュ設計

キャッシュ設計では、次の問題を解決する必要があります。

（１）何をキャッシュするか？

キャッシュする必要があるデータ: 1. ホットデータ。 2. 静的リソース

（２）キャッシュはどこにありますか？

CDN、リバースプロキシ、分散キャッシュサーバー、ローカルマシン（メモリ、ハードディスク）

（３）キャッシュする方法は？

有効期限ポリシー

1. 固定時間: たとえば、指定されたキャッシュ時間は 30 分です。

2. 相対時間: たとえば、過去 10 分間にアクセスされていないデータなど。

同期メカニズム

リアルタイム書き込み。（押す）

非同期更新。（押したり引いたり）

2. CDNキャッシュ

CDN は主に、ユーザーに最も近い場所にデータをキャッシュするという問題を解決します。一般的には、静的リソースファイル (ページ、スクリプト、画像、ビデオ、ファイルなど) をキャッシュします。国内ネットワークは非常に複雑であり、事業者間のネットワークアクセスは非常に遅くなります。オペレータ間または地域間のユーザーアクセスの問題を解決するために、CDN アプリケーションを重要な都市に展開できます。ユーザーが必要なコンテンツを近くで入手できるようにし、ネットワークの混雑を軽減し、ユーザーのアクセス応答速度とヒット率を向上させます。

2.1 CND原則

CDN の基本原理は、さまざまなキャッシュサーバーを広く利用し、ユーザーアクセスが比較的集中しているエリアやネットワークに分散させることです。ユーザーが Web サイトにアクセスすると、グローバルロードテクノロジーを使用してユーザーのアクセスが最も近い稼働中のキャッシュサーバーに誘導され、キャッシュサーバーがユーザーの要求に直接応答します。

（１）CDNアプリケーションを導入する前に

ネットワーク要求パス:

リクエスト: ローカルネットワーク (LAN) -> オペレータネットワーク -> アプリケーションサーバールーム

応答: アプリケーションサーバールーム -> オペレータネットワーク -> ローカルネットワーク (LAN)

複雑なネットワークを考慮しない場合、ユーザーアクセス操作には 3 つのノードと、要求から応答までの 6 つのステップが必要です。

（２）CDNアプリケーションを導入した後

ネットワークパス:

リクエスト: ローカルネットワーク (LAN) -> オペレータネットワーク

回答：オペレータネットワーク——》ローカルネットワーク（ローカルエリアネットワーク）

複雑なネットワークを考慮しない場合、ユーザーアクセス操作には 2 つのノードと、要求から応答までの 2 つのステップが必要です。

CDN サービスを導入していない場合と比較すると、ノードが 1 つ、アクセスステップが 4 つ削減されます。システムの応答速度が大幅に向上します。

2.2 CDNの利点と欠点

（１）メリット（百度百科より）

1. ローカルキャッシュの高速化: 特に多数の画像や静的ページを含むサイトのアクセス速度が向上します。

2. ミラーサービス：異なるオペレータ間の相互接続によって発生するボトルネックの影響を排除し、オペレータ間のネットワーク高速化を実現し、異なるネットワークのユーザーが良好なアクセス品質を得られることを保証します。

3. リモートアクセラレーション：リモートアクセスユーザーは、DNS ロードバランシング技術に基づいてキャッシュサーバーを自動的に選択し、最速のキャッシュサーバーを選択して、リモートアクセスを高速化できます。

4. 帯域幅の最適化: サーバーのリモートミラーキャッシュサーバーを自動的に生成します。リモートユーザーがサーバーにアクセスすると、サーバーはキャッシュサーバーからデータを読み取ります。これにより、リモートアクセスの帯域幅が削減され、ネットワークトラフィックが共有され、元のサイトの WEB サーバーの負荷が軽減されます。

5. クラスター攻撃対策: 広範囲に分散された CDN ノードとノード間のインテリジェントな冗長性メカニズムにより、ハッカーの侵入を効果的に防ぎ、さまざまな DDoS 攻撃による Web サイトへの影響を軽減しながら、優れたサービス品質を確保できます。

（２）デメリット

1. 動的リソースキャッシュではリアルタイムのパフォーマンスに注意する必要があります。

解決策: 主に静的リソースをキャッシュし、動的リソースに対してはマルチレベルキャッシュまたは準リアルタイム同期を確立します。

2. データの一貫性とリアルタイムのパフォーマンスを確保するにはバランスが必要です。

解決する：

キャッシュの有効期限を設定します (1 時間、最終的な一貫性)。

データバージョン番号。

2.3 CNDアーキテクチャリファレンス

「雲州ビデオCDNシステム」より抜粋

2.4 CNDテクノロジーの実践

現在、中小規模のインターネット企業は、総合的なコストを考慮してサードパーティの CDN サービスをレンタルするのが一般的ですが、大規模なインターネット企業は自社構築またはサードパーティの組み合わせ方式を採用しています。たとえば、Taobao が最初にサードパーティの CDN を使い始めたとき、トラフィックが非常に大きくなると、サードパーティ企業は CDN トラフィックをサポートできなくなり、Taobao は最終的に独自の CDN を構築する方法を採用しました。

Taobao CDN は以下のとおりです (インターネットから):

3. リバースプロキシキャッシュ

リバースプロキシとは、Web サイトのサーバールームにプロキシサーバーを展開して、負荷分散、データキャッシュ、セキュリティ制御などの機能を実現することを指します。

3.1 キャッシュの原則

リバースプロキシはアプリケーションサーバールームに配置され、WEB サーバーへのすべての要求を処理します。ユーザーが要求したページがプロキシサーバーにキャッシュされている場合、プロキシサーバーはキャッシュされたコンテンツをユーザーに直接送信します。バッファがない場合、まずデータを取得するために WEB サーバーにリクエストが送信され、その後、ローカルにキャッシュされてからユーザーに送信されます。 Web サーバーへのリクエスト数を減らすことで、Web サーバーの負荷が軽減されます。

リバースプロキシは通常、静的リソースをキャッシュし、動的リソースを処理のためにアプリケーションサーバーに転送します。一般的に使用されるキャッシュアプリケーションサーバーには、Varnish、Ngnix、Squid などがあります。

3.2 イカの例

Squid リバースプロキシは通常、静的リソースのみをキャッシュし、動的プログラムはデフォルトではキャッシュされません。 WEB サーバーから返された HTTP ヘッダータグに基づいて静的ページをキャッシュします。最も重要な HTTP ヘッダータグは 4 つあります。

Last-Modified: ページがいつ変更されたかをリバースプロキシに通知します

有効期限: リバースプロキシにページをキャッシュから削除するタイミングを指示します。

Cache-Control: リバースプロキシにページをキャッシュするかどうかを指示します

プラグマ: 実装固有の命令を含めるために使用され、最も一般的に使用されるのはプラグマ: no-cacheです。

Squid リバースプロキシアクセラレーションウェブサイトの例

（1）DNSポーリング技術により、クライアントのリクエストはSquidリバースプロキシサーバーの1つに分散され、処理されます。

（２）このSquidがユーザーの要求したリソースをキャッシュしていた場合、要求されたリソースをユーザーに直接返します。

（3）それ以外の場合、このSquidはキャッシュされていないリクエストを隣接するSquidとバックエンドWebサーバーに送信し、設定されたルールに従って処理します。

（4）これにより、バックエンドウェブサーバーの負荷が軽減されるだけでなく、ウェブサイト全体のパフォーマンスとセキュリティも向上します。

3.3 プロキシキャッシュの比較

一般的なプロキシキャッシュには、Varnish、Squid、Ngnix などがあります。簡単な比較は次のとおりです。

（1）VarnishとSquidはプロフェッショナルなキャッシュサービスであり、nginxはサードパーティのモジュールのサポートを必要とします。

（２）Varnishはメモリキャッシュを使用してメモリとディスク間の頻繁なファイルスワップを回避し、Squidよりもパフォーマンスが高くなります。

（３）Varnishはメモリキャッシュなので、CSS、JS、小さな画像などの小さなファイルのサポートに優れています。バックエンドの永続キャッシュには Squid または ATS を使用できます。

（4）Squidは、さまざまな静的ファイルをキャッシュするのに適した包括的かつ強力なアプリケーションです。通常、負荷分散のためにフロントエンドに HAProxy または nginx がインストールされ、複数のインスタンスが実行されます。

(5) Nginxはキャッシュにサードパーティのモジュールncacheを使用しており、そのパフォーマンスは基本的にVarnishと同等です。一般的にリバースプロキシとして使用され、簡単なキャッシュを実装できます。

4. 分散キャッシュ

CDN (リバースプロキシキャッシュ) は、主に静的ファイルまたはユーザーが要求したリソースのキャッシュの問題を解決します。データソースは通常、静的ファイルまたは動的に生成されたファイル (キャッシュヘッダー識別子付き) です。

分散キャッシュは、主としてユーザーが頻繁にアクセスするデータのキャッシュを指し、データソースはデータベースです。一般的に、ホットデータにアクセスし、データベースの負荷を軽減する役割を果たします。

現在、分散キャッシュ設計は、大規模な Web サイトアーキテクチャにおいて不可欠なアーキテクチャ要素となっています。よく使用されるミドルウェアには、Memcache や Redis などがあります。

4.1 メモリキャッシュ

Memcache は、メモリ内に統合された巨大なハッシュテーブルを維持する、高性能な分散メモリオブジェクトキャッシュシステムです。画像、動画、ファイル、データベース検索結果など、さまざまな形式でデータを保存できます。簡単に言えば、データがメモリに呼び出され、その後メモリから読み取られるため、読み取り速度が大幅に向上します。

Memcache の機能:

（１）物理メモリをキャッシュ領域として使用し、サーバー上で独立して実行できる。各プロセスの最大サイズは 2G です。より多くのデータをキャッシュしたい場合は、より多くの memcache プロセス (異なるポート) を開くか、分散 memcache を使用して異なる物理マシンまたは仮想マシンにデータをキャッシュすることができます。

（２）キーバリューストレージを使用する。これは、データ項目のクエリ時間の計算量をO(1)にすることができる単一インデックス構造化データ編成形式である。

（３）シンプルプロトコル：Telnet経由で直接memcachedサーバー上のデータにアクセスできるテキストベースのプロトコルです。複数のキャッシュがこのプロトコルを参照するのは簡単で便利です。

（4）libeventに基づく高性能通信：libeventはC言語で開発されたプログラムライブラリです。BSDシステムのkqueueやLinuxシステムのepollなどのイベント処理機能をインターフェースにカプセル化しており、従来のselectに比べてパフォーマンスが向上しています。

（５）内蔵メモリ管理方式：すべてのデータはメモリに保存されるため、ハードディスクアクセスよりも高速です。メモリがいっぱいになると、未使用のキャッシュは LRU アルゴリズムによって自動的に削除されます。ただし、データの災害復旧の問題は考慮されていません。サービスを再起動すると、すべてのデータが失われます。

（6）分散型：各memcachedサーバーは相互に通信せず、独立してデータにアクセスし、情報を共有しません。サーバーには分散機能がありません。分散デプロイメントは memcache クライアントに依存します。

（7）キャッシュ戦略：Memcachedのキャッシュ戦略はLRU（最近最も使われていない）有効期限戦略です。 memcached にデータ項目を保存する場合、キャッシュの有効期限を指定できます。デフォルトでは有効期限は永続的です。 memcached サーバーに割り当てられたメモリが不足すると、期限切れのデータが最初に置き換えられ、その後に最近使用されていないデータが置き換えられます。 LRU では、memcached は遅延有効期限戦略を使用します。保存されたキー/値のペアが期限切れかどうかは監視されません。代わりに、キー値を取得するときにレコードのタイムスタンプをチェックして、キー/値のペアのスペースが期限切れかどうかを確認します。これにより、サーバーの負荷を軽減できます。

4.1.1 Memcacheの仕組み

MemCache のワークフローは次のとおりです。

（1）まずクライアントのリクエストデータがmemcachedにあるかどうかを確認します。そうであれば、データベースに対して操作を実行せずに、要求データを直接返します。

（２）要求されたデータがmemcachedに存在しない場合は、データベースをチェックし、データベースから取得したデータをクライアントに返し、そのデータのコピーをmemcachedにキャッシュします（memcachedクライアントはこれに責任を負わず、プログラムによって実装される必要があります）。

（３）データベースが更新されるたびに、一貫性を保つためにmemcached内のデータも更新されます。

（4）memcachedに割り当てられたメモリ領域が使い果たされると、LRU（Least Recently Used）戦略と有効期限戦略が使用されます。期限切れのデータが最初に置き換えられ、次に最近使用されていないデータが置き換えられます。

4.1.2Memcache クラスター

memcached は「分散型」キャッシュサーバーと呼ばれていますが、サーバー側には「分散型」機能はありません。各サーバーは完全に独立した分離されたサービスです。 memcached の配布はクライアントプログラムによって実現されます。

memcached クラスターからキー値を保存/取得する場合、memcached クライアントプログラムは特定のアルゴリズムに基づいてどのサーバーに保存するかを計算し、そのサーバーにキー値を保存します。

データへのアクセスは 2 つのステップで行われます。最初のステップはサーバーの選択、2 番目のステップはデータへのアクセスです。

分散アルゴリズム（一貫性ハッシュ）:

サーバー選択アルゴリズムには、剰余に基づいて配分を計算するものと、ハッシュアルゴリズムに基づいて配分を計算するものの 2 つがあります。

剰余アルゴリズム:

まず、キーの整数ハッシュ値を求め、それをサーバーの数で割り、その余りに基づいてアクセスサーバーを決定します。

利点: 計算が簡単で効率が高い。

デメリット: memcached サーバーを追加または削減すると、ほぼすべてのキャッシュが無効になります。

ハッシュアルゴリズム: (一貫性ハッシュ)

まず、memcached サーバーのハッシュ値を計算し、それを 0 から 2 の 32 乗までの円上に分配します。次に、同じ方法を使用して、データを格納するキーのハッシュ値を計算し、円にマッピングします。最後に、データがマップされている場所から時計回りに検索を開始し、最初に見つかったサーバーにデータを保存します。数が 2 の 32 乗を超えてもサーバーが見つからない場合は、データは最初の memcached サーバーに保存されます。

memcached サーバーを追加すると、円上にサーバーを追加する反時計回り方向の最初のサーバーのキーのみが影響を受けます。

一貫性ハッシュアルゴリズム: 剰余アルゴリズムを追加するときにノードヒット率が大幅に低下する問題を解決します。理論上、物理ノードを挿入すると、平均して仮想ノード数/2 のノードデータのヒット率に影響します。

4.2レディス

Redis は、オープンソース (BSD ライセンス) の、メモリベースのマルチデータ構造ストレージシステムです。データベース、キャッシュ、メッセージングミドルウェアとして使用できます。文字列、ハッシュ、リスト、セット、範囲クエリを含むソート済みセット、ビットマップ、ハイパーログ、地理空間インデックス半径クエリなど、複数の種類のデータ構造をサポートします。

組み込みのレプリケーション、Lua スクリプト、LRU エビクション、トランザクション、さまざまなレベルのディスク永続性を備えており、Redis Sentinel と自動パーティション分割を通じて高可用性を提供します。

4.2.1 Redisの一般的なデータ型

1. 文字列

よく使用されるコマンド: set、get、decr、incr、mget。

アプリケーションシナリオ: 文字列は、Memcache のキー値保存方法と同様に、最も一般的に使用されるデータ型です。

実装方法: 文字列はデフォルトで redis に文字列として保存され、redisObject によって参照されます。 incr や decr などの演算に遭遇すると、計算のために数値型に変換されます。このとき、redisObject の encoding フィールドは int です。

2. ハッシュ

よく使用されるコマンド: hget、hset、hgetall。

アプリケーションシナリオ: ユーザー情報オブジェクトデータの保存を例に挙げます。

実装：

Redis ハッシュに対応する値は、実際には内部的には HashMap です。実際には、ここには 2 つの異なる実装があります。

(1) ハッシュメンバーが比較的少ない場合、Redisは実際のHashMap構造を使用する代わりに、1次元配列のような方法を使用してハッシュメンバーをコンパクトに格納し、メモリを節約します。対応する値 redisObject は zipmap としてエンコードされます。

（２）メンバー数が増えると、自動的に実HashMapに変換され、エンコーディングはhtになります。

3. リスト

よく使用されるコマンド: lpush、rpush、lpop、rpop、lrange。

適用シナリオ:

Redis リストには多くのアプリケーションシナリオがあり、Redis の最も重要なデータ構造の 1 つでもあります。たとえば、Twitter のフォローリストやファンリストは、Redis のリスト構造を使用して実装できます。

実装：

Redis リストは双方向リンクリストとして実装されており、逆方向の検索とトラバーサルをサポートし、操作が簡単になります。ただし、追加のメモリオーバーヘッドが発生します。送信バッファキューを含む Redis 内の多くの実装でも、このデータ構造が使用されます。

4. 設定

よく使用されるコマンド: sadd、spop、smembers、sunion。

適用シナリオ:

Redis セットによって提供される関数は、リストの関数と似ています。特別なのは、セットが自動的に重複を削除できることです。リストデータを保存する必要があり、重複したデータを望まない場合は、set が適切な選択です。 Set は、メンバーがセットコレクション内にあるかどうかを判断するための重要なインターフェイスも提供しますが、これは list では提供できないものです。

実装：

set の内部実装は、値が常に null となる HashMap です。実際にはハッシュを計算することで重複を素早く削除します。これが、セットがメンバーがセット内にあるかどうかを判断できる理由です。

5. ソートされたセット

一般的なコマンド: zadd、zrange、zrem、zcard;

使用シナリオ:

Redis ソート済みセットの使用シナリオは、セットの使用シナリオと似ています。違いは、セットは自動的に順序付けされないのに対し、ソートされたセットはユーザーが追加の優先度 (スコア) パラメータを提供することでメンバーをソートでき、順序どおりに挿入され、つまり自動的にソートされることです。順序付けられた重複のないセットのリストが必要な場合は、ソートされたセットのデータ構造を選択できます。例えば、Twitter の公開タイムラインは、公開時間をスコアとして保存しておき、取得時に時間順に自動的に並び替えられるようにすることができます。

実装：

Redis のソートセットは、データの保存と順序を確保するために、内部的に HashMap と SkipList を使用します。 HashMap にはメンバーからスコアへのマッピングが含まれ、スキップリストにはすべてのメンバーが格納されます。ソートは、HashMap に保存されているスコアに基づいて行われます。スキップリスト構造を使用すると、比較的高い検索効率を実現でき、実装も比較的簡単です。

4.2.2 Redis クラスター

（１）keepalivedによる高可用性ソリューションの実装

切り替えプロセス:

1. マスターに障害が発生すると、VIP はスレーブに移行します。スレーブのkeepalivedはredisにslaveof no oneを実行するように通知し、サービスの提供を開始します。

2. マスターが起動すると、VIP アドレスは変更されません。マスターの keepalived は、スレーブ IP ホストのスレーブを実行し、そこからデータの同期を開始するように redis に通知します。

3. など

マスターとスレーブの両方が同時にダウンしています。

1. 計画も考慮もされていないため、通常はそのような問題は発生しません

2. 計画的な再起動。再起動する前に、操作および保守手段を使用してメインデータベースデータを SAVE DUMP します。順序に注意してください:

1. いずれかのマシン上のすべての Redis をシャットダウンします。すべてのマスターを別のマシンに切り替える必要があります (マスターとスレーブの両方が 1 台のマシンに存在するマルチインスタンス展開)。マシンをシャットダウンする

2.マスター上のRedisサービスを順番にダンプする

3. メインを閉じる

4. メインプロセスを開始し、データがロードされるのを待ちます。

5. 始める

6. DUMPファイルを削除する（再起動の読み込みが遅くなるのを防ぐため）

（２）Twemproxyを使用したクラスタソリューションの実装

Twitter によってオープンソース化されたプロキシの C バージョンは、memcached と redis の両方をサポートしています。最新バージョンは 0.2.4 で、現在継続的に開発中です。 https://github.com/twitter/twemproxy。 Twitter は主に、フロントエンドとキャッシュサービス間のネットワーク接続の数を減らすためにこれを使用します。

機能: 高速、軽量、バックエンドキャッシュサーバーの接続数を削減、構成が簡単、ケタマ、モジュラ、ランダム、一般的なハッシュシャーディングアルゴリズムをサポート。

ここでは、keepalived を使用して、プロキシの単一ポイント問題を解決するための高可用性マスタースレーブソリューションを実装します。

アドバンテージ：

1. クライアントにとって、Redis クラスタは透過的であり、クライアントはシンプルで、動的な拡張が可能です。

2. プロキシが単一ポイントであり、一貫性のあるハッシュ処理を実行する場合、クラスタノードの可用性検出においてスプリットブレイン問題は発生しません。

3. 高性能、CPU集約型、Redisノードクラスタは複数のCPUリソースの冗長性を備えており、追加の機器を必要とせずにRedisノードクラスタに展開できます。

4.3 MemcacheとRedisの比較

（1）データ構造：Memcacheはキー値ストレージのみをサポートしますが、Redisはキー値、ハッシュ、リスト、セット、zsetなど、より多くのデータ型をサポートします。

（2）マルチスレッド：Memcacheはマルチスレッドをサポートしていますが、redisはシングルスレッドをサポートしています。 CPU 使用率の点では、Memcache は Redis よりも優れています。

（3）永続性：Memcacheは永続性をサポートしていませんが、Redisはサポートしています。

（4）メモリ使用率：memcacheは高く、redisは低い（圧縮を使用するとmemcacheよりも高くなる）。

（５）有効期限戦略：memcacheが有効期限切れ後に削除されない場合、次回データを取得するときに問題が発生します。 Redis には、キャッシュされたデータをクリアするための専用スレッドがあります。

5. ローカルキャッシュ

ローカルキャッシュとは、アプリケーション内のキャッシュ、つまり標準の分散システムを指し、通常は複数レベルのキャッシュで構成されます。ローカルキャッシュはアプリケーションに最も近いキャッシュであり、通常はハードディスクまたはメモリにデータをキャッシュできます。

5.1 ハードディスクキャッシュ

データをハードディスクにキャッシュし、読み取り時にハードディスクから読み取ります。原理は、ローカルファイルを直接読み取ることで、ネットワーク転送の消費を削減し、ネットワーク経由でデータベースを読み取るよりも高速化することです。速度要件はそれほど高くないが、大量のキャッシュストレージが必要なシナリオで使用できます。

5.2 メモリキャッシュ

データをローカルメモリに直接保存し、プログラムを通じてキャッシュオブジェクトを直接維持するのが、最も高速なアクセス方法です。

6. キャッシュアーキテクチャの例

責任分担:

CDN: HTML、CSS、JS などの静的リソースを保存します。

リバースプロキシ: 動的リソースと静的リソースを分離し、ユーザーが要求した静的リソースのみをキャッシュします。

分散キャッシュ: ホットデータをデータベースにキャッシュします。

ローカルキャッシュ: アプリケーションディクショナリなどのよく使用されるデータをキャッシュします。

リクエストプロセス:

（1）ブラウザはクライアントへのリクエストを開始し、CDNにキャッシュがある場合はリクエストを直接返します。

（２）CDNにキャッシュがない場合はリバースプロキシサーバーにアクセスします。

（３）リバースプロキシサーバにキャッシュがある場合は、直接返される。

（4）リバースプロキシサーバーにキャッシュや動的リクエストがない場合は、アプリケーションサーバーにアクセスします。

（５）アプリケーションサーバーはローカルキャッシュにアクセスする。キャッシュがある場合は、プロキシサーバーに戻ってデータをキャッシュします。 (動的リクエストはキャッシュされません)

（６）ローカルキャッシュにデータがない場合、分散キャッシュが読み取られ、アプリケーションサーバーに返されます。アプリケーションサーバーはデータをローカルキャッシュに (部分的に) キャッシュします。

（７）分散キャッシュにデータがない場合、アプリケーションはデータベースのデータを読み取り、分散キャッシュに格納します。

7. データの一貫性

キャッシュは、データが永続化される前のノードです。これは主に、データアクセスを高速化し、応答時間を短縮するために、ホットデータをユーザーに最も近いメディアまたはアクセス速度が速いメディアに配置するために使用されます。

キャッシュは永続データのコピーであるため、データの不整合の問題は避けられません。これにより、ダーティリードまたはデータ障害が発生する可能性があります。データの不整合は通常、ネットワークの不安定性またはノード障害によって発生します。データ操作の順序に応じて、主に次のような状況があります。

7.1 シナリオの紹介

（１）まずキャッシュに書き込み、次にデータベースに書き込む

以下のように表示されます。

キャッシュへの書き込みは成功したが、データベースへの書き込みが失敗したか、応答が遅延した場合、次回のキャッシュの読み取り（同時読み取り）時にダーティリードが発生します。

（２）まずデータベースに書き込み、次にキャッシュに書き込む

以下のように表示されます。

データベースへの書き込みは成功したが、キャッシュへの書き込みが失敗した場合、次にキャッシュを読み取るとき (同時読み取り) には、データを読み取ることができなくなります。

（３）非同期キャッシュリフレッシュ

これは、分散シナリオなど、キャッシュへの同時書き込みが不可能な場合や非同期リフレッシュ (改善策) が必要な場合など、データベース操作と書き込みキャッシュが同じ操作ステップにないことを意味します。

この場合、データの書き込みとキャッシュの更新の適時性が主に考慮されます。たとえば、ユーザーのデータアクセスに影響を与えないようにキャッシュを更新する頻度などです。

7.2 解決策

最初のシナリオ:

このキャッシュの書き方自体が間違っています。最初に永続メディアに書き込み、次にキャッシュに書き込むように変更する必要があります。

2番目のシナリオ:

（１）キャッシュへの書き込みのレスポンスに基づいて判断する。キャッシュ書き込みが失敗した場合は、データベース操作をロールバックします。この方法はプログラムの複雑さを増すため、お勧めできません。

（２）キャッシュを使用する場合、キャッシュの読み取りが失敗した場合は、まずデータベースが読み取られ、その後キャッシュに書き戻されます。

3番目のシナリオ:

（１）まず、どのようなデータがそのようなシナリオに適しているかを判断する。

（２）経験値に基づいて合理的なデータ不整合時間とユーザーデータの更新間隔を決定する。

7.3 その他の方法

（１）タイムアウト：合理的なタイムアウト期間を設定する。

（２）更新：一定範囲（時間とバージョン番号に基づく）内のデータを定期的に更新する。

上記は簡略化されたデータの読み取りと書き込みのシナリオであり、実際には次のように分割されます。

（１）キャッシュとデータベース間の一貫性

（２）複数レベルのキャッシュ間の一貫性

（３）キャッシュコピー間の一貫性。

8. キャッシュの高可用性

業界には2つの理論があります。最初のキャッシュセットは、データを一時的に保存し、高可用性を必要としないキャッシュです。 2 番目のタイプのキャッシュは、徐々に重要なストレージメディアへと進化し、高い可用性が求められます。

私の意見では、キャッシュの可用性が高いかどうかは実際のシナリオによって異なります。重要な点は、それがバックエンドデータベースに影響を与えるかどうかです。

具体的な意思決定の根拠は、クラスターの規模 (データ、キャッシュ)、コスト (サーバー、運用、保守)、システムパフォーマンス (同時実行性、スループット、応答時間) の総合的な評価に基づく必要があります。

8.1 解決策

キャッシュの高可用性は、通常、分散とレプリケーションによって実現されます。分散データキャッシュが実装され、レプリケーションを使用してキャッシュデータノードの高可用性が実現されます。アーキテクチャ図は次のとおりです。

このうち、分散ではコンシステントハッシュアルゴリズムを採用し、レプリケーションでは非同期レプリケーションを採用しています。

8.2 その他の方法

（１）レプリケーションと二重書き込み：キャッシュノードのレプリケーションが非同期から二重書き込みに変更されます。両方のコピーが正常に書き込まれた場合にのみ、成功したとみなされます。

（２）仮想層：一貫性のあるハッシュが存在する。ハッシュリングの 1 つが使用できない場合、データは隣接するリングに書き込まれます。ハッシュが利用可能になると、データは通常のハッシュリングに書き込まれ、データオフセットの問題が発生します。この場合、これを実現するために、HASH リングの前に仮想レイヤーを追加することを検討できます。

（３）マルチレベルキャッシュ：例えば、第１レベルではローカルキャッシュを使用し、第２レベルでは分散キャッシュを使用し、第３レベルでは分散キャッシュ＋ローカル永続性を使用する。

方法はいろいろあり、ビジネスシナリオに応じて柔軟に選択する必要があります。

9. キャッシュアバランチ

雪崩とは、多数のキャッシュが失敗し、その結果、多数の要求がデータベースにアクセスし、データベースサーバーが要求を処理できなくなったり、クラッシュしたりする状況を指します。

解決：

（１）キャッシュの有効期限を合理的に計画する。

（２）データベースの負荷圧力を合理的に評価する。

（３）データベースの過負荷保護やアプリケーション層での電流制限を行う。

（４）マルチレベルキャッシュ設計、高いキャッシュ可用性

10. キャッシュ侵入

キャッシュは通常、キーと値の形式で存在します。特定のキーが存在しない場合は、データベースが照会されます。このキーが存在しない場合は、データベースが頻繁に要求され、データベースへのアクセスに負担がかかります。

解決：