私は、Javaのシリーズを愛する--- [5つの一般的に使用されるデータ型でのRedis、一般的に使用されるコマンドや永続性メカニズム]

5つの4.1 Redisのデータ型

Redisの値は、5つのデータ型をサポートしている先進的なキーと値のストレージシステム、次のとおりです。

• 文字列（String）を

• ハッシュ（ハッシュ）

• 文字列のリスト（一覧）

• 文字列のコレクション（セット）

• 文字列の順序集合（ソートセット）

キーの定義、および以下の点に注意してください。

• キーは、それが1024のバイトを操作しないことをお勧め長すぎるではない、それはメモリも検索効率を低下させるだけでなく、消費されます

• 可読性場合、短すぎる、短すぎるではないキーは、キーを削減します

• このプロジェクトでは、最高のキーは均一な命名規則を持っています

4.2文字列型文字列

文字列型4.2.1概要

Redisの文字列型は、データストレージの最も基本的なタイプで、これは預金と同じデータへのアクセスの種類ことを意味し、Redisのでバイナリセーフです。文字列の値の長さはRedisの中まで収容可能なデータ型は512Mです。

文字列型、一般的に使用されるコマンド4.2.2

• 設定したキー値

  キー操作を上書き存在する場合は、指定した文字列値が保持しているキーのセット。常に「OK」を返します

  127.0.0.1:6379>設定会社"itcast" 
  OK 
  127.0.0.1:6379>

• キーを取得

  キーの値を取得します。キーに関連付けられた値が、String型でない場合getコマンドのみの文字列値を取得するために使用することができるので、Redisのはエラーメッセージが返され、キーが存在しない場合は、リターン（NIL）。

  127.0.0.1:6379>セット名"itcast" 
  OK 
  127.0.0.1:6379>名取得
  "itcastを"

• デルキー

  指定されたキーを削除します。

  127.0.0.1:6379>デル名
  （整数）。1 
  127.0.0.1:6379>名前GET 
  （ゼロ）INCRコマンド増分からSaveコマンドDECRをステップ数をインクリメントキーステップincrby 保存の重要なステップからステップ数decrby
  
  
  
  
  
  
  
  
  
  
  

4.3型のハッシュハッシュ

4.3.1タイプハッシュハッシュ概要

ハッシュRedisのタイプは、文字列値文字列のキーと容器マップを有すると見なすことができます。したがって、このタイプのオブジェクトの情報値を格納するのに非常に適しています。ユーザー名、パスワードの有効期間、などが挙げられます。ハッシュは非常に少ないフィールドが含まれている場合、このタイプのデータはまた、唯一の非常に少ないディスク領域を使用します。各ハッシュは4,294,967,295ペアを格納することができます。

4.3.2ハッシュハッシュの種類一般的に使用されるコマンド

• HSETキーフィールド値

  設定して指定されたキーフィールド/値ペア（キーと値のペア）。

  127.0.0.1:6379> HSET myhash名haohao 
  （整数）1 
  127.0.0.1:6379>

• hgetキーフィールド

  指定されたキーでフィールドの値を返します。

  127.0.0.1:6379> HSET myhashユーザ名haohao 
  （整数）1 
  127.0.0.1:6379> hget myhash名
  "haohao"

• HDELキーフィールド[フィールド...]

  1つまたは複数のフィールドを削除することができ、戻り値は削除されたフィールドの数であります

  127.0.0.1:6379> HDEL myhash名
  （整数）1 
  127.0.0.1:6379> hget myhash名
  （NIL）
  127.0.0.1:6379>

4.4リスト型リスト

4.4.1リストタイプリストの概要

Redisのでは、挿入順のリストタイプは、文字列のリストを並べ替えられています。そして、データ構造は、一般的なリストでは、我々は尾（右）その頭（左）に新しい要素を追加することができます。挿入されたときにキーが存在しない場合は、Redisのは、そのキーの新しいリストを作成します。リスト内のすべての要素が削除された場合、逆に、そしてキーは、データベースから削除されます。リスト要素の数が最大に含めることができる4294967295であります

