負荷の高いプロジェクトでmemcachedとRedisを使用する

ヴャチェスラフ・モスカレンコ（レンヴェンド）

高負荷プロジェクトのツール、キャッシング、特にmemcached、Redis、RabbitMQキューサービス、または一般の人々の「ウサギ」について説明します。



レポートの最初の部分では、memcachedとは何か-Redisの基本概念、その機能、およびこれら2つのサービスの違いについて説明します。 私たちのプロジェクトでの両方のサービスの実用化についてお話します。



第2部では、RabbitMQメッセージブローカー、「ウサギ」にある基本概念、プロデューサーとコンシューマー間のメッセージルーティングの仕組みについて説明します。 また、このメッセージブローカーのプロジェクトでの実際的な応用についても説明します。



キャッシングについて。 あなたの多くはあなたのウェブプロジェクトに少なくとも何かをキャッシュしていると思うので、すべてが非常にシンプルで手頃な価格になるでしょう。





キャッシュとは何ですか？ これは、データを要求するクライアントとメインの（通常は低速の）ストレージとの間の仲介です。 このような仲介により、データを非常に迅速に受信できます。 通常、memcachedおよびRedis-aの場合、データはRAMに保存されます。 キャッシュを効果的に使用することにより、データベースサーバーの負荷を軽減できます。



問題は、いつ、何をキャッシュすべきかということです。 頻繁に要求されるデータをキャッシュすることが有用であることは明らかです。 ある種の小さな幼稚園があり、1時間あたり100人のユーザーがいる場合、ベースに大きな負荷はなく、キャッシュは無効になります。 ここで、大規模な高負荷プロジェクトでは、データベースの負荷を減らしたい場合、キャッシュを使用します。



キャッシュできる/できないデータを理解することも必要です。 簡単な例：ユーザーがオンラインストアで注文し、残りの製品を外部システムから取得する必要がある場合、このデータをキャッシュできないため、オンラインで行う必要があります。 次のユーザーがキャッシュからデータを取得し、エラーが発生する可能性があります。 したがって、たとえば数時間、1日など、保存できるデータのみをキャッシュできます。



説明するキャッシングツールは、memcachedとRedisです。



最初のものから始めましょう。 Memcachedは、RAMにデータをキャッシュするための高性能サービスです。 その歴史は2003年に始まります。ブラッドフィッツパトリックはLivejournal向けに開発し、そこで成功裏に実装され、サービスを加速しました。



Memcachedの機能：格納するデータの量に関係なく、非常に高速で、シンプルなインターフェイスがあります。データを入力（設定）したり、取得したり、有効期間後にキーを削除したりできます。 memcachedはアトミック操作をサポートしています-incr / decr、append / prepend; サーバーの数を簡単に増やすことができ、サーバーの1つが落ちたとしても、単にキャッシュミスとして計算されます。 キャッシュにはデータがありません。



memcachedの制限：キーの最大長は250バイトであり、1つのキーの下に保存できるデータの量は1 MBに制限されています。 memcachedのキー損失は、ライフタイム、メモリ制限、またはサーバーの障害によって発生する可能性があります。



なぜなら 私はPHPプログラマーです。PHPでmemcachedを使用する方法の例を示しました。







PHPには2つの拡張機能があります。1つはlibmemcachedライブラリを使用し、2つ目はphp-memcache拡張機能のみです。 Libmemcachedには、データを実装するためのより多くのオプションがあり、デフォルトではPHPを使用してシリアル化されますが、たとえばJSONシリアライザーを定義できます。 memcachedオブジェクトを作成し、サーバーをlocalhostに追加します。デフォルトポートは11211です。特定の文字列を入力し、「array」キーの下に特定の配列を入力し、データが「腐敗」する有効期間を設定できます。 単純なget操作で、データを取得します。 つまり 複雑なことは何もありません。 まだ使用していないシステム管理者にmemcached、php拡張機能をインストールし、memcached用の独自の有能な「ラッパー」を作成し、それを使用してデータベースをロードし、キャッシュできる頻繁に要求されるデータをキャッシュします。



次に、Redisとは何か、memcachedとの違いについて説明します。



Redisは、文字列、ハッシュ、リスト、セット、ソートされたセットなど、多数のデータ型をサポートしています。 Redisは、データを定期的にディスクにフリップする方法も知っています。たとえば、数千件のデータを更新した後、すべてをディスクにフラッシュできます。 RedisはLRUクリーンアップをサポートしており、さまざまなキークリーニング戦略を定義できます。たとえば、クリーニング、長期間使用できない、寿命のあるキーのみを削除するなど、ランダムに実行できます。 また、彼がメモリをまったくクリアしないようにすることもできますが、データを更新すると、Redisクライアントはエラーをスローします。 最も未使用のデータをクリアするようにしましょう。



