分散MemCacheの詳細な解釈

MemCacheとは

MemCache は、動的な Web アプリケーションがデータベースの負荷を軽減するための、無料のオープン ソースの高性能分散メモリ オブジェクト キャッシュ システムです。データとオブジェクトをメモリにキャッシュしてデータベースの読み取り回数を減らすことで、Web サイトへのアクセス速度が向上します。 MemCaChe は、キーと値のペアを格納する HashMap です。メモリ内の任意のデータ (文字列、オブジェクトなど) に使用されるキー値ストレージです。データは、データベース呼び出し、API 呼び出し、またはページ レンダリングの結果から取得されます。 MemCache の設計コンセプトは小さいながらも強力です。シンプルな設計により、迅速な導入と開発が容易になり、大規模なデータ キャッシュが直面する多くの困難な問題が解決されます。オープン API により、MemCache は Java、C/C++/C#、Perl、Python、PHP、Ruby などのほとんどの一般的なプログラミング言語で使用できます。

[[257078]]

さらに、MemCache と MemCached の違いについても説明します。

1. MemCacheはプロジェクトの名前です

2. MemCachedはMemCacheサーバー上の実行可能ファイルの名前です

MemCache の公式ウェブサイトは http://memcached.org/ です。

MemCache アクセス モデル

理解を深めるために、元アリババ技術専門家の Li Zhihui 氏の著書「大規模ウェブサイト技術アーキテクチャの中核原則とケース分析」の MemCache セクションを真似て、自分で絵を描いてみました。

特に明確にしておきたいことが1つあります。 MemCache は「分散キャッシュ」と呼ばれますが、MemCache 自体には分散機能はありません。 MemCache クラスターは相互に通信しません (対照的に、たとえば JBoss Cache では、サーバーがキャッシュ データを更新すると、クラスター内の他のマシンにキャッシュを更新するかキャッシュ データをクリアするように通知します)。いわゆる「分散」は、上の図のプロセスのように、クライアント プログラムの実装に完全に依存します。

同時に、この図に基づいて、MemCache がキャッシュを書き込むプロセスを整理してみましょう。

1. アプリケーションはキャッシュに書き込む必要があるデータを入力します

2. API はキーをルーティング アルゴリズム モジュールに入力し、ルーティング アルゴリズムはキーと MemCache クラスター サーバー リストに基づいてサーバー番号を取得します。

3. サーバー番号からMemCacheとそのIPアドレスとポート番号を取得します。

4. APIは通信モジュールを呼び出して指定された番号のサーバーと通信し、データをサーバーに書き込み、分散キャッシュ書き込み操作を完了します。

読み取りキャッシュは書き込みキャッシュと同じです。同じルーティング アルゴリズムとサーバー リストが使用され、アプリケーションが同じキーを照会する限り、MemCache クライアントは常に同じクライアントにアクセスしてデータを読み取ります。データがサーバーにキャッシュされている限り、キャッシュヒットが保証されます。

この MemCache クラスター アプローチは、パーティションのフォールト トレランスの観点からも検討されます。 Node2 がダウンした場合、Node2 に保存されているデータは利用できなくなります。この時点では、Node0 と Node1 はまだクラスター内に存在するため、次に Node2 に格納されている Key 値が要求されたときには、必ずヒットしません。このとき、キャッシュするデータはまずデータベースから取得され、次にルーティング アルゴリズム モジュールは Key 値に応じて Node0 と Node1 の間のノードを選択し、対応するデータをそこに入れて、次回キャッシュを再び使用できるようにします。このクラスターアプローチは非常に優れていますが、コストが比較的高いという欠点があります。

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

上の図から、サーバー クラスターの管理という非常に重要な問題がわかります。ルーティングアルゴリズムは非常に重要です。負荷分散アルゴリズムと同様に、ルーティング アルゴリズムはクラスター内のどのサーバーにアクセスするかを決定します。まず、簡単なルーティング アルゴリズムを見てみましょう。

1. 剰余ハッシュ

たとえば、文字列 str に対応する HashCode は 50、サーバーの数は 3、残りは 2 で、str はノード Node2 に対応するため、ルーティング アルゴリズムは str を Node2 サーバーにルーティングします。 HashCode は非常にランダムであるため、剰余ハッシュ ルーティング アルゴリズムを使用して、キャッシュされたデータが MemCache サーバー クラスター全体に均等に分散されるようにすることができます。

サーバー クラスターのスケーラビリティを考慮しない場合 (スケーラビリティについては、大規模 Web サイト アーキテクチャの学習ノートを参照してください)、剰余ハッシュ アルゴリズムはほとんどのキャッシュ ルーティング要件を満たすことができますが、分散キャッシュ クラスターを拡張する必要がある場合は困難になります。

