ディレクトリ
- スクラッチ
- ネイティブメモリキャッシュに基づいて、
- Redisのサーバー・サイド
- クライアントのRedis
- 概要
のは、Redisのを見て何を見てみましょうか？
公式の説明の概要：のRedisはBSDをベースとしたオープンソースプロジェクトでは、システムメモリ内のデータ記憶装置の構造は、あなたが使用するデータベース、キャッシング、およびメッセージングミドルウェアとして使用することができます。
Redisのは、文字列、リスト、ハッシュ、セット、セットをソートし、ビットマップをサポートし、地理空間インデックスと他のデータ型hyperloglogs。
また、それはように、パブリッシュ/サブスクライブ、クラスタのRedis自動断片化だけでなく、取引を達成するために、Redisのセンチネルて高可用性を実現するために、複製、LUAスクリプト、LRU、総務などの自動フェイルオーバーを内蔵、およびました。
要約すると、Redisのは、これらの機能が使用されている理由を、混乱して最初に会った、機能豊富なを提供しますか？どのような問題が解決されましたか？どのような状況下では、対応する関数を使用するのでしょうか？
、ここでは最初から、ラフな説明へのステップの進化によって、次のステップを心配しないでください。
1、最初から
初期の需要は私達が熱いニュースのAPIのリストを提供している、非常に簡単です：
- http://api.xxx.com/hot-news
APIの消費者は、各要求は、結果を返すために、約2秒であることを訴えました。
、最大エージング= 600：その後、我々は消費者の知覚APIのパフォーマンスを改善する方法を見て始めた、とすぐに、最もシンプルかつ粗製の最初のプログラムが出てきた：HTTPベースのAPIプラスのキャッシュ制御キャッシュ制御に対応して消費者は10分間応答をキャッシュできるように、それは、あります。
もし効果的に（10分以内）、知覚パフォーマンスを向上させることができ、応答のキャッシュ制御情報の消費者APIを有効活用。
しかし、2つの欠点があります。
- 最初は、APIの消費者は、古いデータを得ることができ、キャッシュの10分以内に効果を取ることです。
- 第二は、ナ緩和的、クライアントAPIは、APIへのキャッシュの直接のアクセスを無視した場合は、まだ2秒を必要としていることです。
図2に示すように、ユニットに基づいて、キャッシュメモリ
問題を解決するために、まだ調査の後、主としてSQLの使用にホットなニュースは、ほぼ2秒の間に消費されます、2秒APIを呼び出す必要があります。
それ以来、私たちは、シンプルで粗溶液を考えている、つまり、SQLの結果は（1分のキャッシュ有効時間を設定）現在のAPIサーバーにキャッシュメモリに直接照会します。1分以内後続の要求は、直接キャッシュを読んで、もはやそれはSQLを実行するために2秒かかりません。
今回のAPIは、毎秒100個の要求を受けた場合は、1分2秒以上かかり混雑要求の前にわずか2秒で応答場合、58秒の後続のすべての要求をしても行うことができ、6000です、2秒を待たずに。
その他のAPIはほとんどの友人は、それは良いアイデアです見つけ、すぐに我々はフルにAPIサーバーのメモリを見つけました。。。
Redisのサーバーの3
APIサーバーのキャッシュ・メモリが満たされているとき、私たち希望のための別の解決策を見つけなければなりませんでした。
最も直接的なアイデアは、我々はこれらのキャッシュはメモリ構成にくらいの、専用のサーバー上でそれに投げ込まれている入れています。
その後、我々はRedisの中でロックされました。。。ここでは説明しない展開のRedisの設定方法については、公式の詳細な説明をRedisの。その後、我々はRedisのサーバーとして別のサーバーを使用していた、サーバーのメモリ圧力APIは解決しました。
3.1持続性（永続性）
単月でのRedisのサーバーは、キャッシュのすべてが（Redisのデータは事のメモリに記憶されている）が失われる原因と、いつも機嫌が悪い、悪い気分のストライキで数日があります。
バックライン上のRedisサーバが、しかし突然、データの損失のメモリ、キャッシュ雪崩で、その結果、圧力APIサーバとデータベースまたはが出てくるので。
だから、Redisの永続化機能が便利になるこの時間は、あなたがキャッシュ雪崩の影響がもたらす緩和することができます。
Redisの持続性は、 Redisのが原因キャッシュミスを低減させる効果を最大化するために再起動したときにデータをロードし、ハードディスクにメモリ内のデータを書き込みますのRedisを指します。
3.2センチネル（センチネル）および複製（レプリケーション）
警告ストライキなしRedisのサーバーが面倒です。それでは、どのようにそれを行うには？
答え：バックアップ1、あなたはそれをハングアップします
それでは、どのようにバックアップマシンが元のサーバー、それの完全なバックアップであることを保証するために、どのように切り替える方法を、駅のRedisサーバがハングアップ知っているのですか？
今回はセンチネルする必要があるとレプリケーションを果たしました。
RedisのSentinelは、監視、アラート、および自動フェイルオーバー機能を提供し、複数のサーバを管理することができます。
レプリケーションは、複数のバックアップサーバを装備することができRedisのサーバーをさせるための責任があります。Redisのも、Redisの高可用性を確保するために、これらの2つの機能を使用します。また、SentinelはRedisの公開や機能を購読使用の関数です。
3.3クラスタ（クラスタ）
単一サーバーのリソースは常に、CPUリソースを頂いた、と私たちはメインからコピーすることができIOリソース、読み取りと書き込みの独立した、とCPUの圧力部分は、サーバからIOに転送されています。
しかし、メモリリソースをどのように行う、マスタースレーブモードが行うバック同じデータをバックアップし、横方向に拡張メモリをすることはできません。単一のマシンのメモリが唯一の治療法を増やすことができますが、制限が常にあります。
だから私たちは私たちが拡張することができますソリューションを必要としています。
究極の目標は、これらすべてのサーバーが全体を構成するように、各サーバの両方が、その一部についてのみ責任があります。
消費者の外側には、分散サーバのこのグループは、中央サーバのようなものです。
Redisのはtwemproxyそこに公式プログラムの前に配布され、2つのオプションがCODIS、両方のスキームは、プロキシを配布する全体的に依存しています
それ自体がRedisの事を、分散関係が、原因であることがtwemproxyとCODISを参照していません。
クラスタプログラムのRedisの関係者は、彼らはもはや、追加のコンポーネントが要件の完了とは独立して配布することができる必要はありませんので、すべてのRedisのサーバーを行って、この事の分散一部を与えられています。
ここでは、我々は最終的にここに配布さを見て、これらのプログラムのやや優れて気にしないそれらの事に対処するのですか？
問題を解決するため、最後に処理され、配布さtwemproxyがクラスタ・ロジックのこの部分の独立した処理をCODISとRedisのサービスにおけるロジックのこの部分に統合されていますか？
私たちは前に言ったように、外の世界での分散サービスは、集中サービスとしてのようなものです。
これを行うには、その後、解決すべき問題に直面：増加または分散サービス内のサーバーの数を減らし、この消費の顧客サービスの終了は、という点では意味ないはずです。
それはそうならば、あなたはもはや交換を障害することができない、サーバーを追加することはできないだろうから、クライアントは、死の1つのサーバプラットフォームのアップに身を結ぶ、分散サービスに浸透できないことを意味します。
この問題を解決する方法は2つあります。
最初の方法我々が使用されるこの特定の依存、即ちtwemproxy方法を分離する中間層を追加することは、最も直接的。
すべてのクライアントが唯一の（しかし、あなたはtwermproxyは、単一のポイントになりますでしょう）、この場合の各Redisのサーバーがそれらの間で、独立しており、この依存性を隔離するために、それを通してredsiサービスを消費するためにそれを使用できるように、彼らはお互いの存在にお互いを知りません。
第二の方法は、彼らが必要とする操作を完了するためにリダイレクト機構を介してクライアントを導くために、サーバーが互いの存在をRedisの知っていることです。
クライアントは、1つのRedisサーバにリンクされているような、私はこの操作を実行することを、Redisのサーバーは、クライアントが別のものを求めるできるように、あなたがクライアントにサーバの動作に関する情報を完了することができます、この操作を完了自身ができましたサーバー
今度は、すべてのRedisのサーバーは、情報の分散サーバ情報の完全なコピーを維持するために、またはクライアントは、クライアントがそれの操作を実行したいと他のサーバーを行ったか知っている必要があります。
これはそんなに上記の大部分を説明し、私はそれが最初の方法または第二の方法を見つけていないかどうか、ということがある一般的なものがあるだろう情報を提供することができ、すべてのサーバーとサービスでサービスを分散は、 。この情報は、どのような場合に存在する必要があります。
第1の相違点は、複数の独立したRedisのバックエンドサーバーを調整するためにこの情報を使用し、これは情報の別の部分を管理するための方法であることです。
第二の方法は、それぞれのRedisサーバせることで、お互いの存在を知って、この情報を所有しており、同じ目的を達成するための方法、利点は、もはや事のこの部分を処理するための追加コンポーネントの必要はありません。
概念のRedisのクラスタ詳細な実装は、即ち溝が以前16384を分配ハッシュ溝を使用することです。
CRC16（キー）％16384操作が溝に対応が得られるため、クライアントのキー。
Redisの内の各サーバは、我々は、移行とそれに対応するデータを溝前に、新しいサーバーが追加または削除されているスロットの部分を担当するサーバです。
各サーバーは、完全な情報とそれに対応する溝サーバを保持している間、クライアントにサーバーを作ることは、リダイレクト処理を要求することができます。
4つのクライアントのRedis
第3のセクションは、サービスの上端に焦点を当ててRedisの進化のステップで、彼は、高可用性、分散、分散ストレージシステムへと進化し、スタンドアロンのサービスからどののRedisを説明する図です。
このセクションでは、Redisのサービスを利用することができ、クライアントに懸念しています。
4.1データ型
最も基本的から一般的に使用されるデータ構造の複雑な文字列に豊富なデータ型のRedisのサポートは、サポートされています。
- 文字列：基本データ型、バイナリセーフな文字列、最大512M。
- リスト：追加の順序に従って秩序を維持するために文字列のリスト。
- SET：文字列の順不同のコレクションは、繰り返し要素が存在します。
- SETソート：ソートされた文字列のコレクション。
- ハッシュ：値の1種類のキーセット。
- ビットマップ：ビット単位で詳細な動作について説明します。
- hyperloglog：確率ベースのデータ構造。
データ型の多くは、主に、さまざまなシナリオのニーズをサポートするために、もちろん、各タイプは、異なる時間複雑性を有します。
実際には、サーバ上で動作命令を実行することによって、設定された標準に対応したこれらの複雑なデータ構造は、結果セットは、サーバがクライアントの使用を簡素化したいとの間で低減され、それはまた、ネットワークのパフォーマンスを向上させることができます。
そのようなリストのデータ構造が存在しない場合たとえば、あなただけの文字列にリストを保存することができ、クライアントは完全なリストを取得し、その後のRedisに提出操作を完了、廃棄物の多くを持っています。
4.2トランザクション
上記のデータ型は、各データ型が動作するために、独自のコマンドを持ち、多くの場合、我々は複数回のコマンドを実行する必要があると同時に、それが成功するか失敗する必要があります。
Redisのトランザクションサポートが順に一度実行複数のコマンドをサポートするために、そのアトミック性を保証するために、すなわち、能力、需要のこの部分に由来します。
4.3 Luaのスクリプト
私たちは、より複雑な操作の終わりに1回限りのサービスを実行する必要がある場合、取引に基づき、それは時間を延長すると同時に満了した場合、その後、LUAは、例えば、特定のキャッシュを取得するには（便利ラフトすることができます（一部のロジックの判断が含まれています） ）。
Redisのは、LUAスクリプトの原子性を保証する、特定のシナリオの下で、それは、トランザクション関連のコマンドが提供するRedisの置き換えることができます。
4.4パイプライン
Redisのクライアントとサーバを接続したときにTCPベースの接続のみコマンドを実行することができ、デフォルトでは毎回、ので。
これは、オーバーヘッドのTCP接続の一部を保存するように、パイプの使用は、コマンド処理を複数に接続されていることができます。
違いは、管路およびトランザクションは、通信のコストを節約することであるということです、それは原子性を保証するものではありません。
4.5分散ロック
公式はRedlockアルゴリズムを推奨し、特定のキーにロックされ、その後、ランダムな値を設定し、その文字列型、。
LUAスクリプトを使用してロックのキャンセルは最初の比較を実行し取得する場合は、し、キーを削除します。
次のように具体的なコマンドは次のとおりです。
概要
抽象的なレベルとその存在の目的からRedisの下に様々な機能を説明することに焦点を当て、そして何気にしないBenpian具体的な詳細はい。
だから、私たちは特定のシーンで、より適切なソリューションを選択し、技術的な詳細に限定されないことができます抽象的な概念レベルに応じて、問題の解決に集中することができます。