Redis小結
4226 ワード
Redisに関する知識
1、なぜredisを使うのか
分析:ブロガーはプロジェクトでredisを使用すると感じて、主に2つの角度から考えます:性能と同時性.もちろん、redisは分散ロックなどの他の機能も備えているが、これらの他の機能を分散ロックするためだけに、zookpeerなどの他のミドルウェアの代わりに、redisを使用する必要はない.したがって,この問題は主に性能と同時の2つの角度から答えられる.パフォーマンス:実行に時間がかかり、結果が頻繁に変動しないSQLに遭遇すると、実行結果をキャッシュに入れるのに特に適しています.これにより、後続のリクエストがキャッシュから読み出され、リクエストが迅速に応答できるようになる. 同時:大同時の場合、すべてのリクエストがデータベースに直接アクセスし、データベースに接続異常が発生します.この場合、redisを使用してバッファ操作を行い、データベースに直接アクセスするのではなくredisにリクエストを先にアクセスさせる必要があります.
2、redisを使うにはどんな欠点がありますか
分析:みんなはredisをこんなに長く使って、この問題は理解しなければなりません.基本的にredisを使うといくつかの問題に遭遇します.よくあるのはいくつかです.
3、単一スレッドのredisはなぜこんなに速いのか
分析:この問題は実はredis内部のメカニズムに対する考察である.実際、ブロガーの面接経験によると、redisが単一スレッドワークモデルであることを知らない人が多い.だから、この問題は復習しなければならない.
4、redisのデータ型、および各データ型の使用シーン
分析:この問題は基礎的だと思っているのではないでしょうか.実は私もそう思っています.しかし、面接の経験によると、少なくとも80パーセントの人はこの問題に答えられないことが分かった.プロジェクトで使用した後、記憶よりも深く、無理に覚えないことをお勧めします.基本的には、合格したプログラマーは、5つのタイプで使用されます.
5.redisの期限切れポリシー及びメモリ淘汰メカニズム
分析:この問題は実はかなり重要で、結局redisが家に着いたかどうか、この問題は見ることができます.例えばredisは5 Gのデータしか保存できませんが、10 Gを書いたら、5 Gのデータを削除します.どうやって削除したのか、この問題を考えたことがありますか.また、あなたのデータには期限切れが設定されていますが、時間が来てもメモリの使用率が高いのは、原因を考えたことがありますか?
回答:redisは定期削除+不活性削除ポリシーを採用しています.
6.redisとデータベースの二重書き込みの一貫性の問題
分析:コンシステンシの問題は分散型の一般的な問題であり、最終的なコンシステンシと強いコンシステンシに分けることもできます.データベースとキャッシュの書き込みは、必ず一致しない問題があります.この問題に答えるには,まず一つの前提を明らかにする.つまり、データに強い一貫性が要求されると、キャッシュを入れることができません.私たちがしたことは、最終的な一致性を保証するしかありません.また,我々が行った案は根本的に言えば,不一致の発生確率を低減し,完全に回避できないとしか言いようがない.そのため,一貫性の要求が強いデータはキャッシュできない.
回答:まず、正しい更新ポリシーを取って、まずデータベースを更新して、それからキャッシュを削除します.次に、キャッシュの削除に失敗する可能性があるため、メッセージキューの利用などの補償措置を提供すればよい.
7、キャッシュスルーとキャッシュ雪崩問題にどう対応するか
分析:この2つの問題は、正直に言うと、一般的に中小規模の伝統的なソフトウェア企業では、この問題に遭遇するのは難しい.大きな同時プロジェクトがあれば、流量は数百万ぐらいです.この二つの問題は必ず深く考えなければならない.
キャッシュスルー、すなわちハッカーがキャッシュに存在しないデータを故意に要求し、すべての要求がデータベースにドロップされ、データベース接続が異常になる.
解決策:(一)反発ロックを利用してキャッシュが無効になった場合、まずロックを取得し、ロックを得てからデータベースを要求する.ロックが得られなければ、一時休眠して再試行(二)keyが値を取得するかどうかにかかわらず、非同期更新ポリシーを採用し、直接戻ります.value値ではキャッシュの失効時間を維持し、キャッシュが期限切れになった場合、非同期にスレッドを作成してデータベースを読み取り、キャッシュを更新します.キャッシュのウォームアップ(プロジェクトが起動する前にキャッシュをロード)操作が必要です.(3)要求が有効かどうかを迅速に判断できる遮断メカニズムを提供する.例えば、ブロンフィルタを利用して、内部で一連の合法的で有効なkeyを維持する.要求されたKeyが合法的に有効かどうかを迅速に判断する.合法でない場合は、直接戻ります.
キャッシュ雪崩、すなわちキャッシュが同じ時間に大面積で失効し、この時にまた要求が来て、その結果要求がデータベースに突き刺さり、データベース接続が異常になった.
解決策:(一)キャッシュの失効時間にランダム値を加え、集団失効を避ける.(二)反発ロックを用いるが,このスキームのスループットは著しく低下した.(3)デュアルキャッシュ.キャッシュ、キャッシュA、キャッシュBが2つあります.キャッシュAの失効時間は20分であり、キャッシュBは失効時間を設定しない.キャッシュウォームアップを自分で行います.次に、以下の小さな点を細分化します. IはキャッシュAからデータベースを読み、ある場合は に直接戻る. II Aにはデータがなく、Bから直接データを読み、直接戻り、更新スレッドを非同期で起動します. III更新スレッドは、キャッシュAとキャッシュBを同時に更新する.
参照先:https://www.cnblogs.com/bigben0123/p/9115597.html
1、なぜredisを使うのか
分析:ブロガーはプロジェクトでredisを使用すると感じて、主に2つの角度から考えます:性能と同時性.もちろん、redisは分散ロックなどの他の機能も備えているが、これらの他の機能を分散ロックするためだけに、zookpeerなどの他のミドルウェアの代わりに、redisを使用する必要はない.したがって,この問題は主に性能と同時の2つの角度から答えられる.
2、redisを使うにはどんな欠点がありますか
分析:みんなはredisをこんなに長く使って、この問題は理解しなければなりません.基本的にredisを使うといくつかの問題に遭遇します.よくあるのはいくつかです.
( )
( )
( )
( )
3、単一スレッドのredisはなぜこんなに速いのか
分析:この問題は実はredis内部のメカニズムに対する考察である.実際、ブロガーの面接経験によると、redisが単一スレッドワークモデルであることを知らない人が多い.だから、この問題は復習しなければならない.
( )
( ) ,
( ) I/O
1、 , I/O ( ) ( ) 。
2、I/O 。 ( ), I/O ( ), I/O 。 redis-client , socket。 , I/0 , 。 ,
, , , , I/O ,redis select、epoll、evport、kqueue , 。
4、redisのデータ型、および各データ型の使用シーン
分析:この問題は基礎的だと思っているのではないでしょうか.実は私もそう思っています.しかし、面接の経験によると、少なくとも80パーセントの人はこの問題に答えられないことが分かった.プロジェクトで使用した後、記憶よりも深く、無理に覚えないことをお勧めします.基本的には、合格したプログラマーは、5つのタイプで使用されます.
( )String
, set/get ,value String 。 。
( )hash
value , 。 , , cookieId key, 30 , session 。
( )list
List , 。 , lrange , redis , , 。
( )set
set 。 。 JVM Set ? , JVM Set, , , , 。
, 、 、 , , , 。
( )sorted set
sorted set score, score 。 , TOP N 。sorted set 。 。
5.redisの期限切れポリシー及びメモリ淘汰メカニズム
分析:この問題は実はかなり重要で、結局redisが家に着いたかどうか、この問題は見ることができます.例えばredisは5 Gのデータしか保存できませんが、10 Gを書いたら、5 Gのデータを削除します.どうやって削除したのか、この問題を考えたことがありますか.また、あなたのデータには期限切れが設定されていますが、時間が来てもメモリの使用率が高いのは、原因を考えたことがありますか?
回答:redisは定期削除+不活性削除ポリシーを採用しています.
?
, key, 。 , CPU 。 ,CPU , key, .
+ ?
,redis 100ms , key, key 。 ,redis 100ms key , ( 100ms, key ,redis )。 , , key 。
, 。 key ,redis , key ? 。
+ ?
, key。 key, 。 ,redis 。 。
6.redisとデータベースの二重書き込みの一貫性の問題
分析:コンシステンシの問題は分散型の一般的な問題であり、最終的なコンシステンシと強いコンシステンシに分けることもできます.データベースとキャッシュの書き込みは、必ず一致しない問題があります.この問題に答えるには,まず一つの前提を明らかにする.つまり、データに強い一貫性が要求されると、キャッシュを入れることができません.私たちがしたことは、最終的な一致性を保証するしかありません.また,我々が行った案は根本的に言えば,不一致の発生確率を低減し,完全に回避できないとしか言いようがない.そのため,一貫性の要求が強いデータはキャッシュできない.
回答:まず、正しい更新ポリシーを取って、まずデータベースを更新して、それからキャッシュを削除します.次に、キャッシュの削除に失敗する可能性があるため、メッセージキューの利用などの補償措置を提供すればよい.
7、キャッシュスルーとキャッシュ雪崩問題にどう対応するか
分析:この2つの問題は、正直に言うと、一般的に中小規模の伝統的なソフトウェア企業では、この問題に遭遇するのは難しい.大きな同時プロジェクトがあれば、流量は数百万ぐらいです.この二つの問題は必ず深く考えなければならない.
キャッシュスルー、すなわちハッカーがキャッシュに存在しないデータを故意に要求し、すべての要求がデータベースにドロップされ、データベース接続が異常になる.
解決策:(一)反発ロックを利用してキャッシュが無効になった場合、まずロックを取得し、ロックを得てからデータベースを要求する.ロックが得られなければ、一時休眠して再試行(二)keyが値を取得するかどうかにかかわらず、非同期更新ポリシーを採用し、直接戻ります.value値ではキャッシュの失効時間を維持し、キャッシュが期限切れになった場合、非同期にスレッドを作成してデータベースを読み取り、キャッシュを更新します.キャッシュのウォームアップ(プロジェクトが起動する前にキャッシュをロード)操作が必要です.(3)要求が有効かどうかを迅速に判断できる遮断メカニズムを提供する.例えば、ブロンフィルタを利用して、内部で一連の合法的で有効なkeyを維持する.要求されたKeyが合法的に有効かどうかを迅速に判断する.合法でない場合は、直接戻ります.
キャッシュ雪崩、すなわちキャッシュが同じ時間に大面積で失効し、この時にまた要求が来て、その結果要求がデータベースに突き刺さり、データベース接続が異常になった.
解決策:(一)キャッシュの失効時間にランダム値を加え、集団失効を避ける.(二)反発ロックを用いるが,このスキームのスループットは著しく低下した.(3)デュアルキャッシュ.キャッシュ、キャッシュA、キャッシュBが2つあります.キャッシュAの失効時間は20分であり、キャッシュBは失効時間を設定しない.キャッシュウォームアップを自分で行います.次に、以下の小さな点を細分化します.
参照先:https://www.cnblogs.com/bigben0123/p/9115597.html