MemCache サーバー クラスターが 3 から 4 に拡張されたと仮定します。サーバー リストを変更し、残りのハッシュを引き続き使用します。 50 から 4 を引いた余りは 2 であり、これはノード 2 に対応します。ただし、str は元々 Node1 に存在していたため、キャッシュ ミスが発生しました。これが十分に明確でない場合は、例を見てみましょう。 HashCode値が0〜19のデータが20個あります。

現在、容量を 4 台のマシンに拡張しており、太字の赤い文字はヒットを示しています。

容量を 20 ユニット以上に拡張すると、最初の 3 つの HashCode に対応するキーのみがヒットし、これは 15% になります。もちろん、これは単なる簡単な例であり、実際の状況はこれよりもはるかに複雑であることは間違いありませんが、剰余ハッシュを使用するルーティング アルゴリズムでは、容量を拡張するときに大量のデータが正しくヒットしなくなることを説明するには十分です (実際には、データがヒットしないだけでなく、ヒットできない大量のデータが削除される前に元のキャッシュのメモリを占有し続けます)。この結果は明らかに受け入れられないものである。ウェブサイト業務では、ほとんどの業務データ操作要求は実際にはキャッシュを通じて取得され、データベースにアクセスする読み取り操作はごくわずかです。そのため、データベースの負荷容量はキャッシュを前提として設計されます。サーバーの拡張によりキャッシュされたデータの大部分が正しく読み取れなくなると、そのデータへのアクセスの負荷がデータベースにかかり、データベースの負荷容量を大幅に超過し、データベースがクラッシュする可能性もあります。

この問題には解決策があり、解決手順は次のとおりです。

（１）ウェブサイトのトラフィックが少ない時期、通常は深夜に、技術チームは容量の拡張やサーバーの再起動のために残業する。

（２）リクエストをシミュレートしてキャッシュを徐々にウォームアップし、キャッシュサーバ内のデータが再分配されるようにする

2. 一貫性ハッシュアルゴリズム

コンシステント ハッシュ アルゴリズムは、コンシステント ハッシュ リングと呼ばれるデータ構造を通じて、キーからキャッシュ サーバーへのハッシュ マッピングを実装します。私が描いた絵を見てください:

具体的なアルゴリズムのプロセスは、まず長さ 232 の整数リング (このリングはコンシステント ハッシュ リングと呼ばれます) を構築し、ノード名のハッシュ値に従ってこのハッシュ リング上にキャッシュ サーバー ノードを配置し (その分布は [0, 232-1] です)、次にキー値に従ってキャッシュするデータのハッシュ値を計算し (その分布も [0, 232-1] です)、次にこのキー値のハッシュ値に最も近いサーバー ノードを時計回りにハッシュ リングで検索して、キーからサーバーへのマッピング検索を完了します。

図に示すように、3 つのノード ポイントはそれぞれハッシュ リング上の 3 つの位置に配置され、キー値はハッシュ コードに応じてハッシュ リング上の固定位置を持ちます。位置が決まると、キーは時計回りに移動して最も近いノードを見つけ、そのノードの MemCache サーバーにデータを保存します。ハッシュ リングにノードが追加されると何が起こるか見てみましょう。

1 つのキー値のデータにのみ影響を与える Node4 ノードを追加したことがわかります。元々、このキー値は Node1 サーバー上にあるはずでしたが、現在は Node4 に移動する必要があります。一貫性のあるハッシュ アルゴリズムを使用すると、確かにクラスター全体に影響しますが、影響を受けるのは太字のセグメントのみです。影響率の半分以上に影響を与える剰余ハッシュ アルゴリズムと比較すると、この影響ははるかに小さくなります。さらに重要なのは、クラスター内のキャッシュ サーバー ノードの数が多いほど、ノードを追加した場合の影響が小さくなることです。これは簡単に理解できます。つまり、クラスターのサイズが大きくなるにつれて、元のキャッシュされたデータにヒットし続ける可能性がますます高くなります。サーバーにキャッシュされた読み取り不可能なデータは依然として少量存在しますが、この割合は十分に小さいため、データベースにアクセスしても、データベースに致命的な負荷がかかることはありません。

具体的なアプリケーションとしては、長さ 232 のこの一貫性のあるハッシュ リングは、通常、バイナリ検索ツリーを使用して実装されます。二分探索木に関しては、それはアルゴリズムの問​​題です。関連情報を自分で調べることができます。

MemCacheの実装原理

まず、MemCache データはメモリに保存されることに注意してください。メモリに保存するということは、いくつかのことを意味すると思います。

1. OracleやMySQLなどの従来のリレーショナルデータベースはデータの永続性を維持するためにデータをハードディスクに保存し、IO操作速度が遅いため、データへのアクセス速度は従来のリレーショナルデータベースよりも速くなります。

