(1) キャッシュの有効期限が切れたばかりです (2) A にデータベースにクエリを実行して古い値を取得するようリクエストします。 (3) B に新しい値をデータベースに書き込むように要求します。 (4) Bにキャッシュの削除を依頼する (5) A に、見つかった古い値をキャッシュに書き込むように要求します。

ただし、2 と 3 のうち 3 が 2 より速い場合に限り、B が最初にキャッシュを削除し、A が古い値でキャッシュを書き込みます。

実際、データベースへの書き込みは読み取りよりもはるかに遅いため、遅い SQL は避けてください。

(1) まずはキャッシュを削除する (2) データベースを再度書き込みます (この 2 つの手順は前と同じです)。 (3) 1秒スリープして再度キャッシュを削除

非同期二重削除を使用する

本数と長さを確認する

キーまたはキーの下の特定のフィールドが存在するか、含まれるか、追加、増加または減少するか

削除、指定位置削除、削除して取得

無料のテーマ

鍵

セット

リスト

注文されたコレクション

取引

ハッシュ

無料のテーマ

文字列サイズを拡張する必要がある場合、1M 未満の場合は 2 倍になり、1M を超える場合は毎回 1M ずつ拡張されます。最大長は 512M です。

自己インクリメント値が最大値を超える場合、エラーが報告されます。

コンテナタイプのデータ構造の場合、コンテナが存在しない場合はコンテナを作成し、要素が存在しない場合はコンテナを削除します。

ロックを取得

ロックを解除する

a) Redis でマスターとスレーブの切り替えが発生すると、一部のロックが失われる可能性があります。

Zookeeper が実装する分散ロックには、実はキャッシュ サービスほどパフォーマンスが高くない可能性があるという欠点があります。ロックの作成と解放のプロセス中は常に、ロック機能を実装するために一時ノードを動的に作成および破棄する必要があるためです。 ZK でのノードの作成と削除はリーダー サーバーを通じてのみ実行でき、データはすべてのフォロワー マシンと共有されません。 同時実行の問題にはネットワークのジッターが含まれる可能性があり、クライアントと ZK クラスター間のセッション接続が切断されます。このとき、ZK クラスターはクライアントがダウンしていると判断し、一時ノードを削除します。

Redis は公平性を実現するのが難しい

分散バージョンのアルゴリズムでは、N 個の Redis ホストがあると仮定します。ノードは完全に独立しているため、レプリケーションやその他の暗黙的な調整システムは使用しません。単一インスタンス内でロックを安全に取得および解放する方法を説明しました。アルゴリズムがこのメソッドを使用して単一インスタンスでロックを取得および解放することは当然のことだと考えています。この例では、適切な値である N = 5 を設定しているため、ほぼ独立した方法で障害が発生することを保証するために、異なるコンピューターまたは仮想マシン上で 5 つの Redis マスター サーバーを実行する必要があります。 ロックを取得するには、クライアントは次の操作を実行します。 1. 現在時刻をミリ秒単位で取得します。 2. すべてのインスタンスで同じキー名とランダムな値を使用して、N 個すべてのインスタンスで順番にロックを取得しようとします。ステップ 2 で、各インスタンスにロックが設定されると、クライアントはロックの自動解放時間の合計と比較して短いタイムアウトを使用してロックを取得します。たとえば、自動解放時間が 10 秒の場合、タイムアウトは約 5 ～ 50 ミリ秒の範囲になります。これにより、クライアントが長期間ブロックされたままになり、Redis ノードとの通信を試行して失敗することがなくなります。インスタンスが使用できない場合は、できるだけ早く次のインスタンスとの通信を試行する必要があります。 3. クライアントは、ステップ 1 で取得したタイムスタンプを現在時刻から減算して、ロックの取得に必要な時間を計算します。クライアントが大部分のインスタンス (少なくとも 3 つ) でロックを取得でき、ロックを取得するまでに経過した合計時間がロックの有効時間未満である場合に限り、ロックは取得されたとみなされます。 4. ロックが取得された場合、その有効時間は、ステップ 3 で計算された、初期有効時間から経過時間を引いたものとみなされます。 5. クライアントが何らかの理由でロックの取得に失敗した場合 (N/2 1 インスタンスをロックできない、または負の有効期限がある場合)、クライアントはすべてのインスタンスのロックを解除しようとします (ロックできないと判断した場合でも)。

ノードがハングアップしても、ロックがプリエンプトされる危険はありません。

集団的な失敗を避けるために、失敗時間にランダムな値を設定します。

記録ユーザーの投稿IDリストをクイック表示します。

ホットリスト投稿IDリストを記録します。 全体ホットリスト、カテゴリホットリスト。

1 対多の記録に使用され、多数のパーティーを厳密に繰り返すことはできません。

ユーザーまたはシステム全体に関連する可能性のある特定のコレクションを記録します。

投稿に対する「いいね！」、コメント、クリックの数を記録します。

投稿のタイトル、要約、著者、表紙情報などを記録します。