4.4.2リストタイプのリスト

• lpushキー値[VALUE1の値2 ...]

  キーが存在しない場合、コマンドはデータを挿入するために、再度リストの先頭の後、前に挿入されたキーに関連付けられた空白のリストを作成し、指定されたキーリストの先頭に関連付けられたすべての値を挿入します。要素の数を返し、成功を挿入します。

  127.0.0.1:6379> lpushマイリストABC 
  （整数）3 
  127.0.0.1:6379>

• LPOPキー

  最初のキーに関連付けられている、指定されたリンクリスト、即ち、ヘッド素子をポップリターン要素。キーが存在しない場合は、nilを返し、キーが存在する場合、リストの先頭要素が返されます。

  127.0.0.1:6379> lpushマイリストABC 
  （整数）3 
  127.0.0.1:6379> LPOPマイリスト
  "C" 
  127.0.0.1:6379> LPOPマイリスト
  "B"

• RPOPキー

  テールポップ要素から。

  127.0.0.1:6379> lpushマイリストABC 
  （整数）3 
  127.0.0.1:6379> RPOPのマイリスト
  ""

   

4.5コレクション型セット

4.5.1収集タイプ設定

文字型がコレクションのソート、リストのタイプではないとしてのRedisで、我々はセットを見ることができ、我々はまた、このタイプのデータの付加価値に対して実行、または他の操作があるかどうかを決定する要素を削除することができます。これらの操作の時間計算量は、（1）、即ち、一定時間内に操作を完了するためにOであることに留意されたいです。4294967295の最大値とリストタイプが異なる含めることができる要素、コレクションを設定して繰り返し要素の数が許可されていません。

一般的なコマンドの設定4.5.2コレクション型

• サッドキー値[値1、値...]

  セットにデータを追加するには、既存のキーの値は、追加を繰り返していない場合

  127.0.0.1:6379> SADD MYSET ABC 
  （整数）3

• キーsmembers

  セットのすべてのメンバーでゲット

  127.0.0.1:6379> SADD MYSET ABC 
  （整数）3 
  127.0.0.1:6379>はMYSET smembers 
  1） "C" 
  2） "" 
  3） "B"を

• SREM主要メンバー[メンバー1、member2 ...]

  メンバーの指定されたセットを削除します。

  127.0.0.1:6379> SREM MYSET AB 
  （整数）2 
  127.0.0.1:6379>はMYSET smembers 
  1） "C" 
  127.0.0.1:6379>
  

   

第5章Redisの汎用コマンド

• キーパターン

  すべてのパターンマッチングキーを取得し、キーのキーを持つすべての一致を返します。*任意の1文字以上の文字を表し、？任意の1つの文字を表現

  127.0.0.1:6379>キー* 
  1） "会社" 
  2） "マイリスト" 
  3） "myhash" 
  4） "マイセット"

• KEY1 KEY2の...

  指定されたキーを削除します。

  127.0.0.1:6379>パートナー
  （整数）1

• 期限切れにキーを

  キーが存在するか否かを判定し、0は不在を表し、1の存在を示します

  127.0.0.1:6379>のcompnayが存在する
  （整数）0 
  127.0.0.1:6379>はマイリスト存在
  （整数）1 
  127.0.0.1:6379を>

• タイプキー

  指定されたキーの種類を取得します。コマンドの形式は、文字列として返されます。返される文字列の文字列、リスト、セット、ハッシュ、キーが存在しない場合またはnone

  127.0.0.1:6379>タイプ会社
  列
  127.0.0.1:6379>型mylistというの
  リスト
  127.0.0.1:6379>は型マイセットは、
  セット
  myhashタイプ> 127.0.0.1:6379を
  ハッシュ
  127.0.0.1:6379を>

  切れます

  有効期限：

  秒は、キー値を期限切れ

第6章Redisの永続化

6.1 Redisの永続化の概要