2. MemCacheデータはメモリに保存されるため、MemCacheを再起動するとデータは消えてしまいます。

3. MemCache のデータはメモリに保存されるため、マシンのビット数によって制限されます。これは以前の記事でも何度も書かれてきました。 32 ビット マシンでは最大 2 GB のメモリ空間しか使用できませんが、64 ビット マシンでは上限がないと考えられます。

それでは、MemCache の原理を見てみましょう。 MemCache で最も重要なことは、メモリ割り当ての内容です。 MemCache が採用しているメモリ割り当て方法は、固定スペース割り当てです。それを説明するために絵を描いてみましょう:

この図には、slab_class、slab、page、chunk という 4 つの概念が含まれています。それらの関係は次のとおりです。

1. MemCacheはメモリ空間をスラブのグループに分割します

2. 各スラブには複数のページがあります。各ページのデフォルトのサイズは 1M です。スラブが 100 MB のメモリを占有する場合、このスラブの下に 100 ページが存在する必要があります。

3. 各ページにはチャンクのグループが含まれています。チャンクはデータが実際に保存される場所です。同じスラブ内のチャンクのサイズは固定されています。

4. 同じサイズのチャンクを持つスラブは、slab_classと呼ばれるようにまとめられます。

MemCache がメモリを割り当てる方法は、アロケータと呼ばれます。スラブの数は限られており、数個、数十個、または数十個になることがあります。これは、起動パラメータの構成に関連しています。

MemCache 内の値が格納される場所は、値のサイズによって決まります。値は常にチャンク サイズに最も近いスラブに格納されます。たとえば、slab[1]のチャンク サイズは 80 バイト、slab[2]のチャンク サイズは 100 バイト、slab[3]のチャンク サイズは 128 バイトです (隣接するスラブのチャンクは 1.25 の比率で増加します。この比率は、MemCache の起動時に -f で指定できます)。したがって、88 バイトの値が渡された場合、それはスラブ 2 に配置されます。スラブを配置する場合、最初にスラブをメモリに適用する必要があります。メモリアプリケーションはページ単位なので、最初のデータが配置されると、データの大きさに関係なく、1M のページがスラブに割り当てられます。ページを申請すると、スラブはチャンクのサイズに応じてページのメモリをチャンクに分割し、チャンク配列に変換します。最後に、チャンク配列から 1 つのチャンクが選択され、データが格納されます。

このスラブに割り当て可能なチャンクがない場合はどうなりますか? MemCache が -M なしで起動された場合 (LRU が無効になっており、メモリが不足している場合は Out Of Memory エラーが報告されます)、MemCache はこのスラブ内の最も最近使用されていないチャンクのデータをクリアし、最新のデータに置き換えます。 MemCache のメモリ割り当てとリサイクル アルゴリズムに関しては、次の 3 つの点がまとめられます。

1. MemCache のメモリ割り当てチャンクでメモリの無駄が発生します。 88 バイトの値は 128 バイトのチャンク (次の大きいチャンク) に割り当てられ、その結果 30 バイトが失われます。ただし、これにより、メモリの断片化を管理する問題も回避されます。

2. MemCacheのLRUアルゴリズムはグローバルではなく、スラブ固有です

3. MemCache に保存される値のサイズが制限されている理由を理解する必要があります。新しいデータが来ると、スラブはまずページ単位でメモリの一部を申請します。適用される最大メモリは 1M のみなので、値のサイズは 1M を超えることはできません。

MemCacheの特徴と限界をまとめる

MemCache については上記で比較的詳しく説明しました。 MemCache の制限と機能の概要は次のとおりです。

1. 十分なメモリがある限り、MemCacheに保存できるアイテムデータの量に制限はありません。

2. 32 ビット マシンの単一の MemCache プロセスで使用される最大メモリは 2G です。これについては以前の記事でも何度も触れてきました。 64 ビットマシンには制限はありません。

3. キーの最大長は 250 バイトです。これを超える長さの場合は保存できません。

4. 1つのアイテムの最大サイズは1MBです。 1MBを超えるデータは保存されません。

5. MemCache サーバーは安全ではありません。たとえば、MemCache ノードがわかっている場合は、そのノードに直接 telnet し、flush_all を使用して既存のキーと値のペアを直ちに無効にすることができます。

6. この操作は比較的遅く、他の操作をブロックするため、MemCache 内のすべての項目を走査することはできません。

7. MemCache の高パフォーマンスは、2 段階のハッシュ構造によって実現されます。最初の段階はクライアント側で、ハッシュ アルゴリズムを使用してキー値に基づいてノードを計算します。 2 番目の段階はサーバー側で行われ、内部ハッシュ アルゴリズムを使用して実際のアイテムを検索し、クライアントに返します。実装の観点から見ると、MemCache は非ブロッキングのイベントベースのサーバー プログラムです。

