序文
皆さんも、プログラムのパフォーマンスを向上させるために分散キャッシュを作成するなど、プロジェクトで redis を使用したことがあると思います。
Redis をキャッシュとして使用する場合、いくつかの問題を考慮する必要があります。キャッシュのブレークダウン、キャッシュのペネトレーション、キャッシュ アバランシェに加えて、他にどのような問題を考慮する必要がありますか?
高い同時書き込み
ライブ注文などの同時実行性の高い状況では、ライブ注文は Flashkill とは異なります。Flashkill の在庫には限りがありますが、ライブストリーミング注文はいつでも行うことができ、注文の数が多いほど良い結果が得られます。たとえば、商品の在庫が 10 万点ありますが、この商品が特に人気がある場合は、一瞬でトラフィックが集中してしまう可能性があります。インベントリは事前に Redis に配置されており、MySql にはアクセスしませんが、この時点ですべてのリクエストが Redis に送信されます。
表面的には問題がないように見えますが、クラスターがあってもアクセスされるキーが 1 つだけであっても、最終的には同じ Redis サーバーに落ちてしまうのではないかと考えたことはありますか。現時点では、キーが配置されている redid がすべてのリクエストを伝送し、クラスター内の他のマシンはまったくアクセスできなくなります。この時点で redis がそれを処理できると確信していますか? ? ? 現時点で大量の読み取りリクエストがある場合、Redis はそれを処理できると思いますか?
この状況では、データ断片化ソリューションを使用できます。たとえば、100,000 株がある場合、この時点で 10 台の Redis サーバーをセットアップし、各 Redis サーバーに 10,000 株を配置できます。ユーザー ID がモジュール化され、ユーザー トラフィックが 10 台の Redis サーバーに分散されます。
したがって、ホットスポット データの場合、特にこの種の同時書き込みが多い場合には、トラフィックを共有し、複数の Redis がトラフィックの一部を共有できるようにする必要があります。
高い同時読み取り
redis をキャッシュとして使用することは、私たちのプロジェクトで最もよく使われていると言えます。アクセス量がそれほど多くないためか、私たちの redis サービスは非常に多くのユーザーのリクエストを十分に処理できます。しかし、それについては考えてみましょう。 1つのネットワークIOは1万回なら10万回？これは 100,000 回のネットワーク IO に相当し、作業ではこれを考慮する必要があります。このオーバーヘッドは実際には非常に大きいため、アクセス量が多すぎると、Redis に問題が発生する可能性があります。
この問題を解決するには、ローカル キャッシュ + Redis 分散キャッシュを使用します。一部のホット リード データや小規模な更新データについては、Guava などのツールなどのローカル キャッシュにデータを保存できます。もちろん、ローカル キャッシュの有効期限は、設定は 5 秒程度と短く設定されていますが、この時点では、ほとんどのリクエストは Redis にアクセスすることなくローカル キャッシュに配置できます。
この時点でローカル キャッシュがない場合は、redis に再度アクセスし、redis 内のデータをローカル キャッシュに置きます。
多値キャッシュを追加すると、多値キャッシュ内のデータの整合性をどう確保するかなど、それに応じた問題が発生します。
要約する
完璧なソリューションはありません。唯一、あなたにとって最適なソリューションがあります。特定の技術的ソリューションを採用することに決めた場合、必然的に、考慮する必要がある他の問題がいくつか発生します。同じことが Redis にも当てはまりますが、キャッシュに使用されています。プログラムのパフォーマンスを向上させることができますが、キャッシュとして redis を使用する場合は、いくつかの状況も考慮する必要があります。トラフィックの少ないユーザーの場合、redis を直接使用するだけで十分ですが、同時実行性の高いシナリオでは、当社のソリューションは当社のビジネスをサポートできますか?