Redisはマスタースレーブレプリケーションをサポートし、シンプルキューをサポートします。 チャンネルの作成、チャンネル登録、チャンネルへのメッセージの公開、閲覧ができます。 MULTI / EXECコマンド、LUAスクリプトを使用したトランザクションをサポートします。 Redisには優れたドキュメントもあります-redis.ioのWebサイトにアクセスすると、すべてが利用可能です。



次に、データ型と、Redisで使用できるコマンドについて説明します。







最初のデータ型は文字列です。 インターフェースはシンプルです。 特定のキーに値を入力できます。 スライドは、コンソールクライアントからRedisへのスクリーンショットの例を示しています。 特定のポート、特定のホストでSQLに接続するのと同じように、Redisと連携して値を設定し、データを取得し、寿命を秒単位で設定して、残りの時間を要求できます。



次のデータ型はハッシュです。 ハッシュは、特定のオブジェクトのフィールドとその値を格納できる構造です。



ハッシュを処理するには、HSETおよびHMSEコマンドが使用されます。 ハッシュフィールドの値を取得するには、HGETALLコマンドを使用して、ハッシュのすべてのプロパティを取得します。



特定の例は、ユーザーセッションをハッシュに格納できることです。







次のデータ型はセットです。 Redisでは、特定のキーに特定の要素セットを保存できますが、Redisの多くはその一意性に責任があります。 つまり 2つの同一の要素をセットに追加すると、彼は常に単独でそこにいます。 セットに要素を追加するには、SADDコマンドを使用し、セットのすべての要素を取得するには、SMEMBERSコマンドを使用します。 有効期間のEXPIREコマンドでキーを設定したり、キーを削除したりできます。



別のデータ型はソートされたセットです。 これらはセットとほぼ同じように機能しますが、セット内の各要素のいわゆる「ポイント」を設定できることを除きます。 上記のスライドの例にあるように、コメントでTIMESTAMPを記事13に渡しました。 キーに名前を付けて、これが第13条のコメントであることを明確にします。



2つの要素をセットに追加すると、ポイントの降順または昇順で並べ替えられたリストを取得できます。



Redisにはまだリストなどのデータ型があります。 ここで、左側、右側の要素セットにプッシュして、特定のインデックスから特定のインデックスに要素を取得できます。



PHPのクライアントは何ですか？



phpredis拡張機能があり、Cで記述されています。PHP、Rediska、RedisServerで記述されたPredisライブラリもあります。特定のポートでソケットを開き、Redisと通信するクラスです。ResidentはRedisServerのフォークですが、それでも拡張機能を使用しますスピードとパフォーマンスの向上のためのphpredis。



もちろん、phpredisを使用することをお勧めします。これは、すべてのベンチマークとテストで高速であり、Cで記述されており、すべてのphp実装が遅いためです。



次のスライドは、memcachedとRedisの違いを示しています。







実際、Redisとmemcachedの両方を特定のタスクに使用する必要があります。 データ構造、セット、ソートされたセットの一部を保存する必要があり、データを失うことができない場合は、もちろん、Redisが助けになります。 Redisはシングルスレッドであることに注意してください。



次に例について説明します。







どういうわけか、プロジェクトでは、製品のクイックビューカードを表示するだけでした。 このページには製品のミニチュアがあり、クリックすると製品の詳細な説明を表示する必要があります。 タスクは、バックエンドの負荷を可能な限り減らすようになりました。 データベースへのアクセスの減少など。



このように決定しました：







つまり AJAXリクエストがNgnixフロントエンドに到着すると、Ngnixにはmemcachedで動作できるモジュールがあります。 最初にキーでmemcachedのデータを要求し、データがある場合（そしてそこに製品のJSONがある場合）、すぐにこのJSONを返します。 非常に高速に動作します。



データがない場合、リクエストはPHPにプロキシされ、2つの状況があります-製品カードは、JSONの形式でRedisにあり、Redisから取得してmemcachedに保存し、クライアントに渡します。



Redisとmemcachedのどちらにもない場合は、MySQLから製品カードをリクエストし、Redisに保存し、このデータをmemcachedに複製して返します。 以下のリクエストで、製品カードはすでにmemcachedから直接発行されています。



ほとんどのRedisデータ型が使用される次のより複雑な例は、パラメトリック検索です。







カタログにはカテゴリがあり、各セクションには独自のフィルタセット、つまり標準のフィルタパネルがあります。 各フィルターグループには独自のオプションがあり、特定のオプションを選択する場合、これらのフィルターを満たす製品のリストをユーザーに表示する必要があります。



