Redis には豊富な機能がありますが、初めて見るとまぶしく感じるかもしれませんが、これらの機能は何に使われているのでしょうか?どのような問題が解決されましたか?対応する機能はどのような状況で使用されますか?ステップバイステップの説明から始めましょう。
#ローカル メモリに基づくキャッシュ
API 呼び出しに 2 秒かかる問題を解決するために、調査した結果、主な理由は、最新のニュースを取得するのに SQL を使用するのに 2 秒近くかかるため、SQL クエリの結果を現在の API サーバーのメモリに直接キャッシュするという単純で大雑把な解決策を考えました (キャッシュの設定)。有効時間は 1 分です)。 1 分以内の後続のリクエストはキャッシュを直接読み取るため、SQL の実行に 2 秒もかかりません。この API が 1 秒あたり 100 のリクエストを受信する場合、1 分あたり 6,000 のリクエストがあります。つまり、最初の 2 秒で混雑したリクエストだけが 2 秒かかり、その後の 58 秒のすべてのリクエストはすぐに応答できます。さらに 2 秒待ちます。サーバー側の Redis
API サーバーのメモリがキャッシュでいっぱいになったとき、別の解決策を考える必要があることがわかりました。最も簡単なアイデアは、これらすべてのキャッシュを専用サーバーに置き、そのメモリを大きく構成することです。次に、redis に焦点を当てました。 。 。 Redisの設定とデプロイ方法については、ここでは説明しませんが、Redis公式に詳しく紹介されています。そこで、Redis サーバーとして別のサーバーを使用することで、API サーバーのメモリ圧迫が解決されました。永続性
単一の Redis サーバーは、月に数日間常に機嫌が悪い状態になります。機嫌が悪い場合はストライキが発生し、その結果、すべてのキャッシュですべてが失われます (redis データはメモリに保存されます)。 Redis サーバーはオンラインに戻すことができますが、メモリ データの損失によりキャッシュ雪崩が発生し、API サーバーとデータベースへの負荷が急激に増加しました。そこでこのとき、キャッシュ雪崩の影響を軽減できるRedisの永続化機能が役に立ちます。 redis の永続性とは、redis がメモリ内のデータをハードディスクに書き込み、redis の再起動時にデータをロードすることを意味し、キャッシュ損失の影響を最小限に抑えます。Sentinel とレプリケーション
Redis サーバーの警告なしの攻撃は厄介なものです。じゃあ何をすればいいの?答えは、1 台のマシンをバックアップしてハングアップします。では、特定の Redis サーバーがダウンしていることをどのようにして確認し、切り替える方法、そしてバックアップ マシンが元のサーバーの完全なバックアップであることを確認するにはどうすればよいでしょうか?現時点では、Sentinel と Replication が表示される必要があります。 Sentinel は複数の Redis サーバーを管理でき、監視、リマインダー、自動フェイルオーバー機能を提供します。レプリケーションは、Redis サーバーに複数のバックアップ サーバーを装備できるようにする役割を果たします。 Redis は、これら 2 つの機能を使用して Redis の高可用性を確保します。さらに、Sentinel 機能は、Redis のパブリッシュおよびサブスクリプション機能を使用します。クラスタ
単一サーバーのリソースには常に上限があり、マスター/スレーブ レプリケーションにより読み取り/書き込みの CPU リソースと IO リソースを分離できます。 CPU と IO プレッシャーの一部をスレーブ サーバーに転送します。しかし、メモリ リソースはどうすればよいでしょうか? マスター スレーブ モードでは同じデータのみがバックアップされ、メモリを水平方向に拡張することはできません。1 台のマシンのメモリは増やすことしかできませんが、常に上限があります。したがって、水平方向に拡張できるソリューションが必要です。最終的な目標は、各サーバーがその一部のみを担当し、これらすべてのサーバーが全体を形成するようにすることです。外部の消費者にとって、この分散サーバーのグループは集中サーバーのようなものです以上がredisにはどのような機能があるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。