最近の注目の投稿コンテンツをキャッシュします (投稿コンテンツは非常に大きいため、データベースから取得するのには適していません)。

投稿の関連記事のリストを記録し、内容に基づいて関連投稿を推奨します。

主にメモリを節約するために、ブール配列またはカスタム ビット配列として使用されます。

重複排除後の統計値を大まかに計算するために使用されます。

加算して合計数を取得することはできますが、特定の値が存在するかどうかやすべての要素を取得することはできません。

重複した要素を削除するために使用されます。

プロジェクトが大きくなく、メンテナンスコストが高くない場合は、redsi-cell を直接使用できます。それ以外の場合は、各サービスノードに対するきめ細かい制御を検討して、対応する負荷分散戦略を使用して実装することができます。

zset とスコアを使用して時間ウィンドウを一周し、その時間ウィンドウ内で同じユーザーに対して同じ動作が発生した回数をカウントします。現在の制限数が大きすぎる場合 (1 秒あたり 1,000 回など)、適用できない可能性があります。 。

CL.スロットルテスト 100 400 60 3

1: 成功かどうか、0: 成功、1: 拒否 2: トークンバケットの容量、サイズは初期値1です 3: 現在のトークン バケットで使用可能なトークン 4: リクエストが拒否された場合、この値はトークンがファネル バケットに再度追加されるまでにかかる時間を示します。単位: 秒。これは再試行時間として使用できます。 5: トークン バケット内のトークンがいっぱいになるまでの時間を示します。

ファンネルアルゴリズム

通常のリンク リストによる追加のメモリ オーバーヘッドを避けるために、圧縮されたリンク リストまたは配列で構成されます。

メモリをできるだけ節約するように設計された二重リンクリスト

文字列または整数を格納する

値の保存に可変長エンコーディングを使用してメモリを詳細に節約

ハッシュ、リスト、Zset の基礎となるデータ構造の実装

特徴

1) 高いパフォーマンス要件が必要なシナリオで ziplist を使用する場合、長さが 1000 を超えないようにして、各要素のサイズを 512 バイト以内に制御することをお勧めします。

スキップ リストは、O(logN) の平均検索と最悪の場合の O(N) の複雑さの検索をサポートします。

ジャンプ台の代わりに木やバランスの取れた木を使ってみてはいかがでしょうか?

圧縮されたリンク リストは、ポインタを使用してリンクされ、リンク リストになります。

各 ziplist のデフォルト値は 8k (構成可能) です。

2) info Commandstats コマンドを使用して、各コマンドの呼び出し数を含む平均コマンド時間を取得します。 、かかった合計時間、平均かかった時間 (マイクロ秒単位)。

Redis のレプリケーション機能は、同期 (sync) とコマンド伝播 (コマンド伝播) の 2 つの操作に分かれています。

読み取りと書き込みの分離は、大規模なアクセス (単一の Redis マシンが非常に遅く感じるほど大規模なアクセス) に適しており、書き込み操作は読み取り操作よりもはるかに小さくなります。

読み取りリクエストの数が書き込みリクエストをはるかに超える場合、クラスターのデータ コピーのコストは読み取りリクエストのコストよりも大幅に低くなります。同時に、データの不整合をある程度許容できるのであれば、読み取りと書き込みを分離することができます。

1. すべての Redis ノードは相互接続され (PING-PONG メカニズム)、バイナリ プロトコルが内部で使用されて伝送速度と帯域幅が最適化されます。

2. ノードの障害は、クラスター内のノードの半分以上が障害を検出した場合にのみ有効になります。

3. クライアントは中間のプロキシ層を必要とせず、redis ノードに直接接続されます。クライアントはクラスター内のすべてのノードに接続する必要はなく、クラスター内の使用可能なノードに接続するだけです。

4. redis-cluster は、すべての物理ノードを [0-16383] スロット (必ずしも均等に分散されているわけではありません) にマップし、クラスターはノード<->スロット<->値を維持する責任を負います。

5. Redis クラスターは、R​​edis クラスターにキーと値を配置する必要がある場合、CRC16(key) mod 16384 の値に基づいて 16384 個のバケットに事前に分割されます。

各 Redis インスタンスは他のノードの存在を認識します。

1. クライアントはメインサーバーノード B に書き込みます 2. メイン サーバー ノード B がクライアントに確認の応答を返します。 3. マスター サーバー ノード B は、そのスレーブ サーバー B1、B2、および B3 に書き込みを伝播します。

ステップ 2 の後、スレーブ サーバーからデータが送信されず、B がハングアップした場合、キーは失われます (キーは障害時に確実に失われます)。

選択プロセスには、クラスター内のすべてのマスターが参加します。マスター ノードの半分以上が (cluster-node-timeout) を超えて障害が発生したノードと通信する場合、そのノードには障害があるとみなされ、フェイルオーバー操作が自動的に行われます。引き金になった。