以前は、これはすべてMySQLのクエリによって行われ、複雑な選択、分析、あらゆる種類のプロパティがありました。このセクションにはどのフィルタがありますかなど。 それはすべて非常にゆっくりと働きました。 データストレージモデルを完全に変更し、Redisを使用することにしました。 同時に、セクションのフィルターオプションごとに、各オプションを満たす製品IDを保存することにしました。







たとえば、IDが100のカテゴリ「電話」には、「メーカー」と「色」という2つのフィルターグループがあります。



SamsungのRedisの4つの製品-201、202、203、204、およびPhilips-301、302、303の4つの製品があるとします。それぞれのキーには、カテゴリID、フィルター、フィルターオプションが含まれています。 ユーザーがフィルターパネルでSamsungを選択した場合、Redisにリクエストし、製品IDを取得して製品リストコンポーネントに渡します。コンポーネントには4つの製品が表示されます。 ユーザーが別のフィリップスメーカーを選択した場合、Redisで2つのクエリを作成し、これらのセットを結合して、カタログに7つの要素を表示します。



さらに、ユーザーが別のフィルターグループからフィルターオプションを選択した場合、たとえば、赤色が表示されます。 サムスンとフィリップスのすべてを赤くしたいので、最初の2つのオプションを組み合わせて、それぞれ赤の携帯電話と交差させ、202、303の2つの商品を取得します。



この実装の機能-MySQLを使用するよりもはるかに高速ですが、1つだけあります。エンティティの変更ごとに必要です。 製品のプロパティが変更された場合-製品が見出しから見出しに移動し、メーカーの製品が変更され、製品が有効化/無効化され、フィルターが作成、変更、削除された場合、これらすべてのセットを再計算する必要があります。 つまり これが私たちがしなければならない主な仕事であり、キューを通して実装しています。 RabbitMQメッセージブローカーを使用してセットを再計算します。これについては後で説明します。



キューといえば、「ウサギ」について話します。 RabbitMQは、AMQPプロトコルを介してメッセージングシステムを実装するプラットフォームです。 このサービスの機能は、信頼性、柔軟なメッセージルーティングシステム、クラスタリングのサポート、キューのステータスを確認できるさまざまなプラグインのサポート、キュー内のメッセージ数の確認、処理するコンシューマー、カスタムプラグインを作成して標準動作を変更することですブローカー。 ErlangのRabbitMQによって書かれました。 また、Java、Ruby、Python、.NET、PHP、Perl、C / C ++など、ほとんどの言語の「ウサギ」を操作するクライアントがいます。ウサギのWebサイトには、優れたチュートリアルと十分に文書化された機能があります。 各言語には例もあり、すべてがアクセス可能な言語で記述されています。



「ウサギ」を使用する際の基本的な概念は何ですか？



「ウサギ」に含まれる交換機の種類、ルーティングの進行状況について説明し、プロデューサーからコンシューマーへのメッセージがワークフローでどのように発生するかを示す図を示します。







プロデューサー（P）は、メッセージを送信するプログラムです。 メッセージはキューに直接入らず、エクスチェンジャー-Exchange（X）を経由します。エクスチェンジャーはこのメッセージまたはそのメッセージを送信するキューをすでに決定しています。 メッセージが格納されるキューが存在することは明らかであり、コンシューマ、これらのキューを読み取り、何らかの方法で処理するプログラムもあります。



最も単純なワークフロー-プロデューサーは交換機にメッセージを送信し、交換機はバインディングキーを使用してメッセージを送信するキューを決定し、コンシューマーは既に特定のキューを読み取っています。 キューからメッセージを受信すると、コンシューマーは、はい、受信、処理、メッセージをキューから削除できることを確認できます。 メッセージが「ウサギ」で処理されることを確認するメカニズムがあります。 消費者がメッセージを受け取って突然落ちた場合、メッセージが処理されたことを確認するまでメッセージはキューに残ります。



キューからの読み取りを設定して、コンシューマーが取得したメッセージが常にピックアップされるようにすることができます。 自動確認をtrueに設定し、重要でない場合は何も確認する必要はありません。



どの交換機がありますか？







最初のタイプは直接交換であり、その本質は次のとおりです。交換機はさまざまなルールのキューにバインドできます。 たとえば、ここでは、バインドキーエラーを介してExchangeにバインドされた上位キュー、および警告キーを介してエクスチェンジャーにバインドされた下位キューがあります。 交換機にメッセージを送信するプロデューサーは、メッセージのルーティングキーを渡します。たとえば、スライド上で、赤いメッセージにルーティングキーエラーがあり、バインドキーと一致する場合、リストの先頭に移動します。 メッセージに警告ルーティングキーがある場合、つまり ルーティングキーと特定のキューのバインディングキーとの厳密な一致。 異なる消費者に異なるメッセージを提供できます。



