Redisの上の詳細記事
分散ロック・リアライズどのようにRedisの
使用セット（文字列キー、文字列値、文字列nxxx、ストリングexpx、長い時間） 方法、
メソッドパラメータの説明：
- キーロックキーの値があまり説明することではありません
- 値多くの学生も値やってロックを手に入れるために頼むだろうか？ロックを解除することができるユーザーを制御するための値、または再ロックアライメントリエントラントするかどうか。
- nxxxはNXまたはXXをとることができます。
- キーが存在しないNXセット成功
- XXキーセットがある場合
- のみEX又はPXを取るpxex：有効期限を表すデータ単位を、時間フィールドを記述するため
- 秒でEX
- PXミリ秒
- 時間が時間を満了し、ユニットは、ユニット表現expxです
戻り値の詳細な方法：成功の代わりに、文字列「OK」を返します。それ以外の場合は、挿入に失敗しました
光は何も処理時にロックが占有されているシーンが存在しないため、この方法は、役に立たない知っています。
また、あなたは、スピンやロック・タイムアウトを設定する必要があります。
再びスピンロックを取得しようとすると等価ですどのくらいの期間、
タイムアウトがスピンはまだない取得に成功したロックがドロップされたどのくらい後に相当します
Aタイムアウト仮説タイムアウト= 10000ミリ秒スピン間隔ごとに設定すると、100ミリ秒である
スピンtimeout- = 100あたり;ときにスピンのタイムアウト<= 0終了。コードは以下の通りです
int timeout = 10000;
long expires = 60000L;
while(timeout >= 0) {
if ("OK".equalsIgnoreCase(jedis.set(lockKey, lockValue, "NX", "PX", expires))) {
return true;
}
timeout -= 100;
Thread.sleep(100L);
}
拡張論文は（ネギの教室は、それを開始しました！）
保証は全体の操作のアトミック性がないためsetnx +メソッドを使用して期限切れに分散ロックを書いてブログの多くは、間違っているがあります。
プログラムは、突然（setnxを実行した後にクラッシュした場合）、ロックが生じることは有効期限が設定されていません。そして、デッドロックが（期限が切れていると解放されません）が発生します。
ケースエラーコード：
if (1L == jedis.setnx(lockKey, lockValue)) {
// 若在这里程序突然崩溃，则无法设置过期时间，将发生死锁
jedis.expire(lockKey, expireTime);
}
再入国を達成するためにどのようにそれをロック？
リエントラントロックが何であるかでまず外観
キーの当量ロックにリエントラントロック、任意のスレッドは、対応するリリースされていないロックの場合に再びロックされ、ロックを解除するキーを保持してもよいです。
後リエントラントロックの意味を知っている設定上記の方法で解決策を考えることは非常に簡単ではありませんか？
思考：requestIdで見つかった場合には（存在する場合）しようとすると、ThreadLocalのときにロックされるからロックするために上記の方法の値の設定値をrequestId（UUIDまたは他の一意の識別子）を提供してもよい、requestId（ThreadLocalの）に格納されているスレッドローカル変数は、除去しました値の比較値と等しい場合、真、再設定有効期限を返します。
再入国ロックを完了するためにここにいるということではないですか？しかし、それはしていません！
リエントラントロックはロックの繰り返し記録番号を取得する必要があります。ロックを解除し、ロックが再入可能であるため、ロックはロック例存在しない場合に直接、外部操作の実装につながっリリースロックアウトの内端に番号、事業執行を入力する場合があり、削除できませんセキュリティ問題。再入国の累積数は、その後、リリース時に再入国の数を引いたときにそのため、あなたがロックを取得する必要があり、0に減少した場合、あなたはロックを解除することができます。
それはどのようにデータ・キャッシュとデータベースの整合性を行います
：すべての読み取りが自然に矛盾表示されていない場合だけのことを確認する必要があり、書き込み動作の場合は必須で、あるデータの整合性
プログラム：最初にデータベースを変更して、Redisのキャッシュを削除し、キャッシュは、一般的に失敗を設定するために必要とされます極端な場合には不整合を回避するための時間、。
なぜ直接変更するのではなく削除]を選択しますか？なぜ、代わりにフロントの背面にあるデータベースへの書き込みを削除する必要がありますか？
- 代わりに直接変更の削除を選択し
、スレッドAの書き込みが高い並行処理で実行される場合、正常にデータベースを更新し
、この時のスレッドBも行われ、同様の動作をスレッドが、キャッシュを更新プロセススレッドAの実行中に、スレッドBが更新キャッシュに新しいデータベースのデータ、
すべてがキャッシュにのみ比較的スレッド内の古いデータや更新をスレッドBが実行された後、これはそれが一貫性のないデータ・キャッシュとデータベースの問題につながる発生したとき。 - 何背面ではなく前面にデータベースへの書き込みを削除する必要があります
クエリを削除するスレッドがある場合は、データベースのデータの矛盾の問題に古いデータを更新するためと、キャッシュがデータベースに正常に書き込まれていない前に発生します。
キャッシュの浸透、故障のキャッシング、キャッシング・ソリューション雪崩
キャッシュの浸透
- 用語集：キーユーザーは、データベースをチェックし、クエリデータを望んでいると何のRedisのメモリを発見した、データベースはしませんでした。このキー時間を確認するために多数の要求がキャッシュに浸透することで永続化層の上に大きな圧力が発生しますとき
- ソリューション：
1、データベース内のキャッシュ・オブジェクトはRedisのに持っていない空は、それを保存し、有効期限が存在を設定します。
図2に示すように、ブルームフィルタ、すべてのパラメータは、ユーザが見つかった（または独自の検証ルールを定義する）フィルタリングブルームを使用してクエリしたい場合、ハッシュ・クエリ形式で格納することができるが、より長い、廃棄に設定されていません永続化層クエリ。
キャッシュの内訳
- 用語解説：このポイントへの同時大集中アクセス、現在進行中の大規模なキャッシュによって複雑キー障害が、身に着けていた瞬間、データベースへの直接の要求、大規模な同時実行を運ぶ重要な非常に高温、ノンストップです圧力サージにデータベースを起こします。
- ソリューション：
1は、ホットキーの有効期限が切れることはありません
取得がデータベースにチェックするために行った場合、特定の中でロックを取得しない場合は2を、ミューテックス、キーが存在しない場合は、クエリキャッシュを取りに行く、その結果は、書き込みキャッシュで見つかりましたその後、キャッシュを取得する時間。
キャッシュ雪崩
- 用語解説：キャッシュ短時間で障害の多数または突然ハングする記憶層を得、データベースクエリの圧力サージを導く、ハングアップのRedis。
- ソリューション：
1、ハングアップすることが可能であるため、RedisのRedisの利用可能性は、その後、私はそのようなハングが、実際には、それはビルドクラスタにした後、他の仕事を続けることができ、さらにいくつかの追加のRedisよりもです。
2、ミューテックス（同書）
3は、であっても可能な限りキャッシュミスの時点で異なる満了時間を設定します。
あなたは私たちがあなたや、彼らが方向を変更されませんインタビュアーはありませんが、Redisのクラスタ、それをに関連する問題について何を話をする方法の事に沿って依頼する面接の質問をするので、最終的には、クラスタをRedisの若い男に相談してください。だからあなたの次の質問への基本的な答えは、あなたの答えから意味するかもしれません。
私の次のクラスタは、それを終えました。
