Redis 01-Redis要点まとめ

8825 ワード
分散システム redis epoll

Redisの要約


スタンドアロンRedis


なぜRedisが現れたのか

  • 従来のリレーショナル・データベース・ディスク・ストレージは、schemaタイプ(バイト幅)を指定する必要があるため、データベースは行レベル・ストレージです.データテーブルが大きいとパフォーマンスが低下します.テーブルにインデックスがある場合は、削除と変更が遅く、クエリーの速度が同時に多すぎる場合は
    • が遅くなります.
  • SAPのHANAはメモリクラスのリレーショナルパンツで、速いけど非常に高いですが、また、データはディスクとメモリで体積が異なる(ディスクにポインタがないため、同じデータが複数コピーされて記憶されるため、データが膨らみ、メモリにポインタがあるため、同じデータは1部しか保存されず、異なるポインタでそのデータを指すため、メモリ格納データ空間は磁気格納よりも小さい)
    • .
  • ディスク->アドレッシング:ms、帯域幅:G/Mメモリ->アドレッシング:ns、帯域幅:大きなディスクは内部アドレッシングより10 W遅い、I/O buffer:コストの問題、ディスクとトラック、セクタ512 Byteインデックス4 K、オペレーティングシステム、いくら読んでもディスクから最低4 K
    • を取る
  • Redisとmemcacheは折衷の選択で、速度が速く、価格が安い
    • です.

    アーキテクチャーデータストアの選択比較Webサイト

             ： https://db-engines.com/en 

https://redis.io  
http://www.redis.cn/  ---

    Redisインストール

    https://redis.io
http://www.redis.cn/  ---
  • BIOブロックI/O:アプリケーションプロセスが1 K個の要求を開始すると、1 K個のsocketファイル記述子が開き、socketはカーネルからのデータの返却を待つときにブロック式であり、データの準備ができていないうちにデータが戻ってくるまで待機をブロックし続け、次のsocketからの
    • を待つ
  • NIOポーリング非ブロックI/O:アプリケーションプロセスが1 K個の要求を開始すると、ユーザースペースでこの1 K個のsocketファイル記述子をポーリングし続け、結果が返されるかどうかを確認する.この方法はブロックしないが,効率が低すぎて無効なサイクルが大量にある
  • I/O多重(select,poll,epoll)select:開くことができるファイル記述子の数は限られており(最大1024個)、1 K個の要求があれば、ユーザープロセスは毎回1 K個のファイル記述子をカーネルに送り、カーネルは内部ポーリング後に可読記述子を返し、ユーザープロセスは順次読み出す.ファイル記述子(fd)関連データはユーザ状態とカーネル状態の間でコピーする必要があるため、性能は比較的低いpoll:開くことができるファイル記述子の数は向上しているが、性能は依然としてepoll(Linuxの下ではこの技術が多い):ユーザ状態とカーネル状態の間にはファイル記述子(fd)のコピーではなく、mmap技術によって共有空間を開き、すべてのfdは赤と黒の木で格納されている.返却結果のあるfdはチェーンテーブルに置かれ、ユーザープロセスはチェーンテーブルを通じて返却結果を読み取る、擬似非同期I/O、性能が高い
    • .
  • AIO:非同期I/O、最高の性能ですが、使用は非常に複雑で、あまりよく使われていません(windowsシステムでは多く見られます)

    • RPC I/Oモデル，BIO，NIO，多重I/O，AIO

  • BIOブロックI/O:アプリケーションプロセスが1 K個の要求を開始すると、1 K個のsocketファイル記述子が開き、socketはカーネルからのデータの返却を待つときにブロック式であり、データの準備ができていないうちにデータが戻ってくるまで待機をブロックし続け、次のsocketからの
    • を待つ
  • NIOポーリング非ブロックI/O:アプリケーションプロセスが1 K個の要求を開始すると、ユーザースペースでこの1 K個のsocketファイル記述子をポーリングし続け、結果が返されるかどうかを確認する.この方法はブロックしないが,効率が低すぎて無効なサイクルが大量にある
  • I/O多重(select,poll,epoll)select:開くことができるファイル記述子の数は限られており(最大1024個)、1 K個の要求があれば、ユーザープロセスは毎回1 K個のファイル記述子をカーネルに送り、カーネルは内部ポーリング後に可読記述子を返し、ユーザープロセスは順次読み出す.ファイル記述子(fd)関連データはユーザ状態とカーネル状態の間でコピーする必要があるため、性能は比較的低いpoll:開くことができるファイル記述子の数は向上しているが、性能は依然としてepoll(Linuxの下ではこの技術が多い):ユーザ状態とカーネル状態の間にはファイル記述子(fd)のコピーではなく、mmap技術によって共有空間を開き、すべてのfdは赤と黒の木で格納されている.返却結果のあるfdはチェーンテーブルに置かれ、ユーザープロセスはチェーンテーブルを通じて返却結果を読み取る、擬似非同期I/O、性能が高い
    • .
  • AIO:非同期I/O、最高の性能ですが、使用は非常に複雑で、あまりよく使われていません(windowsシステムでは多く見られます)

    • キャッシュデータ型


    memcache

    key，value   ：value        ，   Redis。          json，

    Redis

    1. Redis    、   、   、  epoll     I/O  ，           client          
