Redis の単一データ、マルチソースの超高同時実行ソリューション

Redis は現在最も人気のある KV キャッシュ データベースで、シンプルで使いやすく、安全で安定しており、インターネット業界で非常に幅広い用途に使用されています。

この記事では主に、単一データと複数のソースへの超高同時アクセス下での Redis のソリューションとソリューションについて説明します。

まえがき

Redis は主に 2 つの問題を解決します:

毎日数千万のユーザーと数百万の人々がいるビジネス シナリオに遭遇したとき同時にオンラインで、フロントエンド アクセスがバックエンド データベースに直接読み込まれると、基礎となるデータベースに負荷がかかり、ビジネスが停止する可能性があります。あるいは、クエリ条件の数が増加し、組み合わせ条件が複雑になると、クエリ結果の応答時間が保証されなくなり、ユーザーエクスペリエンスの低下やユーザーの喪失につながります。高同時実行性、低遅延のビジネス シナリオを解決するために、Redis が登場しました。

2 つのシナリオを見てみましょう

これはオンライン家探しのビジネス シナリオです。クエリ条件が非常に多いため、バックエンドは複雑になる必要がありますクエリ SQL、このシナリオでは Redis を使用する必要がありますか?

答えは「ノー」です。オンライン住宅検索ビジネスは同時実行性が低いため、顧客はビジネスの応答時間をそれほど要求していません。ほとんどのリクエストは、動的 SQL を通じて一時的に直接クエリできます。もちろん、ユーザー エクスペリエンスを向上させるために、ホット クエリの結果の一部を Redis に事前キャッシュすることができます。

このシナリオをもう一度見てみましょう

#ビデオアプリケーション用のフィルムチェックシステムは、住宅検索システムとほぼ同じビジネスシナリオを持っていますが、このシナリオは、同時アクセスを増やし、応答時間を短縮し、数十万、さらには数百万の同時アクセス要件を満たすために、Redis をキャッシュとして使用するのに非常に適しています。 Redis を使用するかどうかを決定する基本的な要素は、同時実行性と待機時間の要件であることがわかります。

極端なインターネット シナリオにおける同時アクセス要件を Redis がどのように解決するかを見てみましょう。

超高同時アクセス時のキャッシュ ソリューション

これは典型的なメディア キャッシュ アーキテクチャ図です。パブリッシング システムはメディア ライブラリを随時更新します。分散キャッシュ サービスは各最新記事を Redis キャッシュに同期し、フロントエンド アプリケーションはルーティング層を通じて対応するデータ ソース アクセスを見つけます。各キャッシュ サービスのデータは同期されていません。ホットスポット イベントが発生すると、ルーティング層が到達不能な領域からホットスポット データが配置されているキャッシュ サーバーにアクセスをルーティングし、瞬間的なトラフィックの急増を引き起こし、極端な場合にはサーバーのダウンタイムやビジネスへの損害を引き起こす可能性があります。では、この不規則なトラフィックバーストシナリオを解決するにはどうすればよいでしょうか?

ここにいくつかのアイデアがあります:

ホット データ レプリケーションを実現するために、プレフィックスを使用してホットスポット キーを分割します。

ローカル キャッシュをルーティング レイヤー、マルチレベル キャッシュを通じてキャッシュ機能を向上させる

キャッシュ レイヤーはデータ コピーを提供し、同時アクセス機能を向上させます

最初のソリューションではホット データを効果的に消散できますが、ホット イベントは時間の経過とともにランダムに発生します。運用とメンテナンスのプレッシャーとコストは高くなりますが、これは単なる頭痛と痛みの解決策です。

2 番目の解決策では、ローカル キャッシュを追加することでキャッシュ機能を向上させることができますが、ローカル キャッシュの設定サイズ、更新頻度、ビジネスがダーティ リードを許容できるかどうかなどはすべて解決できない問題です。避けられた。

3 番目のソリューションでは、読み取り専用レプリカを追加してデータ レプリケーションを実現できますが、コストが高く、メイン データベースに高い負荷がかかります。

上記のアーキテクチャ図は最適化されたソリューションであり、メイン ライブラリを通じて読み取り専用スレーブ ライブラリの複数のブランチをプルし、さまざまなリクエスト ソースに対して独立したキャッシュを分割します。たとえば、モバイル アプリケーションは APP データ リソース グループに固定的にルーティングされ、WEB アクセスは WEB データ リソース グループなどにルーティングされ、各リソース グループは N 個の読み取り専用コピーを提供して、同一オリジンでの同時アクセス機能を向上させることができます。アクセス。このアーキテクチャにより、さまざまなアクセス ソースのリソース分離機能が向上し、マルチソース アクセス下でのサービスの安定性と可用性が向上します。

このソリューションの問題点も明らかです。

メイン ライブラリの読み取りおよび書き込みパフォーマンスが低いです。

読み取り専用のコピーが多数あり、コストが高いです。

読み取り専用リンクが渡されます。長くて、管理と保守が難しく、運用保守コストが高くなります。

お客様の最も誇張された例では、1 マスターを使用しています。同様のビジネス シナリオを満たす 40 の読み取り専用アーキテクチャ。

Alibaba Cloud Redis は、この超高同時アクセスの問題をどのように解決しますか?

Alibaba Cloud は、Redis のパフォーマンスが強化されたバージョンをリリースしました。ネットワーク IO の同時処理能力を向上させることにより、Redis 単一ノードの読み取りおよび書き込みパフォーマンスが大幅に向上しました。コミュニティ バージョンでは、パフォーマンスが 3 倍向上しました。単一ワーカー処理モードを維持しているため、Redis プロトコルと 100% 互換性があります。単一データに対する上記の 100 万 QPS のアクセス能力は容易に達成できます。この記事で紹介されているメディア シナリオでは、1 つのマスター インスタンスと 5 つの読み取り専用インスタンスのパフォーマンス強化バージョンをアクティブにすることで、単一データに対して 200 万 QPS を達成でき、トラフィックの急増や、トラフィックの急増や超高同時アクセスなどの業界の問題点を効果的に軽減できます。突然の熱い出来事。 1 マスターと 40 読み取りの自社構築コミュニティ バージョンと比較して、同じパフォーマンス基準を持つ Alibaba Cloud Redis パフォーマンス強化バージョンには 1 マスターと 5 読み取り専用アーキテクチャがあり、より安定しており、管理がより便利です。使いやすい。

以上がRedis の単一データ、マルチソースの超高同時実行ソリューションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。