8. MemCache にキー値を追加するときに、有効期限 0 を渡すと、キー値が永続的に有効になります。このキー値も 30 日後に期限切れになります。 memcache.c のソースコードを参照してください。

有効期限はmem

キャッシュのソース コードには、開発者が MemCache キー値の有効期限である 30 日を変更できないことが記載されています。

MemCache命令の概要

前述のように、MemCache の特定のノードがわかっている場合は、そのノードに直接 telnet し、さまざまなコマンドを使用して MemCache を操作することができます。 MemCache のコマンドを見てみましょう。

統計コマンドの説明

stats は、現在の MemCache サーバーのステータスを一覧表示する重要なコマンドです。次のようなデータセットを例に挙げます。

これらのパラメータは、MemCache サーバーの基本情報を反映します。それぞれの意味は次のとおりです。

パラメータ名: 機能: pid: MemCache サーバーのプロセス ID。 uptime: サーバーが稼働している秒数。 time: サーバーの現在の UNIX タイムスタンプ。 version: MemCache バージョン。 point_size: 現在のオペレーティング システム ポインター サイズ。オペレーティング システムのビット数を反映します。 64 は MemCache サーバーが 64 ビットであることを意味します。 rusage_user: プロセスの累積ユーザー時間。 rusage_system: プロセスの累積システム時間。 curr_connections: 現在開いている接続の数。 total_connections: サーバーの起動後に開かれた接続の数。 connection_structures: サーバーによって割り当てられた接続構造体の数。 cmd_get: get コマンドのリクエストの合計数。 cmd_set: set コマンドの要求の合計数。 cmd_flush: flush_all コマンドの要求の合計数。 get_hits: ヒットの総数。キャッシュにとって最も重要なパラメータは、get_hits / (get_hits + get_misses) として表されるキャッシュ ヒット率であることに注意することが重要です。たとえば、キャッシュヒット率は 99.2% です。 get_misses: ミスの合計数。 auth_cmds: 処理された認証コマンドの数。 auth_errors: 処理された認証失敗の数。 bytes_read: 読み取られたバイトの合計数。 bytes_written 送信されたバイトの合計数 limit_maxbytes MemCache に割り当てられたメモリ サイズ (バイト単位) accepting_conns 最大接続数に達したかどうか。1 は達したことを意味し、0 は達していないことを意味します listen_disabled_num 現在のサーバー接続数が最大接続数に達した回数をカウントします。この数値は 0 または 0 に近い値である必要があります。この数値が増加し続ける場合、サービス スレッドに注意する必要があります。MemCache スレッドの現在の合計数。 MemCache スレッドはイベント駆動メカニズムに基づいているため、1 つのスレッドは 1 つのユーザー リクエストに対応しません。バイト数: 現在のサーバーに保存されているアイテムの合計バイト数。current_items: 現在のサーバーに保存されているアイテムの合計数。total_items: サーバーの起動後に保存されたアイテムの合計数。

統計スラブコマンドの説明

上記の MemCache ストレージ メカニズムについて理解が深まったら、各スラブの情報を確認したり、データのセットを例に挙げてみましょう。

まず、2 番目のスラブの chunk_size (144) / 最初のスラブの chunk_size (96) = 1.5、3 番目のスラブの chunk_size (216) / 2 番目のスラブの chunk_size (144) = 1.5 であることがわかります。この MemCache の成長係数は 1.5 であり、chunk_size は 1.5 倍に増加することがわかります。次に、フィールドの意味を説明します。

このコマンドからの大量の出力を見ると、すべての情報が非常に役立ちます。たとえば、最初のスラブで使用されるチャンクが非常に少なく、2 番目のスラブで使用されるチャンクが多い場合は、MemCache の成長係数を適切に増やし、データの一部を最初のスラブに収め、2 つのスラブのメモリを適切にバランスさせてスペースの無駄を避けることを検討できます。

MemCache Java実装例

ここまで述べてきましたが、Java プログラマーとして、MemCache クライアントの実装を書かないわけにはいきません。 MemCache クライアントの実装を提供するサードパーティの jar パッケージは多数あります。その中で、XMemCached が優れています。 XMemCached には、高効率、非ブロッキング IO、低リソース消費、完全なプロトコルのサポート、ノードの重みの設定が可能、ノードの動的な追加と削除が可能、JMX のサポート、Spring フレームワークとの統合のサポート、接続プールの使用、優れたスケーラビリティなど、多くの利点があるため、広く使用されています。ここでは、XMemCache を使用して、単純な MemCache クライアント インスタンスを記述します。これは検証されておらず、あくまでも参考用です。