Redisのはその高いパフォーマンスにメモリに格納されているすべてのデータであり、再起動後のRedisを作るためにまだデータが失われないことを確認、あなたがハードドライブにメモリからデータを同期させる必要があり、このプロセスは持続性です。Redisのは一つの方法は、AOFにあり、1はRDBの方法で、2つの方法で永続的なサポートしています。どの組み合わせで、単独で、またはその両方を使用することができます。

• RDBの永続性（デフォルトでサポートされている、設定なし）

  このメカニズムは、メモリ内のデータセットのスナップショットは、ディスクに書き込まれる指定された時間間隔内であることを意味します。

• AOFの永続性

  このメカニズムは、Redisのサーバーが起動の初めに、サーバごとに書き込み操作によって処理ログレコードの形態であろう、それはデータベースが完了した起動した後、データを確実にするために、データベースを再構築するには、このファイルを読み込みます。

• 持続性なしありません

  我々はのmemcachedの拡張版の関数としてのRedisことができるように我々は、設定の仕方によって、持続性のRedisサーバ機能を無効にすることができます。

• RDB Redisのと同じ時間AOFで使用することができます

6.2 RDBの永続性メカニズム

RDB持続的な利点が制度化6.2.1

• このようたら、その後、あなたの全体のRedisのデータベースは、ファイルのバックアップに最適です。一つだけのファイルを、含まれています。たとえば、最後のデータの24時間を時間ごとにアーカイブするつもりかもしれませんが、また、毎日のデータの最後の30日に1回アーカイブ。システムが壊滅的障害が発生した後に、このバックアップ戦略では、我々は非常に簡単に復元することができます。

• 災害復旧のために、RDBは非常に良い選択です。我々は非常に簡単に別のファイル圧縮すること、その後、他の記憶媒体に転送することができますので、

• パフォーマンスが最大化されています。あなたは素晴らしいサービス実行プロセスを避けることができるようにプロセスのRedisのサービスのために、持続性の初めに、実行するその唯一の必要性は、フォーク（フォーク）子プロセス、および、子によって、これらの永続的な作業が完了した後でIOが運営しました。

データセットが大きい場合AOF機構に比べて、効率が高くRDBになり始めます

6.2.2 RDB永続化機構の欠点

• あなたはつまり、最大値はデータの損失を回避するために、データの高可用性を保証したい場合は、RDBは良い選択ではないでしょう。持続性のタイミングの前に、システムのダウンタイム現象一度、ディスク上にデータを書き込むための時間がなかったので失われます。

• データセットが大きい場合、それは数百ミリ秒、あるいは1秒の提供を停止するサーバー全体を引き起こす可能性がある場合ように、データの永続化作業を支援するためにフォークの子プロセスによってRDBので、

設定6.2.3 RDBの永続化メカニズム

redis.windows.conf設定ファイルがあり、次のとおりです。

################################スナップショット################# ################ 
＃
＃ディスク上のDBを保存：
＃1 
<秒> <変化>保存＃
＃の
DBに保存されます。＃もし与えられた秒数と両方与えられた
＃ DBに対する書き込み回数が発生しました。
＃1 
：行動以下の例では＃保存することで
、少なくとも1つのキーが変更された場合は900秒（15分）の後位
に少なくとも10個のキーが変更された場合は300秒（5分）の後に＃を
少なくとも10000のキー場合は60秒後に位変更された
＃の
＃注：すべてのコメントすべての「保存」の行で保存を無効にすることができます。
＃
＃すべての以前に設定保存を除去することも可能です
単一の空の文字列引数とディレクティブを保存追加することにより、＃ポイント
次の例のように＃は：
＃
＃「」保存900 1セーブ300 10 [保存]を60万保存

その中でも、上記の構成は、道RDBデータの永続化のタイミングは次のとおりです。

キーワード	時間（秒）	キーの数を変更します。	説明
保存する	900	1	少なくとも900秒ごと（15分）キーが変更され、メモリのスナップショットダンプ
保存する	300	10	（5分）10キー、少なくとも300秒ごとには、メモリのスナップショットダンプを変更されました
保存する	60	10000	少なくとも60秒ごとに（1分）10の000キーの変更、メモリのスナップショットダンプ

