アリババから第三層企業まで、大規模分散システムにおけるキャッシュの応用

1. キャッシュの概要

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

1. キャッシュの原理

より高速なストレージ（デバイス）へのデータの書き込み/読み取り。
アプリケーションに最も近い場所にデータをキャッシュします。
ユーザーに最も近い場所にデータをキャッシュします。

2. キャッシュの分類

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

CDN キャッシュ;
リバースプロキシキャッシュ。
分散キャッシュ;
ローカルアプリケーションキャッシュ。

3. メディアをキャッシュする

よく使用されるミドルウェア: Varnish、Ngnix、Squid、Memcache、Redis、Ehcache など。
キャッシュコンテンツ: ファイル、データ、オブジェクト。
キャッシュメディア: CPU、メモリ (ローカル、分散)、ディスク (ローカル、分散)

4. キャッシュ設計

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

何をキャッシュしますか?

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

キャッシュはどこにありますか?

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

問題をキャッシュする方法は?

有効期限ポリシー
固定時間: たとえば、指定されたキャッシュ時間は 30 分です。
相対時間: たとえば、過去 10 分間にアクセスされていないデータなど。
同期メカニズム
リアルタイム書き込み。（押す）
非同期更新。（押したり引いたり）

2. CDNキャッシュ

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

1. CND原則

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

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

ネットワーク要求パス:

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

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

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

ネットワークパス:

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

回答: オペレータネットワーク ——》ローカルネットワーク (LAN)

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

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

2. CDNのメリットとデメリット

利点（Baidu百科事典より）：

ローカルキャッシュアクセラレーション: 特に大量の画像や静的ページを含むサイトのアクセス速度が向上します。

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

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

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

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

欠点:

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

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

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

解決する：

（１）キャッシュの有効期限を設定する（１時間、結果整合性）。

（２）データバージョン番号

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

4. CND技術実習

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

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

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

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

1. キャッシュの原則

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

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

2. イカの例

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

Last-Modified: ページがいつ変更されたかをリバースプロキシに通知します
有効期限: リバースプロキシにページをキャッシュから削除するタイミングを指示します。
Cache-Control: リバースプロキシにページをキャッシュするかどうかを指示します
プラグマは実装固有の命令を含めるために使用され、最も一般的に使用されるのはプラグマ: no-cacheです。

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

DNS ポーリングテクノロジーにより、クライアントの要求は Squid リバースプロキシサーバーの 1 つに分散され、処理されます。
この Squid がユーザーの要求したリソースをキャッシュしている場合は、要求されたリソースをユーザーに直接返します。
それ以外の場合、この Squid は、設定されたルールに従って処理するために、キャッシュされていないリクエストを隣接する Squid とバックエンド WEB サーバーに送信します。
これにより、バックエンド WEB サーバーの負荷が軽減されるだけでなく、Web サイト全体のパフォーマンスとセキュリティも向上します。

2. プロキシキャッシュの比較

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

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

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

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

（4）Squidは機能が充実しており、さまざまな静的ファイルキャッシュに適しています。通常、負荷分散のためにフロントエンドに HAProxy または nginx がインストールされ、複数のインスタンスが実行されます。

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

4. 分散キャッシュ

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

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

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

1. メモリキャッシュ

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

Memcache の機能:

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

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

（3）シンプルプロトコル：これは、telnetを介してmemcachedサーバー上のデータに直接アクセスできるテキストベースのプロトコルです。さまざまなキャッシュがこのプロトコルを参照するのは簡単で便利です。

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

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

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

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

Memcache の動作原理:

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

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

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

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

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

Memcache クラスター

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

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

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

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

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

剰余アルゴリズム:

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

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

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

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

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

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

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

2. レディス

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

組み込みのレプリケーション、Lua スクリプト、LRU エビクション、トランザクション、さまざまなレベルのディスク永続性、および Redis Sentinel と自動パーティショニング (クラスター) による高可用性。

Redis の一般的なデータ型

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

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

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

ハッシュ

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

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

実装方法: Redis Hash に対応する Value は、実際には内部的には HashMap です。実際には、ここには 2 つの異なる実装があります。

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

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

リスト

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

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

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

セット

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

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

実装方法: set の内部実装は、値が常に null となる HashMap です。実際、ハッシュを計算することで重複を素早く排除します。このため、セットはメンバーがセット内にあるかどうかを判断するメソッドを提供できます。

ソートされたセット

よく使用されるコマンド: zadd、zrange、zrem、zcard。

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

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

Redis クラスター

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

切り替えプロセス:

マスターが失敗すると、VIP はスレーブに移行します。スレーブ上の keepalived は、redis に slaveof no one を実行してサービスの提供を開始するように通知します。
マスターが起動すると、VIP アドレスは変更されず、マスターの keepalived は redis にスレーブ IP ホストの slaveof を実行し、スレーブとしてデータの同期を開始するように通知します。
等々。

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

計画も考慮もされていないので、一般的にはそのような問題は発生しません
計画的な再起動。再起動する前に、操作および保守手段を使用してメインデータベースデータを SAVE DUMP します。順序に注意してください:

いずれかのマシン上のすべての Redis をシャットダウンするには、すべてのマスターを別のマシンに切り替える必要があります (マスターとスレーブの両方が 1 台のマシンにあるマルチインスタンス展開)。マシンをシャットダウンする
マスター上のRedisサービスを順番にダンプする
メインを閉じる
マスターを起動し、データがロードされるのを待ちます。
開始
DUMP ファイルを削除します (再起動の読み込みが遅くなるのを防ぐため)

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

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

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

アドバンテージ：

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

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

高性能で CPU を集中的に使用する Redis ノードクラスターには複数の CPU リソースの冗長性があり、追加の機器を必要とせずに Redis ノードクラスターに展開できます。

3. MemcacheとRedisの比較

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

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

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

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

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

5. ローカルキャッシュ

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

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

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

2. メモリキャッシュ

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

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

責任分担:

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

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

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

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

リクエストプロセス:

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

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

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

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

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

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

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

7. 一般的なキャッシュの問題

1. データの一貫性

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

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

シーン紹介

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

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

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

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

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

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

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

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

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

回避策

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

2番目のシナリオ:

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

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

3番目のシナリオ:

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

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

その他の方法

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

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

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

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

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

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

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

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

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

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

回避策

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

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

その他の方法

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

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

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

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

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

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

解決：

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

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

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

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

4. キャッシュ侵入

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

解決：