Redis を正しく使用するための 10 のヒント-PHPチュートリアル-php.cn

Redis は現在のテクノロジーコミュニティで非常に人気があります。 Antirez の小規模な個人プロジェクトから、インメモリデータストレージの業界標準になるまで、Redis は長い道のりを歩んできました。以下では、Redis を正しく使用するための 10 のヒントを説明します。

1. KEYS の使用をやめる *

さて、このコマンドに挑戦することからこの記事を始めるのは良い方法ではないかもしれませんが、確かにそれが最も重要なポイントかもしれません。 Redis インスタンスの統計に注目する場合、多くの場合、キー情報が明確に表示されるように、すぐに「KEYS *」コマンドを入力します。公平を期すために、プログラミングの観点から、私たちは次のような疑似コードを書く傾向があります:

for key in &#39;keys *&#39;: 
 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 統計が最適な結果よりも低い理由を知りたいと考えています。ただし、次のようなさまざまな現実の状況を考慮する必要があります: どのようなクライアントのオペレーティング環境の制限が

の対象となる可能性がありますか?
それらは同じバージョン番号ですか?
テスト環境のパフォーマンスは、アプリケーションが実行される環境と一致していますか?

Redis-Benchmark のテスト結果は、Redis-Server が異常な状態で実行されないことを確認するためのベンチマークポイントを提供しますが、それを本当の「ストレステスト」として受け取らないでください。ストレステストでは、アプリケーションの実行状況を反映する必要があり、本番環境と可能な限り似た環境が必要です。

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 インスタンスに確実に入れる必要がある場合は、それを Try/Except ブロックに入れることを強くお勧めします。ほとんどすべての Redis クライアントは「送信して忘れる」戦略を採用しているため、多くの場合、キーが実際に Redis データベースに配置されているかどうかを考慮する必要があります。 Redis コマンドに try/expect を組み込むことの複雑さは、この記事の内容ではありません。そうすることで、重要なデータが配置されるべき場所に確実に配置されることを理解する必要があります。

8. インスタンスを使い果たさないようにします

可能な限り、複数の Redis インスタンスのワークロードを分散します。バージョン 3.0.0 以降、Redis はクラスターをサポートします。 Redis Cluster を使用すると、キー範囲に基づいてマスター/スレーブモードを含むいくつかのキーを分離できます。クラスタリングの背後にある完全な「魔法」はここで見つけることができます。ただし、チュートリアルを探している場合は、ここが最適な場所です。クラスタリングが選択肢にない場合は、ネームスペースとキーを複数のインスタンスに分散することを検討してください。データの配布方法については、redis.io Web サイトにこの優れたレビューがあります。

9. コアは多いほど良いのでしょうか?

もちろんそれは間違いです。 Redis はシングルスレッドプロセスであり、永続性が有効になっている場合でも最大 2 コアしか消費しません。単一のホスト上で複数のインスタンスを実行する予定がない限り、できれば開発環境とテスト環境でのみ実行してください。 ——それ以外の場合、Redis インスタンスに 2 コアを超える必要はありません。

10. 高可用性

これまでのところ、Redis Sentinel は徹底的にテストされており、多くのユーザーがそれを運用環境 (ObjectRocket を含む) に適用しています。アプリケーションが Redis に大きく依存している場合は、アプリケーションがオフラインにならないように高可用性ソリューションを考案する必要があります。もちろん、これらのことを自分で管理したくない場合は、ObjectRocket が高可用性プラットフォームと 24 時間年中無休のテクニカルサポートを提供しますので、ご興味があれば検討してみてはいかがでしょうか。