永続化メカニズムAOF 6.3

6.3.1 AOF永続化メカニズムの優位性

• このメカニズムは、より高いデータセキュリティ、すなわちデータの永続性をもたらす可能性があります。Redisのは毎秒同期同期戦略、3を提供し、すべての変形及び同期は同期していません。実際には、非同期同期は違い、システムのダウンタイム現象一度、その後、数秒以内に変更されたデータが失われることで、その効率は非常に高く、毎秒完了です。そして、すべての同期を変更し、我々は、データの変更が即座にディスクに記録されますたびに発生同期の永続性とみなすことができます。このように効率が最低であることを予想されます。非同期に関しては、言うまでもなく、私たちはそれを理解して修正することができると思います。

• メカニズムは、ログファイルを書き込みますので、追加モードで使用されているので、ダウンタイムの現象は書き込み処理中にあっても、それが既に存在するログファイルの内容を破壊しないであろう。私たちは、この操作は半分しかデータが、システムのクラッシュを登場で書く場合は、私たちはRedisの-チェックAOFツールでデータの一貫性の問題を解決するために我々はできる、次回の起動時のRedisの前に、心配しないでください。

• ログが大きすぎる場合、Redisのは、自動的に書き換えメカニズムを有効にすることができます。Redisのモードを追加するということはRedisのは、コマンドに変更されたものを記録するための新しいファイルを作成しながら、変更されたデータは、古いディスク・ファイルに書き込まれていきます。この期間中に実行されます。そのため、切り替え時に行われる書き換えデータのセキュリティをより良く保証することができます。

• 簡単に、明確なログファイルレコードのすべての変更を理解することがあってAOF形式。実際には、我々は、ファイルを介して再構成データを完了することができます

6.3.2 AOF永続化機構の欠点

• データセットの同じ数のために、AOFの文書ファイルは通常、RDBよりも大きく、

• 同期化政策に応じて、作業効率上のAOFは、RDBにおけるよりも遅くなる傾向にあります。要するに、第二の戦略当たりの同期の効率が比較的高い、同期効率的かつ効率的なようRDBポリシーを無効にします。

6.3.3 AOF永続化メカニズムの設定

6.3.3.1オープンAOFの永続性

############################## ONLY MODEを追加################# ############## デフォルトRedisのことで＃は非同期に、ディスク上のデータセットをダンプします。このモードは、多くのアプリケーションで＃は十分に良いが、Redisのプロセスの問題や停電が書き込みの数分になることがあり＃は（に応じて、失われたセーブポイントに構成＃）。＃＃追加ファイルのみを提供し、代替永続モードで＃はるかに優れた耐久性を。たとえば、デフォルトのデータのfsyncポリシー使用して＃（後の設定ファイルの参照）のRedisに書いてのちょうど1秒を失う可能性が何かあれば、サーバの停電のような＃劇的なイベント、または単一の書き込みを










Redisのプロセス自体が間違っ＃が起こりますが、オペレーティングシステムがあり
、まだ正常に実行されている＃。
＃
＃のAOFとRDBの永続性は問題なく、同時に有効にすることができます。
AOFがAOFをロードする起動時のRedisで有効になっている場合＃は、そのファイルのある
優れた耐久性を保証して＃。
＃
＃詳細はhttp://redis.io/topics/persistenceを確認してください。appendonlyなし

appendonly永続化メカニズムAOFオープン、yesに変更され、デフォルトのディレクトリはappendonly.aofファイルの下で生産されます

6.3.3.2 AOF永続的なタイミング

＃1 appendfsync常に
appendfsync everysec 
＃appendfsyncなし

次のように持続時間AOF上記構成のために、説明しました：

キーワード	永続機会	説明
appendfsync	常に	たびにupdateコマンド、持続時間
appendfsync	everysec	1秒に1回の持続性
appendfsync	いいえ	不持久化