Redisコーミングレコード

はじめに

Redisは2008年にイタリアの会社Merziaの創設者であるサルバトーレサンドフィリッポによってリアルタイム統計システムLLOOGGのために作成されました。これはC言語で開発されました。目的はMySqlの同様の機能を持つデータベースを開発することですが、パフォーマンスを大幅に向上させることができます。コード寄稿者のPieter NoordhuisがRedisのために一緒に開発されました。今日まで、最新バージョンは5です。

Redisは、リモート辞書サーバーであるREmote DIctionary Serverの略です。Redisのデフォルトポートは6379で、サポートされているデータタイプは次のとおりです。

  • 文字列
  • ハッシュタイプ(キー値もディクショナリ構造ですが、フィールドの値は文字列のみです)
  • リストのタイプ(順序付け、一意ではない)
  • コレクションタイプ(順不同、それぞれ一意)
  • 順序付けられたコレクションタイプ(順序付けられ、それぞれ一意)

Redisのパフォーマンス

Redisはシングルスレッドモデルであり、理論的にはマルチスレッドモデルのMemcachedよりも劣りますが、一般的に言えば、Redisのパフォーマンスとパフォーマンスは十分です。2つのパフォーマンスは、2つの主な違いであってはなりません。機能の違いは、それを使用する際に考慮される主な要因である必要があります。両者の評判と機能の違いを考慮すると、Redisが一般的に優先されます。

一般的なコマンド:

  • キーを取得
  • キー値を設定
  • 追加する
  • 存在キー#existenceは1を返し、非存在キーは0を返します

起動時に特定のポートメソッドを指定します。

redis-server --port 6380

redis-cli -h 192.168.0.1 -p 6380

Redisパイプライン

コマンドを実行する場合、コマンド数が多い場合、1つずつ実行して実行するたびに戻ると、実行効率がやや低下し、パフォーマンスに影響します。この場合、Redisパイプラインモードで運用できます。パイプラインを通じて一度に複数のコマンドを送信し、実行が完了した後で結果を一度に返すことができます。一連のコマンドの各コマンドが前のコマンド実行の結果に依存しない場合は、この一連のコマンドを一緒にパイプラインを通じて発行できます。 、パイプラインは、クライアントとRedis間の通信数を減らすことにより、Redisスループットを向上させる目的を達成します。

バッファー浸透効果

キャッシュは、データベースの保護壁と言えます。一般に、キーをキャッシュし、フロントエンドがこのキーに関するクエリを持っている場合、キャッシュに直接クエリして結果を返します。ただし、クエリしたキーがキャッシュにない場合は、このキャッシュの壁の後で、この壁は機能しないため、多数のクエリがデータベースに直接到達し、データベースのクエリプレッシャーが急激に増加します。このようにして、キャッシュの意味が失われます。これは、キャッシュ浸透効果と呼ばれます。

バッファー浸透効果は避けられないものではなく、可能な限り合理的な範囲内でしか制御できません。使用される技術的手段はブルームフィルターです。

キャッシュなだれ

キャッシュアバランシェは、多数のキャッシュが同時に失敗し、多数のリクエストがデータベースに到達し、データベースのプレッシャーが大幅に増加したり、ハングアップしたりする状況です。

キャッシュアバランシェソリューションには次のものがあります。

1. Redisクラスターの使用など、キャッシュの高可用性を改善して、マシンの1つがハングアップした後にすべてのキャッシュが失われないようにします。

2.キャッシュの有効期限は、すべてのキャッシュの無効化を同時に回避するために、可能な限り分散する必要があります。

3.一般的なキャッシュの場合、通常の更新方法を使用して、キャッシュデータを無効にすることなく更新できます。

4.データベースの処理能力を超える大量のデータクエリを回避するために、サービス電流制限とインターフェイス電流制限。

Redisの永続性

Redisを永続化するには2つの方法があります。

1つ目:設定されたルールに従って、Redisは定期的にデータをハードディスクのメモリに保存します。このメソッドはRDBメソッドと呼ばれます。

2番目:Redisが各コマンドを実行した後、将来使用するためにコマンド自体を記録します。このメソッドはAOFメソッドと呼ばれます。

2つの永続化メソッドは、独立して、または同時に使用できますが、一般的には、2種類の永続化メソッドが一般的です。

Redisの高可用性

Redisの実際の使用では、1台のマシンだけでは十分でないことがよくあります。高可用性を実現するには、Redisクラスターをデプロイする必要があります。Redisクラスターをデプロイする場合、マスターライブラリは設定を必要としませんが、スレーブライブラリで設定する必要があります:redis-server --port **** --slaveof IP:port。Infoレプリケーションを使用して、クラスターマシン間の接続を表示します。Redisクラスターでは、ライブライブラリは読み取りと書き込みが可能ですが、スレーブライブラリは読み取りのみが可能で、書き込みはできません。マスターライブラリとスレーブライブラリ間の同期作業は非同期モードで実現され、スレーブでハードディスクまたはハードディスクコピーなしの形式を使用できます。ライブラリはSYNCコマンドをマスターライブラリに送信します。コマンドを受信すると、マスターライブラリはバックグラウンドでメモリファイルを生成し、それを非同期でスレーブライブラリに送信します。ハードディスクがない場合は、スレーブライブラリにデータを送信します。

Redisクラスタを用意するだけでは不十分です。Sentinelと呼ばれるモニタリングツールも必要です。このツールはRedis 2.8でバージョン2.0にアップグレードされています。クラスタのモニタリングにはこのバージョンを使用してください。Sentinelはクラスタ内の各ライブラリを監視でき、相互に監視することもできます。関数は次のとおりです。

1.マスターライブラリとスレーブライブラリの通常の動作を監視する

2.マスターライブラリが失敗すると、スレーブライブラリはマスターライブラリに変換されます

現在、推奨される方法は、クラスターモードです。このモデルのアイデアは分散化であり、実現するには少なくとも6つのノードが必要です。

おすすめ

転載: www.cnblogs.com/jizhong/p/12678400.html