ホームページ > 記事 > バックエンド開発 > Redis のデータ型は何ですか? Redis のさまざまなデータ型の概要

Redis のデータ型は何ですか? Redis のさまざまなデータ型の概要

不言オリジナル: 2018-09-13 17:20:386750ブラウズ

この記事では、redis データ型とは何なのかについて説明します。 Redisの各データタイプをまとめたので参考になると思いますので、困っている方は参考にしていただければ幸いです。

序文

#redis は、ANSI C 言語で書かれたオープンソースのログタイプのキー/値データベースであり、ネットワークをサポートし、メモリに基づくことができ、また、複数の言語で API を提供します。
これは、データベース、キャッシュ、メッセージキューエージェントとして使用できるメモリ内データ構造サーバーです。
すべてのデータをメモリ内に保持することで高速アクセスを確保し、同時にデータランディング機能を提供する、これが Redis の主な適用シナリオです。
reids には、レプリケーション、Lua スクリプト、LRU リカバリ、トランザクション、さまざまなレベルのディスク永続化機能が組み込まれており、redis Sentinel による高可用性と Redis Cluster による自動パーティショニングも提供します。
Redis は、文字列、ハッシュテーブル、リスト、セット、順序セット、ビットマップ、ハイパーログログなどのデータ型をサポートします。
Redis で最も一般的に使用されるデータ型: 撹拌、ハッシュ、リスト、セット、ソートセット、パブリッシュ/サブスクライブ、トランザクション。

文字列型

文字列型は単純なキーと値の型で、値は文字列だけでなく数値も含まれます。
一般的に使用されるコマンド: set、get、decr、incr、mget など。
memcached と同じ get、set、incr、decr およびその他の操作を提供することに加えて、redis は次の操作も提供します。 (1) 文字列の長さを取得;
(2) 文字列に内容を追加;

(4) 特定のセクションを設定および取得文字列の Bit (ビット);

(5) 一連の文字列の内容をバッチで設定します;

ハッシュ型

ハッシュは特に保存に適していますオブジェクト。

一般的に使用されるコマンド: hget、hset、hgetall など。
アプリケーションシナリオ: ユーザーのニックネーム、年齢、性別、ポイントなどの構造化データを保存し、ユーザー情報オブジェクトデータを保存します。
ハッシュのアプリケーションシナリオを説明するための簡単な例を取り上げます。たとえば、次の情報を含むユーザー情報オブジェクトデータを保存します。
(1) 検索対象のキーはユーザー ID です;
1. 分析例:

(2) このマップのキーはメンバーの属性名で、値は属性値です;

(3) このようにして、データへの変更とアクセスは、その内部メソッドを通じて直接行うことができます。マップキー(redisではinternalと呼ばれます) Mapのキーはフィールド)、つまりキー(ユーザー名ID)フィールド(属性名)で対応する属性データを操作することができます。

2. 注:

(1) Redis は、すべての属性データを直接取得できるインターフェース (hgetall) を提供していますが、内部 Map のメンバーが多数ある場合、内部マップを走査する必要があります。マップ全体を操作します。

(2) Redis のシングルスレッドモデルのため、このトラバーサル操作には時間がかかり、他のクライアントリクエストにまったく応答しない可能性があることに注意する必要があります。

リストタイプ

リストタイプは基本的に、各要素が文字列型である二重リンクリストです。これにより、リストをスタックまたはスタックとして使用できます。キュー。。

リストタイプは、複数のプログラム間のメッセージ交換を完了するためにメッセージキューサービスでよく使用されます。

一般的に使用されるコマンド: lpush、rpush、lpop、rpop、lrange など。
アプリケーションシナリオ: 最新メッセージランキングやメッセージキューなどの機能を実装します。
単純なメッセージキューの分析例:
(1) アプリケーションが lpush を実行してリンクリストに新しい要素を追加するとします。プログラムは「プロデューサー」と呼ばれます;##(2) 別のアプリケーションがリンクリストから要素を削除する rpop 操作を実行している間、そのようなプログラムを「コンシューマー」と呼びます;
(4) さらに、プロデューサーの速度がコンシューマーの速度よりも速い場合、メッセージキューの長さは増加し続け、時間の経過とともに多くのメモリ領域を占有することになります;
(5) したがって、 brpop コマンドを使用できます。このコマンドは要素が存在する場合のみを返し、要素が存在しない場合はタイムアウトするまでブロックされ、null を返します。