次のタイプの交換機はファンアウトです。







ここでのポイントは、どのキーに関係なくキューがエクスチェンジャーにバインドされ、バインドされるだけで、FanoutタイプでExchangeに送信されるすべてのメッセージがこのエクスチェンジャーにバインドされるすべてのキューに分類されることです。 したがって、1つのメッセージを送信することで、いくつかの情報を複数のサービスに送信する必要がある場合、Fanoutタイプの交換機を使用でき、メッセージは両方の消費ルームに分類されます。



次のタイプは、タイプがトピックの交換機です。







このタイプのエクスチェンジャーは、キーを使用してキューにバインドできます。キーには、アスタリスク（*）やラティス（＃）などの特殊文字を含めることができます。 これはどういう意味ですか？ バインディングキーのアスタリスクは1つの単語に置き換えることができ、ラティスは0個以上の単語に置き換えることができます。



この例では、Q 1キューは* .orange。*キーを使用してバインドされ、2番目のキューは2つのキーにバインドされます。 彼女は怠zyで始まるメッセージを受信し、残りは重要ではありません-好きなだけ他の単語があり、単語はドットで区切られ、2番目のバインディングキーは3単語です：最初の2つは重要ではなく、重要なのは「うさぎ。」



プロデューサーがスライドの最初の例のようなルーティグキーを持つメッセージを送信した場合、3つの単語で構成され、2番目の単語にはオレンジが含まれ、最後にウサギという単語があるため、両方のキューに分類されます。



実際のRabbitMQ。



たとえば、Redis-eのデータを再計算する場合（上記参照）、「ウサギ」を多く使用します。 つまり データを変更する多くのプロデューサープロセスがあり、これらのコマンドをキューの変更に送信します。2つのキューはありません。さらに多くあり、コンシューマは既に特定のメッセージを処理しています。 たとえば、アイテムAは無効になっているため、削除する必要があります。 JSONの形式でメッセージを送信し、次に消費者がそれを読み取り、Redisに接続し、そこにマスタースレーブレプリケーションがあり、それぞれマスターに書き込み、このJSONを解析し、そのようなものを削除する必要があることがわかりますそのようなカテゴリやそのようなセットから商品を削除し、フロントエンドはすでにスレーブのRedisから読み取り、更新されたデータを表示します。



実際、これがこれらの単純なツール-キャッシングとキュー-について伝えたかったことのすべてです。 質問がありますか？



聴衆からの質問 ：キャッシュの「ディケイ」がどのように実装されているか、具体的に教えてください。 どのように計算し、どのような値を設定しますか？ たとえば、製品カードを表示し、たとえば価格が変更された場合、キャッシュはどれくらいの速さで更新されますか？



回答 ：実際、すべてがそこで単純です-価格を更新するとき、キャッシュは更新しません、タスクの条件に従って特に重要ではありません、1時間だけキャッシュします、1時間後にこのデータは「悪くなります」、すなわち 価格は1時間で更新されます。



聴衆からの質問 ：それでは、より関連性が高いでしょうか？ プロモーション価格で販売されている製品があるとします。明らかに、すぐに出荷されます。 次に、どのくらいの頻度で残高を更新しますか？



回答 ：残高をキャッシュしません。 , , , memcached , ID, .



: — ?



: , . , memcached, memcached. .



: - , , ? ?



: .



: ?



: 20- «». , Redis, , , , , , … 20 , . , MySQL. , , , - .



: Redis-. ?



: , , ID , .. , ID .



: — memcached, Redis. , , , memcached , ?



: emcached , ngnix , memcached , Redis , , Redis. , , , popup. Redis , , , , popup, memcached, PHP, , framework, Redis. , . , Redis- , framework, MySQL Redis memcached.



: , - ?



: , , «», , munin- - .



: , , , , . . , , , memcached , , ?



: , , , -



: RabbitMQ , , «» - ?



: , . callback, , .



: RabbitMQ? , , , , , , , , ?



: , , , , . , .



: , RabbitMQ , , ?



: , , .



: , Redis , memcached. memcached ?



: , Redis , memcached, Redis, memcached. , Redis-e . - , , , memcached, . , , .



: memcached? 10%, 20%, 50%?



: , , — - , - , Redis 10% , memcached, . , , . , . .

— HighLoad++ .



- HighLoad.Guide — , , , . 30 . !



— " - ", , HighLoad++ Junior . , , , —