Redisを拡張する方法

チームのクラスメートは、Redis をプロジェクトのキャッシュとして使用し、ホットスポット データを Redis に保存しました。パフォーマンスを向上させるため、Redis を記述するときにパイプライン方式が使用されます。通常に使用すると、Redis のパフォーマンスとリソース使用量はプロジェクトの要件を満たしますが、アクセス数が増加すると、Redis の QPS は要件を満たします。 , しかし、CPU 使用率が高いです。90% に達していますが、通常は 30% しかありません。ご存知のとおり、Redis は単一プロセスであり、1 つの CPU コアしか占有できません。フルになると 100% になります。使用できません。 CPU が 100% に達すると、必然的にパフォーマンスのボトルネックが発生します。どうやって対処すればいいのでしょうか？

# 推奨: 「

Redis ビデオ チュートリアル 」

オプション 1:

最初に思いつくのは、Redis サーバーの数を増やし、クライアントに保存されているキーに対してハッシュ操作を実行し、それらを別の Redis サーバーに保存することです。読み取り時には、同じハッシュ操作が実行されて検索されます。問題は解決しますが、欠点もあります:

最初に、クライアントはコードを変更する必要があります;

2 番目に、クライアントはすべての Redis サーバーのアドレスを記憶する必要があります;

このソリューションは使用できますが、コードを変更せずに拡張できますか?

オプション 2:

クラスターを構築します。Redis サーバーで使用されるバージョンは 3.0 より低いため、クラスターはサポートされていません。プロキシのみを使用できます。 , そこで私は有名な Redis プロキシ twemproxy を思い出しました。

twemproxy はパフォーマンスも非常に良く、プロキシでありながらアクセスパフォーマンスへの影響が非常に小さく、Redis 作者も推奨しています。

twemproxy は使いやすいです。初心者でも 1 時間以内に使い方を学ぶことができます。重要なのは、クライアント コードを変更する必要がないことです。ほぼすべての Redis コマンドとパイプライン操作をサポートしています。クライアント コードを変更するだけで、設定ファイルに設定されている Redis IP とポートが、元の Redis IP とポートから twemproxy サービスの IP とポートに変更されます。

クライアントはハッシュの問題を考慮する必要はありません。twemproxy がこれらを行います。クライアントは Redis を操作するのと同じです。

「keys *」などの一部のコマンドはサポートされていないため、上記で「ほぼ」という言葉が使用されています

私たちは、twemproxy とそれに続く 4 つの Redis マシンをすぐにデプロイしました。テストでは、CPU が次の 4 つの Redis ユニットの使用率は低下しましたが、twemproxy も単一プロセスであるという新たな問題が発生しました。パフォーマンスのボトルネックが再び twemproxy に発生します。

オプション 3:

Redis へのアクセスは、プロデューサーとコンシューマーと同様に、書き込みと読み取りに分割されます。慎重に分析した結果、書き込みと読み取りが少ないことがわかりました。読み取りが比較的少なくなります。さらに、これにより読み取りと書き込み、プライマリへの書き込みとバックアップからの読み取りを分離できます。読み取りと書き込みが 2 つのサービスであるという状況が発生します。読み取りと書き込みを分離するには、構成を変更するだけです。これは非常に簡単に実行できるため、メイン Redis への圧力が分散されます。

Redis へのアクセス圧力は改善されましたが、長期的な解決策ではなく、たとえばイベントが開催されてデータ量が増加した場合、パフォーマンスのリスクは依然として残ります。

最後に採用された方法は、次の図に示すように、包括的なプラン 2 と 3 です。

この方法では、既存のサービスへの変更が最小限で済み、次のことが可能です。 Redis のプレッシャーを軽減するという問題が効果的です。

プロデューサー側とコンシューマー側の twemproxy で使用されるハッシュ アルゴリズムは一貫していなければなりません。そうでないとキーが見つかりません。

案1も追加するとさらに複雑になるため当面は使用しません。

以上がRedisを拡張する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。