Redis は現在のテクノロジー コミュニティで非常に人気があります。 Redis は、Antirez の小規模な個人プロジェクトから、インメモリ データ ストレージの業界標準になるまで長い道のりを歩んできました。結果として得られる一連のベスト プラクティスにより、ほとんどの人が Redis を正しく使用できるようになります。
1. KEYS の使用をやめる *
わかりました、このコマンドに挑戦することからこの記事を始めるのは良い方法ではないかもしれませんが、確かに可能です。最も重要な点。 Redis インスタンスの統計に注目する場合、多くの場合、キー情報が明確に表示されるように、すぐに「KEYS *」コマンドを入力します。
プログラミングの観点から、次のような疑似コードを作成する傾向があります:
for key in'keys *': doAllTheThings()
しかし、1,300 万個のキーがあると、実行速度が遅くなります。 KEYS コマンドの時間計算量は O(n) (n は返されるキーの数) であるため、このコマンドの計算量はデータベースのサイズによって異なります。また、この操作の実行中は、インスタンス内で他のコマンドを実行することはできません。
代替コマンドとして、よりわかりやすい方法で実行できる SCAN を見てみましょう... SCAN は増分反復でデータベースをスキャンします。この操作はカーソルのイテレータに基づいて実行されるため、必要に応じていつでも停止または続行できます。
2. Redis の速度を低下させる原因を特定する
Redis には詳細なログがないため、Redis インスタンス内で何が行われているかを知ることは非常に困難です。幸いなことに、Redis は次のようなコマンド統計ツールを提供します。
127.0.0.1:6379> INFO commandstats # Commandstats cmdstat_get:calls=78,usec=608,usec_per_call=7.79 cmdstat_setex:calls=5,usec=71,usec_per_call=14.20 cmdstat_keys:calls=2,usec=42,usec_per_call=21.00 cmdstat_info:calls=10,usec=1931,usec_per_call=193.10
このツールを使用すると、コマンドが実行された回数や実行にかかったミリ秒数など、すべてのコマンド統計のスナップショットを表示できます。コマンドの実行 (各コマンドの合計時間と平均時間)
CONFIG RESETSTAT コマンドを実行してリセットするだけで、まったく新しい統計結果を取得できます。
3. 一般化するのではなく、Redis ベンチマークの結果を参考として使用する Redis の父である Salvatore 氏は、「GET/SET コマンドを実行して Redis をテストするのは、雨の日にフェラーリをテストするようなものです。ワイパーがミラーを掃除する効果。」多くの人が私のところに来て、Redis-Benchmark 統計が最適な結果よりも低い理由を知りたいと考えています。ただし、さまざまな実際の状況を考慮する必要があります。
例:
4. ハッシュは最良の選択です。
ハッシュはエレガントな方法で導入してください。ハッシュは、これまでにない体験をもたらします。これまでに、次のようなキー構造を多く見たことがあります。
foo:first_name foo:last_name foo:address
上の例では、foo はユーザーのユーザー名で、その中の各項目は個別のキーです。これにより、エラーや不要なキーが発生する余地が増加します。代わりにハッシュを使用すると、必要なキーが 1 つだけであることに驚くでしょう:
127.0.0.1:6379> HSET foo first_name 'Joe' (integer) 1 127.0.0.1:6379> HSET foo last_name 'Engel' (integer) 1 127.0.0.1:6379> HSET foo address '1 Fanatical Pl' (integer) 1 127.0.0.1:6379> HGETALL foo 1) 'first_name' 2) 'Joe' 3) 'last_name' 4) 'Engel' 5) 'address' 6) '1 Fanatical Pl' 127.0.0.1:6379> HGET foo first_name 'Joe'
5. キー値の生存時間を設定します
可能な限り、キー タイムアウト を利用してください。良い例は、一時的な認証キーのようなものを保存することです。 OAUTH を例として認証キーを検索すると、通常はタイムアウトが発生します。
このように、キーを設定するときに同じタイムアウト期間に設定すると、Redis が自動的にキーをクリアします。すべてのキーをたどるのに KEYS * を使用する必要がなくなりました。とても便利です。
6. 適切なリサイクル戦略を選択する
キーのクリアについて説明したので、リサイクル戦略について話しましょう。 Redis インスタンスのスペースがいっぱいになると、いくつかのキーを再利用しようとします。使用状況に応じて、キーにタイムアウトを設定している場合は、volatile-lru 戦略を使用することを強くお勧めします。
ただし、キャッシュに似たものを実行していて、キーのタイムアウト メカニズムを設定していない場合は、allkeys-lru リサイクル メカニズムの使用を検討できます。
7. データが非常に重要な場合は、Try/Except を使用してください。
重要なデータを Redis インスタンスに確実に配置できるようにする必要がある場合は、それを Redis インスタンスに配置することを強くお勧めします。 Try/Except ブロック。ほとんどすべての Redis クライアントは「送信して忘れる」戦略を採用しているため、多くの場合、キーが実際に Redis データベースに配置されているかどうかを考慮する必要があります。
Redis コマンドに try/expect を入れることの複雑さについては、この記事では扱いません。そうすることで、重要なデータが配置されるべき場所に確実に配置されることを理解する必要があるだけです。
8. インスタンスを使い果たさないようにします
可能な限り、複数の Redis インスタンスのワークロードを分散します。バージョン 3.0.0 以降、Redis はクラスターをサポートします。 Redis Cluster を使用すると、キー範囲に基づいてマスター/スレーブ モードを含むいくつかのキーを分離できます。クラスタリングの背後にある完全な「魔法」はここで見つけることができます。
しかし、チュートリアルを探しているのであれば、ここは完璧な場所です。クラスタリングが選択肢にない場合は、ネームスペースとキーを複数のインスタンスに分散することを検討してください。
9. コアは多いほど良いのでしょうか? ！
もちろんそれは間違いです。 Redis はシングルスレッドプロセスであり、永続性が有効になっている場合でも最大 2 コアしか消費しません。単一のホスト上で複数のインスタンスを実行する予定がない限り、できれば開発環境とテスト環境でのみ実行してください。 ——それ以外の場合、Redis インスタンスに 2 コアを超える必要はありません。
10. 高可用性
これまでのところ、Redis Sentinel は徹底的にテストされており、多くのユーザーが実稼働環境 (ObjectRocket を含む) に適用しています。アプリケーションが Redis に大きく依存している場合は、アプリケーションがオフラインにならないように高可用性ソリューションを考案する必要があります。
さらに関連する知識については、Java 基本チュートリアル 列
を参照してください。
以上がRedis の使用に関する 10 のヒントの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
