1. キャッシュに関する知識
1.1 キャッシュの概念
キャッシュとは、CPU の 1 次キャッシュと 2 次キャッシュなど、速度が異なる 2 つ以上の物質の速度を調整し、中央の遅い方を高速化することです。メモリは最近 CPU が頻繁にアクセスするデータを保存し、メモリは CPU が頻繁にアクセスするデータをハードディスクに保存します。ハードディスクにはさまざまなサイズのキャッシュもあり、物理サーバーの RAID カードにもキャッシュがあります。 CPU のハードディスク データへのアクセスを高速化するために使用されます。CPU の速度が速すぎるため、CPU が必要とするデータは、ハードディスクのせいで短時間に CPU のニーズを満たすことができなくなります。 CPU キャッシュ、メモリ、RAID カード キャッシュ、ハードディスク キャッシュは、CPU のデータをある程度満たすことができ、CPU がキャッシュからデータを読み出すという要件を満たすことで、CPU の作業効率を大幅に向上させることができます。
1.2 システム キャッシュ
バッファとキャッシュ:
バッファ: バッファは書き込みバッファとも呼ばれます。通常、書き込み操作に使用されます。データは最初にメモリに書き込まれ、次にディスクに書き込まれます。バッファは通常、書き込みバッファに使用され、異なるメディアの速度が一貫していないバッファを解決するために使用されます。データは最初に一時的に書き込まれます。書き込み速度を上げるために、CPU は最初にデータをメモリのディスク バッファに書き込み、次にデータが書き込まれたと判断し、カーネルが次の場所に書き込みます。そのため、サーバーの突然の停電により、メモリ内のデータの一部が失われます。
キャッシュ: キャッシュはリード キャッシュとも呼ばれます。一般に読み取り操作に使用されます。CPU はメモリからファイルを読み取ります。メモリがない場合は、ハードディスクからメモリに読み取り、次に CPU に読み取ります。必要なデータを置きます。最も近いキャッシュ領域に頻繁に読み込まれるため、次回読むときにすぐに読むことができます
1.3 キャッシュの保存場所と階層構造
インターネットアプリケーションの分野では、キャッシュがサービスの応答速度向上の鍵となります
ユーザー層: ブラウザー DNS キャッシュ、アプリケーション DNS キャッシュ、オペレーティング システム DNS キャッシュ クライアント プロキシ
層: CDN、リバース プロキシ キャッシュ
Web 層: Web サーバー キャッシュ
アプリケーション層: ページ静的
データ層: 分散キャッシュ、データベース
システム層: オペレーティング システム キャッシュ
物理層: ディスクキャッシュ、RAIDキャッシュ
DNS キャッシュ
ブラウザの DNS キャッシュのデフォルトは 60 秒です。つまり、60 秒以内に同じドメイン名にアクセスされた場合、DNS 解決は実行されません。
アプリケーション層キャッシュ
Nginx や PHP などの Web サービスは、アプリケーション キャッシュを設定してユーザー リクエストへの応答を高速化できます。また、PHP/Python/Java などの一部のインタープリタ言語は直接実行できず、最初にバイトコードにコンパイルする必要がありますが、バイトコードマシンコードは後でしか実行できないため、バイトコードは一種のキャッシュでもあり、プログラムコードの起動後にバイトコードが更新されない現象が発生することがあります。したがって、新しいバージョンを起動する前に、まずアプリケーション キャッシュをクリアしてから、新しいバージョンを起動する必要があります。
さらに、動的ページ静的技術を使用して、アクセスを高速化することができます。たとえば、データベース データの動的ページにアクセスするには、プログラムを使用して静的ページ ファイル html を事前に生成し、電子商取引 Web サイトの商品紹介、コメント情報、この技術を利用することで、非リアルタイムデータなどを実現できます。
データ層キャッシュ
分散キャッシュサービス:
Redis
Memcached
データベース:
MySQL クエリ キャッシュ
、innodb キャッシュ、MYISAM キャッシュ、
ハードウェア キャッシュ、
CPU キャッシュ (L1 データ キャッシュおよび L1 命令キャッシュ)、レベル 2 キャッシュ、レベル 3 キャッシュ
ディスク キャッシュ: ディスク キャッシュ
ディスク アレイ キャッシュ: RAID キャッシュ、バッテリーによる防止が可能電力損失 データ
2. リレーショナル データと非リレーショナル データベース
2.1 リレーショナル データベース
リレーショナル データベースは、リレーショナル モデル (2 次元テーブル モデル) に基づいて構築された構造化データベースであり、一般にレコードを指向しています。
SQL ステートメント (Standard Data Query Language) は、リレーショナル データベースに基づいた言語であり、リレーショナル データベース内のデータの検索と操作を実行するために使用されます。
主流のリレーショナル データベースには、Oracle、MySQL、SQL Server、Microsoft Access、DB2、PostgreSQL などが含まれます。
上記のデータベースを使用する場合、まずデータベースを構築し、テーブルを構築し、テーブル構造を設計し、その後テーブル構造に従ってデータを格納する必要があり、データがテーブル構造と一致しない場合、格納は失敗します。
2.2 非リレーショナル データベース
NoSQL (NoSQL=NotonlysQL) は、「SQL だけではない」という意味で、非リレーショナル データベースの総称です。
主流のリレーショナル データベース以外のデータベースは、非リレーショナルとみなされます。
データ ストレージ テーブル構造を定義するためにデータベースとテーブルを事前に構築する必要はなく、各レコードには異なるデータ型とフィールド数 (WeChat グループ チャットのテキスト、写真、ビデオ、音楽など) を含めることができます。
主流の NOSQL データベースには、Redis、MongBD、Hbase (ビッグ データに使用される分散型非リレーショナル データベース)、Memcached、ElasticSearch (ES、インデックス付きデータベースと呼ばれる)、TSDB (時間連続データベース) などが含まれます。
2.3 リレーショナル データベースと非リレーショナル データベースの違い:
(1) データ保存方式の違い
リレーショナル データベースと非リレーショナル データベースの主な違いは、データの保存方法です。
リレーショナル データは本質的に表形式であるため、データ テーブルの行と列に格納されます。データテーブルは相互に関連付けて共同して保存でき、データの抽出も簡単です。
対照的に、非リレーショナル データはテーブルの行や列に収まらず、大きな塊にグループ化されます。非リレーショナル データは通常、ドキュメント、キーと値のペア、グラフ構造などのデータセットに保存されます。データとその特性は、データの保存方法と抽出方法を選択する際に最も影響を与える要素です。(データセット内に複数のデータ型が存在するため、データ型を切り替えるのは簡単です)
(2) 拡張方法の違い
SQL データベースと NoSQL データベースの最大の違いは、拡張の方法にあると考えられますが、増大する需要に対応するには、当然のことながら拡張が必要です。
より多くの同時実行性をサポートするために、SQL データベースがスケールアップされます。つまり、処理能力が向上し、より高速なコンピューターを使用することで、同じデータ セットをより速く処理できるようになります。データはリレーショナル テーブルに格納されるため、多くのテーブルが関係する操作のパフォーマンスのボトルネックは、コンピューターのパフォーマンスを向上させることで克服する必要があります。SQIデータベースは発展の余地が大きいとはいえ、最終的には垂直方向の拡張の上限に達するのは間違いない。(データは通常、ローカル ファイル システムに保存されます。読み取りは読み取りと書き込みの分離と負荷分散を通じてパフォーマンスを共有できますが、読み取りと書き込みは依然として IO パフォーマンスを消費します。)
NoSQL データベースは水平方向に拡張します。非リレーショナル データ ストレージは自然に分散されるため、NoSQL データベースの拡張では、より一般的なデータベース サーバー (ノード) をリソース プールに追加することで負荷を分散できます。(データ分散は別のサーバーに保存され、効率を高めるために同時に読み取りと書き込みが可能です)
水平方向の拡張: サーバーを追加します。(安い)
垂直方向の拡張: より高性能な CPU への変更、CPU コア、ハードディスク、ディスク IO、メモリー スティックの数の増加など、ハードウェア構成を改善します。(ハードディスクを除き、追加するには他のハードディスクをシャットダウンする必要があります)
(3) トランザクションに対するさまざまなサポート
データ操作で高いトランザクション性が必要な場合、または複雑なデータ クエリで実行計画を制御する必要がある場合は、パフォーマンスと安定性の点で従来の SQL データベースが最適な選択です。SQL データベースはトランザクションのアトミック性に対するきめ細かい制御をサポートしており、トランザクションのロールバックも簡単です。
NoSQL データベースもトランザクション操作を使用できますが、安定性の点ではリレーショナル データベースには及ばないため、その真の価値は操作のスケーラビリティと大量のデータの処理にあります。
非リレーショナル データベースは、トランザクション処理と安定性の点でリレーショナル データベースに劣ります。ただし、読み取りおよび書き込みのパフォーマンスが高く、拡張が容易で、大規模なデータの処理に有利です。
リレーショナル データベース: トランザクション要件が高く、実行計画を制御する必要があるタスクに特に適しており、トランザクションをきめ細かく制御する方が優れています。
非リレーショナル データベース: トランザクション制御は若干弱くなり、その価値は高いスケーラビリティと大量のデータ処理にあります。
2.4 非リレーショナルデータベースの背景
これは、Web2.0 の純粋な動的 Web サイト タイプの 3 つの大きな問題に対処するために使用できます。
(1) 高パフォーマンス - データベースに対する高い同時読み取りおよび書き込み要件。
(2) Hugestorage - 効率的なストレージと大量のデータへのアクセスの必要性。
(3) HighScalability&&HighAvailability —— データベースの高スケーラビリティと高可用性の要件。
リレーショナル データベースと非リレーショナル データベースにはそれぞれ独自の特性と適用シナリオがあり、この 2 つを密接に組み合わせることで、Web2.0 データベースの開発に新しいアイデアがもたらされます。リレーショナル データベースは関係とデータの一貫性の保証に重点を置き、非リレーショナル データベースはストレージと高効率に重点を置きます。たとえば、読み取りと書き込みが分離されている MySQI データベース環境では、頻繁にアクセスされるデータ (つまり、高熱のデータ) を非リレーショナル データベースに保存して、アクセス速度を向上させることができます。
2.5 NOSQL と SQL のデータ レコードの比較
リレーショナルデータベース:
インスタンス --> データベース --> テーブル (表) --> レコード行 (行)、データフィールド (列)
非リレーショナル データベース:
インスタンス --> データベース --> コレクション (コレクション) --> キーと値のペア (キーと値)
非リレーショナル データベースは、データベースとコレクション (テーブル) を手動で構築する必要はありません。
3 redis に関する知識
3.1 redis の概要
Redis は、C 言語で書かれたオープンソースのメモリベースのキー/値データベースであり、複数の言語で API を提供します。そのデータ構造は非常に豊富で、主にデータベース、キャッシュ、分散ロック、メッセージ キューなどに使用されます。
Redis サーバー プログラムはシングル プロセス モデルです。つまり、1 台のサーバー上で複数の Redis プロセスを同時に起動できます。Redis の実際の処理速度は、メイン プロセスの実行効率に完全に依存します。
サーバー上で Redis プロセスが 1 つだけ実行されている場合、複数のクライアントが同時にアクセスすると、サーバーの処理能力はある程度低下しますが、同じサーバー上で複数の Redis プロセスを開いている場合、Redis は同時処理を向上させます
。同時に、サーバーの CPU に多大な負荷がかかります。
3.2 Redis の 5 つの主要なデータ型
基本的なデータ型には、文字列 (文字列)、リスト (リスト、二重リンク リスト)、ハッシュ (ハッシュ、キーと値のペアのコレクション)、セット (セット、反復されない)、およびソート セットが含まれます。 Zset (順序セット) とも呼ばれます。
3.3 redisのメリット・デメリット
(1) データの読み書き速度が非常に速く、データの読み込み速度は最大110,000回/秒、データの書き込み速度は最大81,000回/秒に達します。
(2) サポートされるデータ構造: キーと値。豊富なデータ型をサポート: 文字列、リスト、ハッシュ、セット、ソートされたセット、およびその他のデータ型操作。
(3) データの永続化をサポート: メモリ内のデータをディスクに保存し、再起動時に再度ロードして使用できます。
(4) アトミック性: すべての Redis 操作はアトミックです。(トランザクションをサポートし、すべての操作はトランザクションとして扱われます)
(5) データ バックアップのサポート: つまり、マスター/スレーブ モードでのデータ バックアップ。(マスター/スレーブ レプリケーションをサポート)
Redis の欠点
キャッシュとデータベースの二重書き込みの整合性の問題
キャッシュなだれの問題
キャッシュの破壊の問題
キャッシュの同時競合の問題
3.4 Redis の適用可能なシナリオ
Redis は、メモリベースのデータベースとして、高性能のキャッシュです。最近の最もホットなコメント、購読の公開など。
Redis は、高いリアルタイム データ要件、有効期限と削除特性のあるデータ ストレージ、永続性の必要がない、または弱い整合性のみ、およびシンプルなロジックを備えたシナリオに適しています。
//どのデータがキャッシュに配置するのに適していますか?
●即時性。たとえば、最新の物流ステータス情報をクエリします。
● データの一貫性要件はそれほど高くありません。例えば、変更後の店舗情報はデータベース上で変更され、5分後にはキャッシュが最新になりますが、機能の利用には影響ありません。
●アクセス数が多く、更新頻度が高くない 例えば、Webサイトのトップページに掲載されている広告情報は、アクセス数は多いものの、頻繁に変更されるわけではありません。
3.5 Redis がシングル スレッドを使用する理由
まず、Redis シングル スレッドとは、ネットワーク IO とキーと値のペアの読み取りと書き込みは 1 つのスレッドで完了しますが、Redis の永続化とクラスター データは追加のスレッドで実行されることを意味することを明確にする必要があります。Redis がシングル スレッドを使用することを理解する前に、まずマルチ スレッドのオーバーヘッドを理解する必要があります。
通常、マルチスレッドを使用すると、システムのスループットやシステムのスケーラビリティが向上しますが、マルチスレッドは通常、特定の共有リソースに同時にアクセスします。共有リソースへのアクセスの正確性を確保するには、次のことを保証する追加のメカニズムが必要です。このメカニズムは、まず、ある程度のオーバーヘッドが発生します。実際、複数スレッドによる同時アクセスの制御は常に難しい問題であり、細かい設計をしないと、例えば粗粒度のミューテックスを使用しただけでは満足のいく結果が得られません。スレッドが追加されても、ほとんどのスレッドは共有リソースにアクセスするためのミューテックスの取得を待機しており、並列処理はシリアル化され、スレッドの増加に応じてシステムのスループット率は向上しません。
また：
マルチスレッドが Redis6.0 で導入されたことは注目に値します。Redis6.0以前はネットワークIO処理から実際の読み書きコマンド処理までシングルスレッドで完結していましたが、ネットワークハードウェアの性能向上に伴い、ネットワークIOの処理にRedisの性能ボトルネックが現れる可能性があります。 、単一のメインスレッドがネットワークリクエストを処理する速度は、基盤となるネットワークハードウェアの速度に追いつくことができません。この問題を解決するために、Redis は複数の IO スレッドを使用してネットワーク リクエストの処理の並列性を向上させますが、複数の IO スレッドはネットワーク リクエストの処理にのみ使用されます。読み取りおよび書き込みコマンドについては、Redis は引き続きシングル スレッド処理を使用します。
3.6 Redis が高速に動作する理由
Redis はメモリに基づいており、ほとんどのリクエストはメモリ操作であるため、非常に高速です。
Redis には効率的な基礎となるデータ構造があり、メモリを最適化するために、基本的に型ごとに 2 つの基礎となる実装があります。
主な実行プロセスはシングルスレッドであるため、不要なコンテキストの切り替えやリソースの競合が回避され、マルチスレッドによる CPU の切り替えやロックの問題も発生しません。
IO 多重化メカニズム: ネットワーク IO 操作で多数のクライアント要求を同時に処理して、高いスループットを実現できます。
IO 多重化メカニズムは、複数の IO ストリームを処理するスレッドを指し、多くの場合、select/epoll メカニズムと呼ばれます。シングルスレッドで実行されている Redis の場合、このメカニズムにより、複数のリスニング ソケットと接続されたソケットがカーネル内に同時に存在することができます。カーネルは、これらのソケット上の接続リクエストまたはデータリクエストを常にリッスンします。リクエストが到着すると、処理のために Redis スレッドに渡されます。これにより、1 つの Redis スレッドが複数の IO ストリームを処理する効果が実現され、同時実行性が向上します。
3.7 Redis と memcached の比較
4. Redis のインストールと設定
4.1 Redis ソース コードのコンパイルとインストール
#Close firewall
systemctl stop firewalld
setenforce 0
#インストール環境に依存するパッケージ
yum install -y gcc gcc-c++ make # ソフトウェア パッケージをアップロードして
解凍 cd /opt/ tar zxvf redis- 5.0 .7.tar.gz -C /opt/ cd /opt/redis-5.0.7/ #2 コアのコンパイルとインストールを開き、インストール パスを /usr/local/redis として指定します make -j2 && make PREFIX=/ usr/local/ redis install #Makefile は Redis ソース パッケージで直接提供されるため、パッケージを解凍した後、./configure を実行して構成する必要はなく、make および make install コマンドを直接実行してインストールできます。それ。 # ソフトウェア パッケージによって提供される install_server.sh スクリプト ファイルを実行し、Redis サービスに必要な関連構成ファイルをセットアップします cd /opt/redis-5.0.7/utils ./install_server.sh ...... # 常に 入力してください
Redis 実行可能パスを選択してください [] /usr/local/redis/bin/redis-server
#ここでのデフォルトは /usr/local/bin/redis-server ですが、手動で /usr/local/redis/ に変更する必要がありますbin/redis-server、一度に正しく入力するように注意してください ------------------------
点線はコメントです -------- ------ -------------------------------------- 選択した構成: ポート: 6379 #デフォルトのリスニングポートは 6379 です 設定ファイル: /etc/redis/6379.conf #設定ファイルのパス ログファイル: /var/log/redis_6379.log #ログファイルのパス データディレクトリ : /var/lib/redis/ 6379 #データ ファイル パス 実行可能ファイル: /usr /local/redis/bin/redis-server #実行可能ファイル パス Cli 実行可能ファイル: /usr/local/bin/redis-cli #クライアント コマンド ツール
-------------------------------------------------- ---------------------------------
#
install_server.sh スクリプトの実行が終了すると、Redis サービスはすでに開始されています。デフォルトでは、待機ポートは 6379 です
netstat -natp | grep redis
#
システム識別用のパス環境変数のディレクトリに redis の実行可能プログラム ファイルを置きます ln -s
/usr/local/redis/bin/* /usr/local /bin
/
4.2 Redis 起動設定
#Redis
サービス制御
/etc/init.d/redis_6379 stop #stop
/etc/init.d/redis_6379 start #start
/etc/init.d/redis_6379 restart #restart
/etc/init.d/ redis_6379 status #ステータスの表示 #
設定ファイル、パラメータの編集 vim /etc/redis/6379.conf ...... 70 binding 127.0.0.1 192.168.73.105 #モニターの IP アドレスも指定されたリモート ログイン モード 93 ポート 6379 #ポート 137 をリッスンします daemonize yes #デーモン プロセスで開始します。つまり、バックグラウンドで開始します。 159 pidfile /var/run/redis_6379.pid #Redis プロセス番号の保存場所 172 logfile /var/log/redis_6379.log #log 保存場所 187 データベース 16 # 監視ライブラリの数 (番号 0 ～ 15 )
/etc/init.d/redis_6379 restart #redis サービスを再起動します
Redis におけるバインドの正しい理解
bind: Redis が他のコンピューターからの IP アドレスを許可するのではなく、マシンの IP アドレス (正確には、マシンのネットワーク カードに対応する IP アドレス。各ネットワーク カードには IP アドレスがあります) をバインドします。
bind が指定されている場合は、指定されたネットワーク カードからの Redis リクエストのみが許可されることを意味します。指定しない場合、任意のネットワーク カードからの Redis リクエストが受け入れられることを意味します。
ローカル アクセス保護モードが有効になっている場合、Redis はバインド IP が設定されておらず、パスワードも設定されていない場合にのみローカル応答を受け入れることができます。
バインド 127.0.0.1 の説明: (このマシンだけが接続でき、他のマシンは接続できない理由)
ifconfig からわかります: lo ネットワーク カード (IP アドレス 127.0.0.1 に対応): これはループバック アドレス (ローカル ループバック) です。つまり、ローカルのみがこのループバック アドレスにアクセスでき、他のコンピュータは自分のループバックにのみアクセスできます。住所。
次に、このネットワーク カードのコンピュータにはこのコンピュータしか存在しないため、このコンピュータだけがアクセスできますが、他のコンピュータはアクセスできません。
バインド 0.0.0.0 は、サーバー上のすべての物理ネットワーク カード アドレスを表します。
5.Redisコマンドツール
5.1 redis-cli: Redis コマンド ライン ツール
redis-cli -h host -p port [-a パスワード]
-h
: リモート ホスト マシンを指定します
-p: Redis サービスのポート番号を指定します
-a: パスワードを指定します。データベースパスワードが設定されていません -a オプションは省略できます
#-a オプション オプションを追加しない場合、このマシン上の Redis データベースへの接続に 127.0.0.1:6379 が使用されることを意味します
#ログイン
ローカル
redis-cli
#リモートログイン
redis-cli -h 192.168.72.60 -p 6379 [-パスワード]
5.2 redis-benchmark テスト ツール
redis-benchmark は、Redis サービスのパフォーマンスを効果的にテストできる、付属の公式 Redis パフォーマンス テスト ツールです。
基本的なテスト構文: redis-benchmark [オプション] [オプション値]
-h
: サーバーのホスト名を指定します。
-p: サーバーのポートを指定します。
-s: サーバーソケットを指定します。
-c: 同時接続数を指定します。
-n: リクエストの数を指定します。
-d: SET/GET値のデータサイズをバイト単位で指定します。
-k: l=キープアライブ 0=再接続
-r: SET/GET/INCR はランダムキーを使用、SADD はランダム値を使用
-P: パイプ <numreg> リクエスト
-q: Redis を強制終了、クエリ/秒値のみを表示
- -csv : CSV 形式で出力
-l: ループを生成し、テストを永久に実行します
-t: テスト コマンドのカンマ区切りリストのみを実行します
-I: アイドル モード、N 個のアイドル接続のみを開いて待機します
(1) 同時接続および100000リクエスト処理性能テスト
redis-benchmark -h 192.168.73.105 -p 6379 -c 100 -n 100000
(2) データパケットアクセスの性能テスト
redis-benchmark -h 192.168.73.105 -p 6379 -q -d 100
(3) Key-Valueペア作成速度テスト
redis-benchmark -t set, lpush -n 100000 -q
6. Redisの簡単な操作
6.1 Redis キーと値のペアへのアクセス
set: store data、コマンド形式は set key value
get: get data、コマンド形式は get key
6.2
Redisキー値リストのキー値を取得する設定：
192.168.73.105:6379> v1 1 を設定
OK
192.168.73.105:6379> v2 2 を設定
OK
192.168.73.105:6379> v3 4 を設定
OK
192.168.73.105:6379> k1 5 を設定
OK
192.168.73.10 5:6379> k2 6 を設定
OK
192.168.73.105:6379> k3 を設定 7
OK
192.168.73.105:6379> k4 を設定 8
OK
(1) リスト
キーをすべて取得 *
(2) 特定の文字
キー v*
キー k*で始まる任意の長さのキーを取得します
(3) 特定の文字で始まるキーを取得し、
指定された長さのキーのテスト データを追加します。
192.168.73.105:6379> v123 を設定 123
OK
192.168.73.105:6379> v11 を設定 11
OK
192.168.73.105:6379> v1124 1124 を設定
6.3 キーの有無の判定 存在
Key
# 戻り値は存在しないことを意味する 0、存在することを意味する 1 となります。
6.4 削除キー
del キー
6.5 キーストレージのデータタイプの表示
6.6 rename 名前の
変更 rename コマンドを使用して名前を変更すると、ターゲット キーが存在するかどうかに関係なく名前が変更され、ソース キーの値がターゲット キーの値を上書きします。
実際の使用においては、重要なデータの上書きを避けるため、rename コマンドを実行するかどうかを決定する前に、exists コマンドを使用して対象のキーが存在するかどうかを確認することをお勧めします。
コマンド形式: ソースキーの名前を変更ターゲットキー
6.7 renamenx rename
- ターゲットキー名がすでに存在するかどうかを確認します
renamenx コマンドの機能は、既存のキーの名前を変更し、新しい名前が存在するかどうかを確認することです。対象のキーが存在する場合、名前の変更は実行されません。（カバーされていません）
ソースキーのターゲットキーの名前を変更する
6.8 dbsize キー番号の表示
dbsize
6.9 パスワードの設定と解除
パスワードの設定と表示
#redis config のログインパスワードの設定
set requirepass passwd #redis config
のパスワードの表示get requirepass
パスワードのクリア
#パスワードのクリア
設定セット requirepass ''
7. Redis のマルチデータベース操作
Redis は複数のデータベースをサポートしており、デフォルトでは 16 個のデータベースが含まれており、データベース名には 0 ～ 15 の番号が連続して付けられます。
redis-cli を使用して Redis データベースに接続すると、シリアル番号 0 のデータベースがデフォルトで使用されます。
複数のデータベースは互いに独立しており、相互に干渉しません。
7.1 複数のデータベースを切り替えるためのコマンド形式の選択
: シリアル番号の選択
#
redis-cli を使用して Redis データベースに接続した後は、シリアル番号 0 のデータベースがデフォルトで使用されます。
127.0.0.1:6379>select 10 #シリアル番号 10 のデータベースに切り替えます
127.0.0.1:6379[10]>select
15 #シリアル番号 15 のデータベースに切り替えます
127.0.0.1:6379[15]>select
0 #シリアル番号 0 のデータベースに切り替え
127.0.0.1:6379
[0]>
7.2 複数のデータベース間でデータを移動する
キーと値のシーケンス番号 (ライブラリのシリアル番号) を移動する
7.3 データベース内のデータをクリアします
。 FLUSHDB: 現在のデータベース データをクリアします。
FLUSHALL: すべてのデータベース データをクリアします。
8. Redis の一般的なエラーと解決策
8.1 Redis の一般的な運用および保守の障害
キー* を使用してライブラリをブロックします。- このコマンドの名前を変更するには、エイリアスを使用することをお勧めします。
メモリ使用量を超えると、一部のデータが削除されます。——これには削除戦略があります。自分に合ったものを選択してください。
永続性が有効になっていないのにインスタンスが再起動されると、すべてのデータが失われます。- キャッシュされていない情報は永続性をオンにする必要があることに注意してください。
RDB の永続化には Vm.overcommit_memory=1 が必要です。そうでない場合、永続化は失敗します。
永続性がない場合、マスター/スレーブ、マスターの再起動が速すぎ、スレーブはマスターがダウンしていると考えず、スレーブは自身のデータをクリアします。マスター ノードを人為的に再起動する前に、まず同期をオフにします。スレーブノードの。
8.2 Redis のトラブルシューティング
Redis モニタリングを組み合わせて、QPS、キャッシュ ヒット率、メモリ使用量などの情報を表示します。
マシンレベルのリソースに異常がないか確認してください。
障害が発生した場合は、時間内にコンピューターを立ち上げ、redis-cli モニターを使用して操作ログを出力し、分析します (その後、この項目の分析は失敗します)。
研究開発と連絡を取り、閉塞している大鍵がないか確認する（大鍵は日常点検でも入手可能） グループ内の同僚と連絡を取り、誤操作がないか確認する。
交通が正常であるかどうか、運転保守の同僚や研究開発者にブラッシングがないかどうかを確認してください。