Alibaba P8 アーキテクトが語る: アプリケーション シナリオ、選択比較、分散キャッシュの問題と課題

分散キャッシュを使用する理由は何ですか?

典型的な Taobao のダブル 11 フラッシュ セールのような高同時実行環境では、数億人のユーザーが数分以内に Taobao に集まります。このとき、アクセスが傍受されないと、大量の読み取りおよび書き込み要求がデータベースに殺到することになります。ディスクの処理速度がメモリと同じレベルではないことは明らかなので、サーバーはすぐにクラッシュします。データベースの負荷を軽減し、システムの応答速度を向上させる観点から、データベースの前にキャッシュのレイヤーが追加されます。アクセス圧力が高くなるほど、CDN はキャッシュする前に画像などのアクセス要求をインターセプトするようになります。

また、初期の単一マシンのメモリ リソースと容量は限られていたため、ローカル キャッシュを多用すると、同じデータが異なるノードによって複数のコピーで保存され、メモリ リソースが大量に浪費されることになります。そこで、分散キャッシュが誕生しました。

分散キャッシュ アプリケーション シナリオ

1. ページキャッシュ。 HTML、CSS、画像などの Web ページのコンテンツ フラグメントをキャッシュするために使用されます。
2. アプリケーション オブジェクト キャッシュ。キャッシュ システムは、データベースの負荷を軽減し、アプリケーション アクセスを高速化することを目的として、ORM フレームワークのセカンダリ キャッシュとして外部サービスを提供します。
3. 分散 Web 展開、状態キャッシュのセッション同期問題を解決します。キャッシュには、アプリケーションが水平に展開されたときのセッション セッション ステータスとステータス データが含まれます。このタイプのデータは一般に回復が難しく、高い可用性が求められます。主に高可用性クラスターで使用されます。
4. 並列処理。通常、共有する必要がある中間計算結果が多数含まれます。
5. クラウドコンピューティング分野における分散キャッシュサービスの提供。

分散キャッシュの比較: Memcache VS Redis

1. Redisは単純なk/v型データをサポートするだけでなく、リスト、セット、zset、ハッシュなどのデータ構造のストレージも提供します。Memcacheは単純なデータ型のみをサポートし、クライアントが複雑なオブジェクトを独自に処理する必要があります。

2. Redis はデータの永続性をサポートしています。つまり、メモリ内のデータをディスクに保存し、再起動時に再度読み込んで使用することができます (PS: rdb、aof に永続化されます)。

3. Memcache には永続化メカニズムがないため、クラッシュするとキャッシュされたデータはすべて無効になります。 Redis は永続的に構成されています。シャットダウンまたは再起動後、シャットダウン時のデータが自動的にキャッシュ システムにロードされます。より優れた災害復旧メカニズムを備えています。

4. Memcache は Magent を使用して、クライアント上で一貫性のあるハッシュを実行し、配信することができます。 Redis はサーバー側での分散をサポートします (PS: Twemproxy/Codis/Redis クラスターの複数の分散実装方法)

5. Memcached の単純な制限は、キーと値の制限です。 ***キーの長さは 250 文字です。許容されるストレージ データは 1 MB を超えることはできません (構成ファイルを変更して増やすことができます)。これは、一般的なスラブの最大値であり、仮想マシンには適していないためです。 Redis のキーの長さは最大 512k をサポートします。

6. Redis は、データが順番に送信されるよう、シングルスレッド モデルを使用します。 Memcache はデータの一貫性を確保するために cas を使用する必要があります。 CAS (Check and Set) は、同時一貫性を保証するメカニズムであり、「楽観的ロック」のカテゴリに属します。原理は非常にシンプルです。バージョン番号を取得して操作し、バージョン番号を比較して、一致している場合は操作し、一致していない場合は操作を中止します。

CPU 使用率。 Redis は 1 つのコアのみを使用しますが、Memcached は複数のコアを使用できるため、各コアに小さなデータを保存する場合、平均して Redis の方が Memcached よりもパフォーマンスが高くなります。 100k を超えるデータの場合、Memcached は Redis よりも優れたパフォーマンスを発揮します。

7. Memcache メモリ管理: Slab Allocation を使用します。原理は非常にシンプルで、一連の固定サイズのグループを事前に割り当て、データ サイズに基づいて最も適切なブロック ストレージを選択します。メモリの断片化を回避します。 (デメリット: 長さを変更できないため、一定量のスペースが無駄になります) デフォルトでは、memcached の次のスラブの最大値は、前のスラブの 1.25 倍です。

8. Redis のメモリ管理: Redis は配列を定義してすべてのメモリ割り当てを記録します。 Redis はパッケージ化された malloc/free を使用します。これは Memcached のメモリ管理方法よりもはるかにシンプルです。 malloc は最初に管理対象メモリ内の使用可能な領域をリンク リスト方式で検索するため、メモリの断片化が大量に発生します。

分散キャッシュ選択の概要