セットタイプは、文字列タイプの順序付けされていないコレクションです。

セットの概念は、一意の値の集合です。

set 要素には、最大 (2 の 32 乗 - 1) 個の要素を含めることができます。
set の内部実装は、値が常に null である HashMap です。
#set が提供する外部関数は list と同様ですが、set の際に自動的に重複を排除できるのが特徴です。
一般的に使用されるコマンド:sadd、spop、smembers、sunion など。
データのリストを保存する必要があり、重複したデータを望まない場合は、set が適切な選択です。
そして set は、メンバーがセットコレクションに含まれているかどうかを判断するための重要なインターフェイスを提供しますが、リストでは提供できません。
セットデータ構造を使用すると、いくつかの集合データを保存できます。たとえば、Weibo アプリケーションでは、ユーザーのすべてのフォロワーをセットに保存でき、そのユーザーのすべてのファンを保存できます。セット、コレクションに保存されます。
Redis は、コレクションの交差、結合、差分などの操作も提供します。これは、共通の注意、共通の好み、2 級友人などの機能を実装するのに非常に便利です。

Zset型

setと同様、sorted setもstirng型要素のコレクションです。違いは、各要素が double 型のスコアに関連付けられており、要素の順序がスコアによって決定されることです。
ソートセットは挿入順、つまり自動的にソートされます。
一般的に使用されるコマンド: zadd、zrange、zrem、zcard など。
順序付けされた重複しないセットのリストが必要な場合は、ソートされたセットのデータ構造を選択できます。
応用例:

(1) たとえば、クラス全体の成績を保存する場合、設定値を生徒番号にすることができます。クラスメートの成績、得点ができます。
(2) ランキングアプリケーション。スコアなどに基づいて上位Nユーザーをリストします。

pub/sub

subscribe、unsubscribe、publish の 3 つのコマンドは、ジェネリックのパブリッシングとサブスクライブを実装します。
送信者 (情報を送信するクライアント) は、特定の受信者 (情報を受信するクライアント) に情報を直接送信するのではなく、チャネル (チャネル) に情報を送信します。 )、その後、チャネルはそのチャネルに関心のあるすべての加入者に情報を転送します。
送信者はサブスクライバーに関する情報を知る必要はなく、サブスクライバーもどのクライアントが情報を送信したかを知る必要はなく、チャネルに注意を払うだけで済みます。それに興味がある。
非常に軽量かつ簡潔になるように設計された redis でのパブリッシュ/サブスクライブ。メッセージのパブリッシュとサブスクリプションの基本機能を実現します。ただし、メッセージの永続性に関する情報はまだ提供されていません。エンタープライズレベルの機能など。
1 つの Redis クライアントがメッセージをパブリッシュし、他の複数の Redis クライアントがメッセージをサブスクライブします。パブリッシュされたメッセージは送信されるとすぐに失われます。Redis はパブリッシュされたメッセージを永続化しません。メッセージサブスクライバーはメッセージをサブスクライブできます。取得のみメッセージが購読された後は、チャネル内の以前のメッセージを取得できません。
メッセージパブリッシャー、つまりパブリッシュクライアントには、排他的リンクは必要ありません。同じ redis-client リンクを使用して、他の操作 (incr など) を実行できます。 ) メッセージのパブリッシュ中;
メッセージサブスクライバー、つまりサブスクライブクライアントには排他的リンクが必要です。つまり、サブスクライブ期間中、redis クライアントは他の操作を中断できません。
現時点では、クライアントはブロック的な方法でパブリッシュ側からのメッセージを待機するため、サブスクライブでは別のリンクを使用するか、追加のスレッドでそれを使用する必要があります。
tcp のデフォルト接続時間は固定されており、このワールドでサブ側がパブ側メッセージを受信しない場合、またはパブ側がメッセージを生成しない場合、サブ側接続は強制的にリサイクルされる。
これを解決するには特別な手段が必要です。タイマーを使用して、パブリッシュとサブスクライブの間のキープアライブメカニズムをシミュレートします。タイマー時間は最大 TCP 接続時間を超えることはできません。
サブスクライブ側がリンクを切断すると、一部のメッセージが失われます、つまり、リンク障害期間中のメッセージが失われます。そのため、ここで Redis リストを考慮する必要があります。永続性のため;
各メッセージについて非常に懸念がある場合は、redis に基づいて追加の補足作業を行う必要があります。サブスクリプションを永続的にしたい場合は、次の設計アイデアを実行してください。

