redisまとめ4-KEYデザインテクニック、よくある質問
redisまとめ1-Redis概要、インストール、クラスタ
redisまとめ2-Redis 6種類のデータ型コマンドまとめ(コマンド例付)
redisまとめ3-持続化rdb,aof,運転メンテナンスコマンド,Sentineモニタリング
redisまとめ4-KEYデザインテクニック、よくある質問
一.概要
1.1 NoSQLの概要
1.1.2 NoSQLの特徴
1.1.3 NoSQL適用シーン
1.2 Redisの概要
1.2.1概要
1.2.2 Redis具体適用の場合
1.2.3 redisとmemcachedの比較
1.2.4 redis,mysql,mongodb比較
二.インストール
2.1スタンドアロンインストール
2.2設定環境変数及びサービス
2.3インストール後のディレクトリ構造
2.4構成の詳細
2.5クラスタ
三Redisコマンド
3.1接続コマンド
3.1 Redis共通命令
3.2 Redis文字列操作
3.4 setセット関連コマンド
3.5 order set秩序集合
3.6 Hashハッシュ
四Redisの持続化-RDB,AOF
4.1持続化
4.2 redis持続化
五.redis運転次元コマンド
5.1共通コマンド
5.2注意事項及び重要パラメータの説明
5.3命令のまとめ:
5.4 config構成リスト
六.メンテナンスモニタsentinel
6.1概要
6.2操作手順
七.Redisのkeyデザインテクニック
7.1元のプライマリ・キー列によるクエリー
比照関係データベースの設計:1):テーブル名をkey接頭辞に変換する.2):セグメント2にパーティションkey用のフィールドを配置–mysqlのプライマリ・キーに対応するカラム名(userid 3):セグメント3にプライマリ・キー値(2,3,4...)を配置します.a,b,c 4):4段目、格納する列名を書く
テーブル名:user
userテーブル
userid
username
password
email
1
lurenjia
1111111
[email protected]
このテーブルにredisを設定するkeyは、次のように設計されています.
注意:keyの階層関係は:区切り、redisのツールで表示するときも階層関係が表示されます.
7.2元の非プライマリ・キー列によるクエリー
ステップ2:1)まず、非プライマリ・キー列に基づいてキーを設定し、キーの値を格納する2)次に、調べたキーに基づいて第1ステップのキーに具体的な値を問い合わせる.すなわち、リレーショナルデータでは、プライマリ・キーのほかに、他のカラムもステップ的にクエリを行う可能性がある、上記の表ではusernameも頻繁にクエリを行い、インデックスを付けることが多い.k-vデータに変換すると、その列を主とするkey-value Set user:username:lurenjia:uid 1も生成されます.これにより、username:lurenjia:uidに基づいてuserid=1を検出し、user:1:password/email...を調べてユーザー名に基づいてユーザー情報を検索できます.
八.Redisの使用に関するよくある質問
8.1キャッシュ貫通(キャッシュ破壊)
8.1.1キャッシュ・スルーとは
一般的なキャッシュシステムは、keyに従ってクエリーをキャッシュし、対応するvalueが存在しない場合は、バックエンドシステム(DBなど)を検索する必要があります.keyに対応するvalueが必ず存在せず、そのkeyに対する同時要求量が大きい場合、バックエンドシステムに大きな圧力を与える.これをキャッシュスルーと呼びます.キャッシュスルーは簡単に言えばキャッシュがまったく役に立たない、キャッシュに存在しないからDBで調べ、DBで調べないからキャッシュしない、そしてキャッシュに存在しないからDBで調べる.
8.1.2回避方法
1:クエリー結果が空の場合もキャッシュし、キャッシュ時間を短く設定するか、キーに対応するデータをinsertしてからキャッシュをクリーンアップします.2:反発ロック(mutex key)業界でよく使われる方法は、mutexを使用することです.簡単に言えば、キャッシュが無効になったとき(取り出された値が空であると判断する)に、直ちにload dbに行くのではなく、キャッシュツールの成功した操作の戻り値を持つ操作(例えばRedisのSETNXやMemcacheのADD)を使用してmutex keyをセットし、戻りに成功したときにload dbの操作を行い、キャッシュをリセットする.そうでない場合はgetキャッシュ全体のメソッドを再試行する.コードは次のとおりです.
8.2キャッシュ雪崩
8.2.1キャッシュ雪崩とは?
キャッシュ・サーバが再起動したり、大量のキャッシュが一定の期間に集中して失効したりすると、失効した場合、バックエンド・システム(DBなど)にも大きな圧力がかかります.すなわち、データがキャッシュからクエリーする場合、ない場合はmysqlからクエリーし、キャッシュにキャッシュする.このモードは、コンカレント量があまり高くない場合や、データの操作効率が高い場合にはほとんど問題ありません.しかしif(キャッシュが無効になった場合&&コンカレント量が高い場合&&データベースの操作時間が長い場合)then?1.キャッシュ失効2.SQL+プログラムロジックを含む場合、最初のプロセスはデータベースに行って新しいデータを取得する.この5 Sのうち、2番目、3番目…N番目はいずれも失効したキャッシュを取得しただけで、データベースにも接続する.その結果、データベース・ロック・テーブル->データベースが大量のプロセスを累計->データベースが停止するまで!
8.2.2回避方法
1:キャッシュが無効になった後、ロックまたはキューを追加することで、リード・データベースのライト・キャッシュのスレッド数を制御します.たとえば、keyに対して1つのスレッドのみがデータのクエリーとライトキャッシュを許可し、他のスレッドが待機します.2:異なるkeyは、異なる期限を設定し、キャッシュが無効になった時点をできるだけ均一にします.3:二次キャッシュを行い、A 1は元のキャッシュ、A 2はコピーキャッシュ、A 1が失効した場合、A 2にアクセスでき、A 1キャッシュの失効時間は短期、A 2は長期に設定.4:この時点でプログラムがキャッシュを更新しているかどうかを判断するためのタグを追加します.もしそうであれば、古いキャッシュに直接戻ります(プログラムエラーによるタグの削除なしによるキャッシュの更新の問題を避けるために、設定の失効時間がマークされています).そうでなければ、タグを設定し、データ取得とキャッシュ更新を行い、最後にタグを削除します.
キャッシュスルー、キャッシュ破壊、キャッシュ雪崩ソリューション分析
Redisが踏んだ穴-美団
redisまとめ2-Redis 6種類のデータ型コマンドまとめ(コマンド例付)
redisまとめ3-持続化rdb,aof,運転メンテナンスコマンド,Sentineモニタリング
redisまとめ4-KEYデザインテクニック、よくある質問
一.概要
1.1 NoSQLの概要
1.1.2 NoSQLの特徴
1.1.3 NoSQL適用シーン
1.2 Redisの概要
1.2.1概要
1.2.2 Redis具体適用の場合
1.2.3 redisとmemcachedの比較
1.2.4 redis,mysql,mongodb比較
二.インストール
2.1スタンドアロンインストール
2.2設定環境変数及びサービス
2.3インストール後のディレクトリ構造
2.4構成の詳細
2.5クラスタ
三Redisコマンド
3.1接続コマンド
3.1 Redis共通命令
3.2 Redis文字列操作
3.4 setセット関連コマンド
3.5 order set秩序集合
3.6 Hashハッシュ
四Redisの持続化-RDB,AOF
4.1持続化
4.2 redis持続化
五.redis運転次元コマンド
5.1共通コマンド
5.2注意事項及び重要パラメータの説明
5.3命令のまとめ:
5.4 config構成リスト
六.メンテナンスモニタsentinel
6.1概要
6.2操作手順
七.Redisのkeyデザインテクニック
7.1元のプライマリ・キー列によるクエリー
比照関係データベースの設計:1):テーブル名をkey接頭辞に変換する.2):セグメント2にパーティションkey用のフィールドを配置–mysqlのプライマリ・キーに対応するカラム名(userid 3):セグメント3にプライマリ・キー値(2,3,4...)を配置します.a,b,c 4):4段目、格納する列名を書く
テーブル名:user
userテーブル
userid
username
password
1
lurenjia
1111111
[email protected]
このテーブルにredisを設定するkeyは、次のように設計されています.
set user:userid:1:username lurenjia
set user:userid:1:password 111111
set user:userid:1:email lurenjia@163.com 注意:keyの階層関係は:区切り、redisのツールで表示するときも階層関係が表示されます.
7.2元の非プライマリ・キー列によるクエリー
ステップ2:1)まず、非プライマリ・キー列に基づいてキーを設定し、キーの値を格納する2)次に、調べたキーに基づいて第1ステップのキーに具体的な値を問い合わせる.すなわち、リレーショナルデータでは、プライマリ・キーのほかに、他のカラムもステップ的にクエリを行う可能性がある、上記の表ではusernameも頻繁にクエリを行い、インデックスを付けることが多い.k-vデータに変換すると、その列を主とするkey-value Set user:username:lurenjia:uid 1も生成されます.これにより、username:lurenjia:uidに基づいてuserid=1を検出し、user:1:password/email...を調べてユーザー名に基づいてユーザー情報を検索できます.
八.Redisの使用に関するよくある質問
8.1キャッシュ貫通(キャッシュ破壊)
8.1.1キャッシュ・スルーとは
一般的なキャッシュシステムは、keyに従ってクエリーをキャッシュし、対応するvalueが存在しない場合は、バックエンドシステム(DBなど)を検索する必要があります.keyに対応するvalueが必ず存在せず、そのkeyに対する同時要求量が大きい場合、バックエンドシステムに大きな圧力を与える.これをキャッシュスルーと呼びます.キャッシュスルーは簡単に言えばキャッシュがまったく役に立たない、キャッシュに存在しないからDBで調べ、DBで調べないからキャッシュしない、そしてキャッシュに存在しないからDBで調べる.
8.1.2回避方法
1:クエリー結果が空の場合もキャッシュし、キャッシュ時間を短く設定するか、キーに対応するデータをinsertしてからキャッシュをクリーンアップします.2:反発ロック(mutex key)業界でよく使われる方法は、mutexを使用することです.簡単に言えば、キャッシュが無効になったとき(取り出された値が空であると判断する)に、直ちにload dbに行くのではなく、キャッシュツールの成功した操作の戻り値を持つ操作(例えばRedisのSETNXやMemcacheのADD)を使用してmutex keyをセットし、戻りに成功したときにload dbの操作を行い、キャッシュをリセットする.そうでない場合はgetキャッシュ全体のメソッドを再試行する.コードは次のとおりです.
SETNX， 「SET if Not eXists」 ， ， 。 redis2.6.1 setnx ，
public String get(key) {
String value = redis.get(key);
if (value == null) { //
// 3min ， del ， load db
if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(key_mutex);
} else { // load db ，
sleep(50);
get(key); //
}
} else {
return value;
}
}8.2キャッシュ雪崩
8.2.1キャッシュ雪崩とは?
キャッシュ・サーバが再起動したり、大量のキャッシュが一定の期間に集中して失効したりすると、失効した場合、バックエンド・システム(DBなど)にも大きな圧力がかかります.すなわち、データがキャッシュからクエリーする場合、ない場合はmysqlからクエリーし、キャッシュにキャッシュする.このモードは、コンカレント量があまり高くない場合や、データの操作効率が高い場合にはほとんど問題ありません.しかしif(キャッシュが無効になった場合&&コンカレント量が高い場合&&データベースの操作時間が長い場合)then?1.キャッシュ失効2.SQL+プログラムロジックを含む場合、最初のプロセスはデータベースに行って新しいデータを取得する.この5 Sのうち、2番目、3番目…N番目はいずれも失効したキャッシュを取得しただけで、データベースにも接続する.その結果、データベース・ロック・テーブル->データベースが大量のプロセスを累計->データベースが停止するまで!
8.2.2回避方法
1:キャッシュが無効になった後、ロックまたはキューを追加することで、リード・データベースのライト・キャッシュのスレッド数を制御します.たとえば、keyに対して1つのスレッドのみがデータのクエリーとライトキャッシュを許可し、他のスレッドが待機します.2:異なるkeyは、異なる期限を設定し、キャッシュが無効になった時点をできるだけ均一にします.3:二次キャッシュを行い、A 1は元のキャッシュ、A 2はコピーキャッシュ、A 1が失効した場合、A 2にアクセスでき、A 1キャッシュの失効時間は短期、A 2は長期に設定.4:この時点でプログラムがキャッシュを更新しているかどうかを判断するためのタグを追加します.もしそうであれば、古いキャッシュに直接戻ります(プログラムエラーによるタグの削除なしによるキャッシュの更新の問題を避けるために、設定の失効時間がマークされています).そうでなければ、タグを設定し、データ取得とキャッシュ更新を行い、最後にタグを削除します.
キャッシュスルー、キャッシュ破壊、キャッシュ雪崩ソリューション分析
Redisが踏んだ穴-美団