Linux の運用と保守のために知っておくべき Redis の経験

#Redis は、現在のテクノロジー コミュニティで非常に人気があります。 Redis は、Antirez の小規模な個人プロジェクトから、インメモリ データ ストレージの業界標準になるまで長い道のりを歩んできました。結果として得られる一連のベスト プラクティスにより、ほとんどの人が Redis を正しく使用できるようになります。

以下では、Redis を正しく使用するための 10 の経験を見ていきます。

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-Benchmark 结果作为参考，而不要一概而论

Redis 之父 Salvatore 就说过：“通过执行GET/SET命令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。很多时候人们跑到我这里，他们想知道为什么自己的Redis-Benchmark统计的结果低于最优结果 。但我们必须要把各种不同的真实情况考虑进来，例如：

• 可能受到哪些客户端运行环境的限制？
• 是同一个版本号吗？
• 测试环境中的表现与应用将要运行的环境是否一致？

Redis-Benchmark的测试结果提供了一个保证你的 Redis-Server 不会运行在非正常状态下的基准点，但是你永远不要把它作为一个真实的“压力测试”。压力测试需要反应出应用的运行方式，并且需要一个尽可能的和生产相似的环境。

4、Hashes 是你的最佳选择

以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种前所未有的体验。之前我曾看到过许多类似于下面这样的key结构：

foo:first_name

foo:last_name

foo:address

上面的例子中，foo 可能是一个用户的用户名，其中的每一项都是一个单独的 key。这就增加了 犯错的空间，和一些不必要的 key。使用 hash 代替吧，你会惊奇地发现竟然只需要一个 key ：

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、设置 key 值的存活时间

无论什么时候，只要有可能就利用key超时的优势。一个很好的例子就是储存一些诸如临时认证key之类的东西。当你去查找一个授权key时——以OAUTH为例——通常会得到一个超时时间。这样在设置key的时候，设成同样的超时时间，Redis就会自动为你清除！而不再需要使用KEYS *来遍历所有的key了，怎么样很方便吧？

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

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

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

10. 高可用性

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