実際、企業が Memcache または Redis を選択する場合、ビジネス使用シナリオにさらに注意を払う必要があります (Memcache と Redis はどちらも十分に高いパフォーマンスと安定性を備えているため)。ビジネス シナリオで永続的なキャッシュまたは複数のデータ構造をサポートするキャッシュが必要な場合は、Redis が最適な選択肢です。

(追記: Redis クラスター ソリューションも Memcache よりも優れています。Memcache はクライアント側の一貫性のあるハッシュ クラスター ソリューションを使用しますが、Redis は分散型のサーバー側クラスター ソリューションを使用します)

まとめると、キャッシュ システムがより多くのビジネス シナリオをサポートできるようにするには、Redis を選択することをお勧めします。

分散キャッシュの一般的な問題と課題

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

キャッシュアバランチは、簡単に言えば、元のキャッシュの障害と新しいキャッシュの障害（たとえば、キャッシュを設定するときに同じ有効期限を使用し、キャッシュの大きな領域が同時に期限切れになる）により、キャッシュにアクセスする必要があるすべての要求がデータベースのクエリに送信され、データベースの CPU とメモリに大きな負荷がかかり、ひどい場合にはデータベースがクラッシュする可能性があります。これにより一連の連鎖反応が発生し、システム全体が崩壊します。

2. キャッシュ侵入

キャッシュ侵入とは、ユーザーがデータをクエリしたときに、そのデータがデータベース内に存在せず、したがってキャッシュ内にも存在しないことを意味します。その結果、ユーザーはキャッシュ内でクエリを見つけることができず、毎回データベースに再度クエリを実行する必要があり、何も返されません (2 つの無駄なクエリに相当)。この方法では、リクエストはキャッシュをバイパスしてデータベースに直接クエリを実行しますが、これは頻繁に言及されるキャッシュ ヒット率の問題でもあります。

3. キャッシュの予熱

キャッシュの予熱は比較的一般的な概念であるはずです。多くの友人が簡単に理解できるはずだと信じています。キャッシュの事前加熱とは、システムがオンラインになった後、関連するキャッシュ データをキャッシュ システムに直接ロードすることを意味します。これにより、最初にデータベースをクエリし、ユーザーが要求したときにデータをキャッシュするという問題を回避できます。ユーザーは事前に予熱されたキャッシュデータを直接クエリします。

4. キャッシュの更新

キャッシュ サーバーに組み込まれたキャッシュ有効期限戦略に加えて、特定のビジネス ニーズに基づいてキャッシュ削除をカスタマイズすることもできます。一般的な戦略は 2 つあります。

（１）期限切れのキャッシュを定期的にクリーンアップする。

（２）ユーザーリクエストが来たら、そのリクエストに使われたキャッシュが期限切れかどうか判断する。期限が切れている場合は、基盤となるシステムにアクセスして新しいデータを取得し、キャッシュを更新します。

どちらにもそれぞれ長所と短所があります。最初の方法の欠点は、多数のキャッシュされたキーを維持するのが面倒なことです。 2 番目の方法の欠点は、ユーザーからのリクエストが来るたびにキャッシュが無効であると判断する必要があり、ロジックが比較的複雑になることです。アプリケーション シナリオに基づいて特定のソリューションを検討できます。

5. キャッシュのダウングレード

トラフィックが劇的に増加したり、サービスの問題 (応答時間が遅い、応答がないなど) が発生したり、非コア サービスがコア プロセスのパフォーマンスに影響を与えたりする場合は、損失があっても、サービスが引き続き利用可能であることを保証する必要があります。システムは、いくつかの重要なデータに基づいて自動的にダウングレードすることも、手動でダウングレードできるようにスイッチを構成することもできます。

ダウングレードの最終的な目標は、コア サービスが損なわれた場合でも、そのサービスが利用可能であることを保証することです。また、一部のサービスはダウングレードできません（ショッピングカートへの追加、チェックアウトなど）。

ダウングレードする前に、システムを整理して、王を救うためにシステムを犠牲にできるかどうかを確認する必要があります。したがって、どの項目をどんな犠牲を払ってでも保護しなければならないか、どの項目を格下げしてもよいかを選別することになります。たとえば、ログ レベルの設定プランを参照できます。

（１）全般：例えば、ネットワークジッタやサービスがオンライン状態であるために、一部のサービスが時折タイムアウトすることがあり、自動的にダウングレードされることがあります。

（２）警告：一部のサービスの成功率が一定期間にわたって変動する場合（例：95％から100％の間）、それらのサービスは自動または手動でダウングレードされ、アラームが送信されます。

（3）エラー：例えば、可用性率が90％を下回ったり、データベース接続プールが圧迫されたり、訪問数がシステムが耐えられる最大しきい値まで急増したりした場合、状況に応じてシステムを自動または手動でダウングレードできます。

（4）重大なエラー：例えば、特別な理由によりデータが間違っている場合、緊急の手動ダウングレードが必要になります。