2. Redis             ，        
3. Redis value  String、List、Hash、Set、Sorted\_set  
 1) String:       、  、bitmap（1.           ，       2.      ，      
   ）  
 2) List:        ，         ，List    （0，1，2...），    （-1，-2，-3...）  
 3) Hash: key field value  
 4) Set:       ，   ，            
 5) Sorted\_set:          ，      ，      ，         （skip list）

    Redisステップ使用

  • 購読および配布
  • Redisの事務:誰が先にexecを実行して、先にどの物事を実行して、Redisは物事のロールバックを支持しません
  • ブロンフィルタ(アップグレード版:Countingブロンフィルタ、布谷鳥フィルタ):存在しないKeyを多重Hashアルゴリズムで大まかにフィルタリングし、キャッシュスルーの問題を解決するが、依然としてKeyが存在しないクエリがデータベースに到達し、Redisに関連Keyを設定し、valueをnullに設定することができるが、このような設定には期限切れ時間(https://github.com/RedisBloom/RedisBloom)
    • を設定する必要がある

    キャッシュでよくある質問

    • を撃破
  • 雪崩
    • を貫通
  • 整合性(デュアルライト)

    • Redisスタンドアロン持続化

  • RDB:スナップショット/レプリカ
  • AOF(データはすべてそろっているが、ファイルは大きく、回復は遅い):ログ、4.0以降のRedisはAOF書き換えをサポートし、古いデータRDBをAOFに、増分部分はAOF
    • である.

    Redisクラスタ


    なぜRedisクラスタがあるのか


    Redisシングルマシン・シングル・プロセスは、キャッシュとしてもデータベースとしても使用でき、2つの持続化方式RDBとAOFを有する.

    シングルマシン、シングルノード、シングルインスタンスの問題:

    1.       
2.       
3.         
  AKF       ，          
AKF----X，Y，Z          
X ：Redis       ，               
Y ：    、    Redis    ，       ，     ，               
Z ：     、       ，    1～10000   ，20001～30000

    X軸データミラーバックアップデータの整合性の問題：


    データ同期の3つのアーキテクチャ:
  • プライマリ・ライブラリを更新し、更新バックアップを同期的にブロックすると、可用性が損なわれます.
  • プライマリ・ライブラリを更新し、非同期でスタンバイ・ライブラリを更新すると、データの損失(Redis選択)
    • をもたらす可能性があります.
  • はメインライブラリを更新し、更新kafka(信頼性の高いメッセージキュークラスタ、応答速度が速い)を同期的にブロックし、最終的なデータ整合性は、短時間でデータ不整合がある可能性がある
    • である.
    Redisシステムが最も強調しているのは性能であり,それは速いために生まれたので,最後のkafkaのスキームを選択するのではなく,選択した第2のスキームである.

    Redisマスターコピーモード


    Redisのプライマリ・スタンバイ方式、プライマリ・リード・ライト、自身がまた1つのシングル・ポイントであり、依然としてシングル・ポイント障害の問題が存在し、プライマリ・スタンバイが停止した場合、ライト・データ操作を行うことができず、データの読み取り可能な操作も行うことができる(スタンバイから読み取る)
    そのため、主にHAを高可用性で行う必要があり、自動的にフェイルオーバし、「代替者」を選択し、アップグレードを主とする
    監視プログラムが主の健康状況を監視する必要があり、誤殺しないことを保証するために、複数の監視プログラムが同時に監視し、主の健康状況に対して投票採決を行う必要がある.そのため、監視プログラムは一般的に奇数個で、半数以上の監視プログラムが主が掛かっていると判断し、新しい主を選出する.
    マスターコピー構成アイテム:
    replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no   ----          
repl-backlog-size 1mb   ----      
min-replicas-to-write 3
min-replicas-max-lag 10

    Redis高使用Sentine哨兵モード

          

redis-sentinel  
redis-server --sentinel  
#    ，Redis      
port 26379  
sentinel monitor mymaster 127.0.0.1 6381 2  
                                         |

    Redis容量の問題解決


    AKF分割原則:X、Y、Z
    プライマリスレーブレプリケーションは、プライマリHA、Xの問題を解決することができますが、単一ノードの容量の問題はまだ解決されていません.そのため、データを分割する必要があります.データのカプセル化には4つの方法があります.
  • データは分類することができ、業務によって
    • を分割することができる.
  • データは分類できずmodulaアルゴリズム(hash+型取り)によりshardingを行い、弊害:型取りの数は分布式での拡張性
    • に固定し、影響しなければならない.
  • データは分類できず、randamアルゴリズム(ランダムlpushからRedisの1つのノードに、もう1つのrpopから)によってshardingが行われ、メッセージキューシーン
    • に類似する.
  • データは分類できず、kemataアルゴリズム(コンシステンシハッシュアルゴリズム)によってshardingを行い、hashアルゴリズムは(CRC 16、CRC 32、FNV、MD 5マッピングアルゴリズム)コンシステンシHashアルゴリズムを含む:0～2^32個の仮想的な点を計画し、計算(IPのHASH値)によって各物理ノードをリングの上にある点に位置させ、データはリング上にある点を計算し、この点は一般的に物理ノードがなくて、時計回りに彼に最も近い物理ノードを探して、このようにもし新しいノードを追加するならば、データの移行を必要としないで、ただそのノードが自分でゆっくりと予熱することを待つだけで、彼の後ろのノードはLRU、LFU淘汰アルゴリズムを設定して、データの移転の利点を実現することができます:ノードを追加して、確かに他のノードの圧力を分担することができて、グローバルシャッフルの欠点をもたらすことはありません:新しいノードは一部のデータが命中できないことをもたらして、破壊の問題をもたらして、mysqlに押して、データの最も近い2つのRedisの方法から
    • を解決することができます
    以上のシナリオは、データベースではなくRedisをキャッシュとして使用します.

    Redisクラスタエージェントスキーム


    Redisクラスタエージェントがない場合は、接続コストが高すぎて、各クライアントが各サーバに接続する必要があります.
    エージェント層でshardingアルゴリズムを実現し、modula、random、kemata、エージェントproxyの前にLVS+VIPを使用することもでき、クライアントのアクセスを透明にし、keepalivedはLVSの高可用性を保証する.
    ≪データ・スライスの事前割当てスキーム｜Pre Assignment Schemas for Data Block｜oem_src≫:データ・スライスをより高速に分割し、実際のノードごとに数ブロック保存します(Redis clusterスキーム).
    proxyエージェントスキーム
    1. twitter Redis    ， Github    twemproxy  ----      (https://github.com/twitter/twemproxy  http://www.redis.cn/topics/partitioning.html)
2. predixy Redis      ，  sentinel cluster  ----      （https://github.com/joyieldInc/predixy/blob/master/README_CN.md）
3. redis cluster   ----   16384   ，         ，            ，  ，       sharding，       sharding，     sharding。       ，         Key（   ）       sharding （http://www.redis.cn/topics/cluster-tutorial.html）

    Redis面接のよくある質問とAPI


    Redis FAQ


    ブレークスルー
        ：  KEY      ，           ，       
  ：KEY              
    ：1.get key 2.setnx(    ) 3-1.OK, DB    3-2.false sleep ->1
      ：1.        ，       ？->          
            2.        ，        ？->   ，     DB，          DB  ，      
                     
#          ，  redis            ，  Redis AP  ，     CP  ， AP  CP，

    突き抜ける
        ：                      
  ：        ，       
    ：       （        ，        ），    key               （   
    ）

    雪崩
        ：  KEY      
  ：        DB  
    ：  KEY         ，          ，      ，         ，

    RedisAPI


    SpringBoot
    https://docs.spring.io/spring-boot/docs/2.2.4.RELEASE/reference/html/spring-boot-features.html#boot-features
    https://docs.spring.io/spring-data/redis/docs/2.2.4.RELEASE/reference/html/#
    Jedis
    https://github.com/xetorthio/jedis
    Lettuce
    https://github.com/lettuce-io/lettuce-core
    どのようにノードを使用してビング検索scrapeする.JS ?
    開発者プロジェクト図書リスト