(1) サブスクライブ側: まず、セットコレクションに「サブスクライバー ID」を追加します。このセットコレクションは「アクティブなサブスクライバー」を保存します。サブスクライバー ID はそれぞれを一意にマークします。このセットは「アクティブなサブスクライバコレクション」用です。
(2) サブスクライブ側はサブスクリプション操作を開始し、redis に基づいてサブスクライバー ID をキーとしてリストデータ構造を作成します。このリストには、消費されていないすべてのメッセージが保存されます。このリストは「サブスクライバーメッセージキュー」と呼ばれます ;
(3) パブリッシュ側: 各メッセージがパブリッシュされた後、パブリッシュ側はアクティブなサブスクライバーコレクションを走査し、パブリッシュされたメッセージを各 "サブスクライバーメッセージキュー" の最後に順番に追加する必要があります;
(4 ) これまでのところ、基本的に、パブリッシュされたすべてのメッセージが各「サブスクライバーメッセージキュー」に永続的に保存されることを保証できます。
(5) サブスクライブ側では、サブスクリプションメッセージが受信されるたびに、その後、次の場所でメッセージを削除する必要があります。「サブスクライバメッセージキュー」の先頭;
(6) サブスクライブ終了の開始時に、「サブスクライバメッセージキュー」に残りのレコードがあることが判明した場合、これらは最初にメッセージを消費してからサブスクライブします。

#上記のメソッドにより、正常に到着したメッセージが失われることなく消費されることが保証されます

(2) コマンドのエンキュー

(3) トランザクションの実行
##トランザクションは個別の分離操作です。トランザクション内のすべてのコマンドはシリアル化され、順番に実行されます。

トランザクションの実行中、他のクライアントから送信されたコマンド要求によって中断されることはありません。

単一の redis コマンドの実行はアトミックですが、redis はトランザクションのアトミック性を維持するメカニズムを追加していないため、redis トランザクションの実行はアトミックではありません。

トランザクションは、パッケージ化されたバッチ実行スクリプトとして理解できますが、バッチ命令はアトミックな操作ではありません。途中で命令が失敗しても、前の命令がロールバックされたり、後続の命令が発生したりすることはありません。やめてください。

multi、exec、discard、watch コマンドは、redis トランザクションの基礎です。

multi:

(1) multi コマンドはトランザクションの開始に使用され、常に ok を返します。
(2) マルチコマンドの実行後、クライアントは任意の数のコマンドをサーバーに送信し続けることができます。
(3) これらのコマンドはすぐには実行されず、キューに入れられます。
( 4) exec コマンドが呼び出されると、キュー内のすべてのコマンドが実行されます。

exec:

(1) exec コマンドは、トランザクション内のすべてのコマンドをトリガーして実行する責任があります。
(2) クライアントが multi を使用してopen a トランザクション終了後、切断により exec コマンドが正常に実行されなかった場合、トランザクション内のすべてのコマンドは実行されません。
(3) 一方、クライアントがトランザクションを開いた後に exec コマンドの実行に成功すると、トランザクション内のすべてのコマンドが実行されます。

discard:

(1) Discard を呼び出すことにより、クライアントはトランザクションキューをクリアし、トランザクションの実行を中止できます。

watch:

(1) watch コマンドは、redis トランザクションにチェックアンドセット (CAS) 動作を提供できます。
(2) watch を使用すると、条件付きで exec コマンドを実行できます: トランザクションは、監視対象のすべてのキーが変更されていないという前提でのみ実行できます。この条件が満たされない場合、トランザクションは実行されません。
(3) watch を使用して有効期限のあるキーを監視すると、キーの有効期限が切れてもトランザクションは実行できます。
(4) watch は複数回呼び出すことができ、健全性の監視は watch が実行されてから exec が呼び出されるまで有効になります。
(5) exec が呼び出されると、トランザクションが正常に実行されたかどうかに関係なく、すべての健全性の監視がキャンセルされます。
(6) クライアントがリンクを切断すると、クライアントのヘルス監視もキャンセルされます。