MindMap Gallery Redis データ構造ナレッジ フレームワークの学習
Redis には多くのデータ型があり、異なるデータ型には同じメタデータが記録されるため、Redis は RedisObject 構造を使用してこれらのメタデータを均一に記録します。Long 型を保存する場合、RedisObject ポインターは整数に直接割り当てられます。
Edited at 2022-11-14 13:53:00Redis データ構造ナレッジ フレームワークの学習
キャッシュの一貫性の問題
まずデータベースを更新してからキャッシュを削除します
(1) キャッシュの有効期限が切れたばかりです (2) A にデータベースにクエリを実行して古い値を取得するようリクエストします。 (3) B に新しい値をデータベースに書き込むように要求します。 (4) Bにキャッシュの削除を依頼する (5) A に、見つかった古い値をキャッシュに書き込むように要求します。
上記はダーティデータの原因となります
ただし、2 と 3 のうち 3 が 2 より速い場合に限り、B が最初にキャッシュを削除し、A が古い値でキャッシュを書き込みます。
実際、データベースへの書き込みは読み取りよりもはるかに遅いため、遅い SQL は避けてください。
まずキャッシュを削除してからデータベースに書き込みます
(1) まずはキャッシュを削除する (2) データベースを再度書き込みます (この 2 つの手順は前と同じです)。 (3) 1秒スリープして再度キャッシュを削除
非同期二重削除を使用する
基本操作
共通操作
本数と長さを確認する
キーまたはキーの下の特定のフィールドが存在するか、含まれるか、追加、増加または減少するか
削除、指定位置削除、削除して取得
無料のテーマ
データの種類
鍵
削除、存在、表示、パターンによる照合 (大規模なコレクションにはパフォーマンスの問題が発生します)、
スキャンはすべてのキーを反復します。
ソートリスト、設定
ある Redis インスタンスから別の Redis インスタンスへの移行
有効期限の設定、キャンセル、キーの残りの有効期限の取得
Redis が期限切れのキーを削除する方法 Redis キーを期限切れにするには、パッシブとアクティブの 2 つの方法があります。 一部のクライアントがそれにアクセスしようとすると、キーが検出され、アクティブに期限切れになります。 もちろん、これでは十分ではありません。期限切れのキーの中にはアクセスできないものもあります。これらのキーはいずれにせよ期限切れになるはずなので、時間指定されたランダム テストによってキーの有効期限が設定されます。これらの期限切れのキーはすべてキー スペースから削除されます。 具体的には、これは Redis が 1 秒あたり 10 回実行することです。 関連する有効期限の検出について 20 個のランダム キーをテストします。 期限切れのキーをすべて削除します。 25% を超えるキーの有効期限が切れた場合は、手順 1 を繰り返します。 これは自明な確率的アルゴリズムであり、基本的な仮定は、サンプルがキー コントロールであり、期限切れのキーの割合が 25% 未満になるまで、つまり、特定の時点で期限切れの検出を繰り返し続けることです。期限切れのキーのほとんど 1/4 がクリアされます。
セット
Sdiff はセットに存在しない要素を取得します SDiff a b は a-b と同等です
Sdiff Store は差分セットをキーに保存します
キーに保存できる複数のセットの和集合を見つけます。
SInter は交差を取得します。 SInterStore は交差をキーに書き込みます。
リスト
BLOCK 操作。キューの先頭と末尾の値をブロックします。
複数のキューから値を取得するように指定できます
キューが空の場合、クライアントは書き込みがあるまでブロックされます。タイムアウトを指定し、タイムアウト後に nil を返すことができます。
ブロック操作により公平性が確保される
Redis 2.4 と 2.6 は異なります。a、b、c などの複数の値が同時に書き込まれると、キーがブロックされているクライアントは 2.4 では a を受け取り、2.6 では c を受け取ります。
サーバーから値を削除した後、値が処理される前にクライアントがハングアップすると、RabbitMQ のメッセージ確認メカニズムでこの問題を解決できます。
List のブロック操作を同じトランザクション内の他のデータ型のアトミック操作と組み合わせて使用すると、クライアントにブロック動作を提供できます。
公平な分散ロックを実現することは可能でしょうか?
JavaのListで提供される操作と同様に、特定の範囲の値をインターセプトするためにLTrimが追加されます。
リストから最後の要素を削除し、別のリストに入れます。
無料のテーマ
注文されたコレクション
SUM、MIN、MAX をサポートする複数の順序付きセットの和集合に対してリデュース操作を実行できます。
順序付きセット内のキーのランキングを返します。
順序付きセットで特定の範囲の値を取得できます。また、最小スコアと最大スコアを指定して、ページ内のこの範囲のセットをクエリすることもできます。
コレクションを反復処理する
取引
時計
WATCH コマンドは、1 つ以上のキーを監視できます。キーの 1 つが変更 (または削除) されると、それ以降のトランザクションは実行されません。監視は、EXEC コマンドが実行される前に値が変更されるまで継続されます。これは、実行中の Redis チェックと同等です。
WATCH コマンドの機能は、監視対象のキー値が変更された場合に後続のトランザクションの実行を阻止することだけであるため、他のクライアントがキー値を変更しないことを保証することはできません。したがって、一般に、WATCH コマンドを再実行する必要があります。関数全体が失敗した後の EXEC の実行。ループ付きで保証
EXEC コマンドの実行後、すべてのキーの監視がキャンセルされます。トランザクションでコマンドを実行したくない場合は、UNWATCH コマンドを使用して監視をキャンセルすることもできます。一部のビジネス シナリオでは、監視後に必ずしもトランザクション操作を実行するとは限りません。
Watch コマンドは、このキー値が変更されている限り、その後の有効な変更は有効になりません。通常、このメソッドは、exec が空のコレクションを返した場合、操作は失敗したと見なされます。
Exec は実際にトランザクション内のすべての命令を実行し、watch コマンドをクリアします。
Exec コマンドの応答は配列であり、コマンドの実行順序と一致します。
トランザクション内の 1 つまたは一部のコマンドが実行に失敗した場合でも、トランザクション キュー内の他のコマンドは引き続き実行されます。Redis はトランザクション内のコマンドの実行を停止しません。
トランザクションが EXEC を実行する前に、キューに入れられたコマンドでエラーが発生する可能性があります。たとえば、コマンドによって構文エラー (パラメータの数が間違っている、パラメータ名が間違っているなど) が発生する場合があります。この場合、クライアントはトランザクションの実行を停止します。
Mutil コマンドの先頭から exec コマンドまでに実行されたすべてのコマンドはトランザクション キューに入ります。
ハッシュ
存在するかどうか、追加、削除、すべてのキー、値の取得、ハッシュ コレクションの反復
キーのハッシュ値をインクリメントします。キーが存在しない場合は、値を 0 に設定します。
無料のテーマ
データ構造の落とし穴
文字列サイズを拡張する必要がある場合、1M 未満の場合は 2 倍になり、1M を超える場合は毎回 1M ずつ拡張されます。最大長は 512M です。
自己インクリメント値が最大値を超える場合、エラーが報告されます。
コンテナタイプのデータ構造の場合、コンテナが存在しない場合はコンテナを作成し、要素が存在しない場合はコンテナを削除します。
分散ロック
単一ノード ソリューション (非レッド ロック)
ロックを取得
クラスターノードへのハッシュ
存在しない場合は、ロックパスを設定します。有効期限を設定します。
ロックはクライアント ID を設定する値です
ウォッチドッグを設定し、ロックを定期的に更新します。これは遅延キューを使用して実装できます。
ロックが取得されない場合は、ブロックして取得を待つことを検討してください。
ロックを解除する
有効期限が設定されていない場合、デッドロックの問題が発生します。
a) Redis でマスターとスレーブの切り替えが発生すると、一部のロックが失われる可能性があります。
zkと比較
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 対多の記録に使用され、多数のパーティーを厳密に繰り返すことはできません。
ユーザーまたはシステム全体に関連する可能性のある特定のコレクションを記録します。
ハッシュ
投稿に対する「いいね!」、コメント、クリックの数を記録します。
投稿のタイトル、要約、著者、表紙情報などを記録します。
最近の注目の投稿コンテンツをキャッシュします (投稿コンテンツは非常に大きいため、データベースから取得するのには適していません)。
リスト
投稿の関連記事のリストを記録し、内容に基づいて関連投稿を推奨します。
ビットマップ
主にメモリを節約するために、ブール配列またはカスタム ビット配列として使用されます。
ハイパーログログ
重複排除後の統計値を大まかに計算するために使用されます。
たとえば、Web サイトの UV では、繰り返しの訪問をフィルタリングする必要があります。
加算して合計数を取得することはできますが、特定の値が存在するかどうかやすべての要素を取得することはできません。
ブルームフィルター
重複した要素を削除するために使用されます。
存在するとしても、実際に存在するとは限らない 存在しないなら絶対に存在しない
未訪問のリソースをユーザーに推奨することを検討する
リソースを複数回再利用しないことを検討してください。
一定の失敗率を許容する必要があります。つまり、リソースにアクセスできない場合でも、アクセスされたものとみなされます。
複数のハッシュ アルゴリズムを使用し、キー マッピングのビットを 1 に設定します。
存在しないなら絶対に存在しない!!!!
コマンドはaddとexist(複数チェック可)のみです。
初期パラメータを使用してフィルタを設定できます。error_rate は、値が小さいほど容量が大きくなります。 初期サイズは推定合計金額です。合計金額は実際のシナリオに従って設定する必要があります。
Redis セル
プロジェクトが大きくなく、メンテナンスコストが高くない場合は、redsi-cell を直接使用できます。それ以外の場合は、各サービスノードに対するきめ細かい制御を検討して、対応する負荷分散戦略を使用して実装することができます。
zset とスコアを使用して時間ウィンドウを一周し、その時間ウィンドウ内で同じユーザーに対して同じ動作が発生した回数をカウントします。現在の制限数が大きすぎる場合 (1 秒あたり 1,000 回など)、適用できない可能性があります。 。
CL.スロットルテスト 100 400 60 3
テストキー容量 100 (最大同時実行数) 60 秒以内に最大 400 回 今回は 3 つの容量が適用されます。
1: 成功かどうか、0: 成功、1: 拒否 2: トークンバケットの容量、サイズは初期値1です 3: 現在のトークン バケットで使用可能なトークン 4: リクエストが拒否された場合、この値はトークンがファネル バケットに再度追加されるまでにかかる時間を示します。単位: 秒。これは再試行時間として使用できます。 5: トークン バケット内のトークンがいっぱいになるまでの時間を示します。
ファンネルアルゴリズム
特殊なデータ構造
圧縮されたリンクリスト
通常のリンク リストによる追加のメモリ オーバーヘッドを避けるために、圧縮されたリンク リストまたは配列で構成されます。
メモリをできるだけ節約するように設計された二重リンクリスト
文字列または整数を格納する
値の保存に可変長エンコーディングを使用してメモリを詳細に節約
各項目には、項目のデータ長とタイプをマークするための個別の桁数があります。
ハッシュ、リスト、Zset の基礎となるデータ構造の実装
特徴
1) 内部表現は、データがコンパクトに配置された連続メモリ配列です。
2) 二重リンクリスト構造をシミュレートし、O(1) の時間計算量で入力およびデキューできます。
3) 新しい削除操作にはメモリの再割り当てまたは解放が含まれるため、操作が複雑になります。
4) 読み取りおよび書き込み操作には複雑なポインターの移動が含まれ、最悪の場合の時間計算量は O(n2) です。
5) 小さなオブジェクトや長さの制限されたデータの保存に適しています。
1) 高いパフォーマンス要件が必要なシナリオで ziplist を使用する場合、長さが 1000 を超えないようにして、各要素のサイズを 512 バイト以内に制御することをお勧めします。
ジャンプ台
スキップ リストは、O(logN) の平均検索と最悪の場合の O(N) の複雑さの検索をサポートします。
ジャンプ台の代わりに木やバランスの取れた木を使ってみてはいかがでしょうか?
ジャンプ テーブルの実装は非常に簡単で、O(logN) レベルに達することができます。
高速リンクリスト
圧縮されたリンク リストは、ポインタを使用してリンクされ、リンク リストになります。
各 ziplist のデフォルト値は 8k (構成可能) です。
運用・保守
モニター
2) info Commandstats コマンドを使用して、各コマンドの呼び出し数を含む平均コマンド時間を取得します。 、かかった合計時間、平均かかった時間 (マイクロ秒単位)。
マスタースレーブ
Redis のレプリケーション機能は、同期 (sync) とコマンド伝播 (コマンド伝播) の 2 つの操作に分かれています。
同期操作は、サーバーからデータベースの状態を取得するために使用されます。 メインサーバーの現在のデータベース状態を更新します。
コマンド伝播操作は、メイン サーバー上のデータベースの状態を変更するために使用されます。 マスタ・スレーブ・サーバのデータベースの状態が不整合の場合、マスタ・スレーブ・サーバのデータベース状態が不一致になると、 サーバーのデータベースは一貫した状態に戻ります。
読み取りと書き込みの分離
読み取りと書き込みの分離は、大規模なアクセス (単一の Redis マシンが非常に遅く感じるほど大規模なアクセス) に適しており、書き込み操作は読み取り操作よりもはるかに小さくなります。
読み取りリクエストの数が書き込みリクエストをはるかに超える場合、クラスターのデータ コピーのコストは読み取りリクエストのコストよりも大幅に低くなります。同時に、データの不整合をある程度許容できるのであれば、読み取りと書き込みを分離することができます。
Redisクラスター
特性
1. すべての Redis ノードは相互接続され (PING-PONG メカニズム)、バイナリ プロトコルが内部で使用されて伝送速度と帯域幅が最適化されます。
2. ノードの障害は、クラスター内のノードの半分以上が障害を検出した場合にのみ有効になります。
3. クライアントは中間のプロキシ層を必要とせず、redis ノードに直接接続されます。クライアントはクラスター内のすべてのノードに接続する必要はなく、クラスター内の使用可能なノードに接続するだけです。
4. redis-cluster は、すべての物理ノードを [0-16383] スロット (必ずしも均等に分散されているわけではありません) にマップし、クラスターはノード<->スロット<->値を維持する責任を負います。
各 Redis ノードはコマンドを実行し、担当するスロットを宣言する必要があります。
クラスターはスロットを追加します {slot_index1} {slot_index 2} {slot_index 3}
5. Redis クラスターは、Redis クラスターにキーと値を配置する必要がある場合、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 つのレベルのみをサポートし、ネストされたツリー構造はサポートしません。
拡張時
ステップ
1. ターゲットノードに送信する クラスター セットスロット {slot_index} をインポートしています {source_node_id} 2. 送信元ノードに送信する クラスター セットスロット {slot_index} を移行中 {target_node_id} 3. ソースノードのループ実行 クラスター getkeysinslot {slot_index} {count(キーの数)} 4. ソース ノードが実行され、パイプラインを通じてキーをターゲット ノードに移行します。 移行 {target_ip} {target_port} "" 0 {タイムアウト} キー {key1} {key2} {key3} 5. 手順 3 と 4 を繰り返します。 6. クラスター内のすべてのマスターノードに通知を送信します。 クラスター セットスロット {slot_index} ノード {target_nodeid}
各ノードは、各スロットに対応するクラスタ ノードを知っています。
ノードはコマンド要求を受信すると、それを自分で処理できるかどうかを問い合わせ、処理できる場合は、移動エラーを返し、正しいノード IP とポート番号を返します。クライアントがそれを実行するようにガイドし、その後のクライアントのすべての操作 キーが実行されると、移動されたエラーによって提供されたノードに移動します。
コディス
アクセス層: アクセス方法は VIP にするか、Java コードを介して jodis を呼び出し、接続して別の codis プロキシ アドレスを呼び出して、高可用性 LVS および HA 機能を実現します。
プロキシ層: 次に、中間層は codis-proxy と Zookeeper を使用して、crc32 アルゴリズムを通じてデータの方向と分散を処理し、古いバージョンの Raid0 と同様のストライピングを実現します。 codis ではスロットを手動で割り当てる必要がありましたが、codis3.2 以降はスロットが自動的に割り当てられるようになり、非常に便利です。
データ層: 最後に、codis-proxy は実際の redis-server メイン サーバーにデータを保存します。codis の作成者である Huang Dongxu はデータの一貫性を非常に重要視しており、データの遅延によって引き起こされるデータの不整合を許容しないため、このアーキテクチャは使用されませんでした。スレーブサーバーはフェイルオーバーのための冗長アーキテクチャとしてのみ使用され、zookeeper は redis-sentinel を呼び出してフェイルオーバー機能を実装します。
Codis では、Codis はすべてのキーを 1024 個のスロットに分割します。これらの 1024 個のスロットは Redis クラスターに対応し、これらの 1024 個のスロットと Redis インスタンス間のマッピング関係はメモリ内に維持されます。このスロットは構成可能で、2048 または 4096 に設定できます。 Redis のノード数によって異なりますが、多すぎる場合は、さらに多くのスロットを設定できます。
Codis の Codis ダッシュボードがスロット情報を変更すると、他の Codis ノードが ZooKeeper スロットの変更を監視し、適時に同期します。図に示すように:
zk はスロット情報の同期を担当します。
優先キュー
ソートされたセット
リスト
複数のキューを使用して優先キューを実装します。異なる優先タスクは異なるキューに入ります。
同時に、コンシューマがキューからデータをフェッチするとき、優先順位を付けて複数のキューからデータをフェッチすることがサポートされます。
ブロックされました
複数のコンシューマを起動するということは、データを取得するために複数のクライアントを起動することを意味します。
メッセージキュー
パブサブ
使用
サブスクライバーは、1 つまたは複数の一致するサブスクリプション トピックをサブスクライブできます
出版社は特定のトピックと価値を出版します
公開されたトピックは、トピックを購読するコンシューマにすぐに転送されます。コンシューマが存在しない場合、メッセージは破棄されます。
危険
メッセージ損失のリスクがあります (マシンがダウンした場合、ネットワークが切断された場合、またはネットワークが中断されてメッセージが失われた場合)
この機能により、単純な pubsub には応答が失われるリスクがあります。
データの信頼性は保証できません
少なくとも一度はそうするという保証はありません
拡張には柔軟性がなく、消費者を追加して消費を加速する方法はありません。
複数のチャンネルを使用して、何度も聞くことができます。
リスト
リスト
1. 指定されたリストにポップされる要素がない場合、待ち時間がタイムアウトするかポップ可能な要素が見つかるまで、接続は BRPOP コマンドによってブロックされます。 2. 複数のキー パラメータが指定された場合、各リストはパラメータ キーに従って順番にチェックされ、空ではない最初のリストの末尾要素がポップアップ表示されます。 また、BRPOP は、ポップアップ要素の位置を除き、BLPOP と同じように動作します。
リストにタスクがない場合、接続はブロックされます 接続ブロックにはタイムアウトがあります。タイムアウトを 0 に設定すると、メッセージが表示されるまでワイヤレスで待機できます。
pubsub を使用すると、リストから消費できることを消費者に通知することもできます。
これは、A と B の間の 2 つの企業間でのサブスクリプションと出版に適しています。複数のビジネスラインが異なる消費者を意味する場合、より困難になります。
ack実装
保留キューと実行テーブル (ハッシュ テーブル) の 2 つのキューを維持します。
ワーカーは ThreadPool として定義されます。 保留キューによってキューに入れられた後、ワーカーはメッセージを処理するためにスレッド (単一ワーカー) を割り当てます。現在のタイムスタンプと現在のスレッド名をターゲット メッセージに追加し、実行テーブルに書き込みます。その後、ワーカーはメッセージを消費します。完了 実行テーブルの情報を自分で消去します。
スケジュールされたタスクを有効にし、実行キューを定期的にスキャンし、すべての要素のタイムスタンプを確認します。タイムアウトになった場合は、ワーカーの ThreadPoolExecutor がスレッドが存在するかどうかを確認し、存在する場合は現在のタスクの実行がキャンセルされます。ロールバックされます。最後に、タスクを実行キューから取り出し、保留キューに戻します。
並べ替えには zset を使用できます。
Redis の過度の使用は避けてください。Redis は自分が得意なことだけを行い、苦手なことはやればやるほど発見が増えます。 落とし穴が多ければ多いほど、初期段階で設計を誤ると、後の段階での失敗率が高くなり、変換コストが高くなります。 Rabbitmq はそれほど複雑ではなく、運用と保守も非常に簡単であり、業務システムと混合することができます。