(2): クラスター全体が使用できなくなる (cluster_state:fail) のはいつですか? a: クラスター内のいずれかのマスターが停止し、現在のマスターにスレーブが存在しない場合、クラスターは失敗状態になります。これは、クラスターのスロット マッピング [0-16383] が完了していない場合に失敗状態になると理解することもできます。 b: 障害状態になっているスレーブ クラスターがあるかどうかに関係なく、クラスター内のマスターの半分以上が停止した場合。

クラスターが使用できない場合、クラスター上のすべての操作が使用できなくなり、((error) CLUSTERDOWN クラスターがダウンしています) エラーが受信されます。

1. オフライン マスター ノードのすべてのスレーブ ノードが、新しいマスター ノードを選択するために選出されます。 2. 選択したスレーブ ノードは、slave no one コマンドを実行し、新しいマスター ノードになります。 3. 新しいマスター ノードは、オフライン マスター ノードへのすべてのスロット割り当てを取り消し、これらのスロットを自分自身に割り当てます。 4. 新しいマスター ノードはクラスターに pong メッセージをブロードキャストします。この pong メッセージにより、クラスター内の他のノードは、ノードがスレーブ ノードからマスター ノードに変更されたこと、およびマスター ノードがサーバーを引き継いだことをすぐに知ることができます。元々はオフラインだったスロット。 5. 新しいマスター ノードは、処理を担当するスロットに関連するコマンド要求の受け入れを開始し、フェイルオーバー操作が完了します。

1. スレーブ ノードは、複製するマスター ノードがオフラインになったことを検出すると、スレーブ ノード (ここでリクエストを行う複数のスレーブ ノードが存在する可能性があります) はクラスターにクラスターにブロードキャストし、投票権 (スロットの処理を担当) を要求します。マスターノードはこのノードに投票します。 2.cluster_type_failover_auth_request メッセージを受信したマスター ノードは、独自の条件 (開始投票ノードの現在のエポックが投票ノードの現在のエポック以上であること) に基づいて、スレーブ ノードが新しいマスター ノードになることに同意するかどうかを判断します。 ) 一致すると、cluster_type_failover_auth_ack メッセージが返されます。 3. ノードからcluster_type_failover_auth_ackメッセージを受信すると、投票数が1増加します。 4. スレーブ ノードの投票がクラスター内のマスター ノードの半分以上 (N/2 1 以上) の場合、このノードが新しいマスター ノードになります。 構成サイクル中に十分な投票を受け取ったスレーブ ノードがない場合、クラスターは新しい構成サイクルに入り、新しいマスター ノードが選出されるまでここで選挙が保持されます。

すべてのスレーブ ノードは、自分がマスターになれるかどうかについて意見を求めることができ (投票する人は自分のより大きなノードにのみ投票します)、そのうちの半分以上が (n 1)/2 になることができます。

たぶん選べない

1. 現在、同じスロット上のキーのバッチ操作のみがサポートされています。 2. 現在、同じスロット上のキートランザクションのみがサポートされています。 3. データベース 0 のみを使用できます (各 Redis インスタンスには 16 のデータベースがあり、select {index} コマンドで切り替えることができます)。 4. 大きなキー (ハッシュ、リストなど) を異なるノードにマッピングすることはできません。 5. 現在、クラスターのマスター/スレーブ レプリケーションは 1 つのレベルのみをサポートし、ネストされたツリー構造はサポートしません。

ステップ

各ノードは、各スロットに対応するクラスタ ノードを知っています。

ノードはコマンド要求を受信すると、それを自分で処理できるかどうかを問い合わせ、処理できる場合は、移動エラーを返し、正しいノード IP とポート番号を返します。クライアントがそれを実行するようにガイドし、その後のクライアントのすべての操作 キーが実行されると、移動されたエラーによって提供されたノードに移動します。

Codis の Codis ダッシュボードがスロット情報を変更すると、他の Codis ノードが ZooKeeper スロットの変更を監視し、適時に同期します。図に示すように:

zk はスロット情報の同期を担当します。

複数のキューを使用して優先キューを実装します。異なる優先タスクは異なるキューに入ります。

同時に、コンシューマがキューからデータをフェッチするとき、優先順位を付けて複数のキューからデータをフェッチすることがサポートされます。

複数のコンシューマを起動するということは、データを取得するために複数のクライアントを起動することを意味します。

使用

危険

1. 指定されたリストにポップされる要素がない場合、待ち時間がタイムアウトするかポップ可能な要素が見つかるまで、接続は BRPOP コマンドによってブロックされます。 2. 複数のキー パラメータが指定された場合、各リストはパラメータ キーに従って順番にチェックされ、空ではない最初のリストの末尾要素がポップアップ表示されます。 また、BRPOP は、ポップアップ要素の位置を除き、BLPOP と同じように動作します。

リストにタスクがない場合、接続はブロックされます 接続ブロックにはタイムアウトがあります。タイムアウトを 0 に設定すると、メッセージが表示されるまでワイヤレスで待機できます。

これは、A と B の間の 2 つの企業間でのサブスクリプションと出版に適しています。複数のビジネスラインが異なる消費者を意味する場合、より困難になります。

ack実装