どのくらいの QPS が高い同時実行性とみなされるのでしょうか?

高い同時実行性の 4 つの側面

同時実行によってユーザビリティが向上しないと言うのは、不正行為と言えます。この問題は 4 つの観点から議論できます。

まず第一に、ステートレス フロントエンド マシンはリクエスト トラフィックを運ぶのに十分ではないため、水平方向に拡張する必要があります。一般に、QPS は数千レベルです。その場合、リレーショナル データベースは読み取りまたは書き込みのピークに対応できなくなり、データベースの水平拡張または NoSQL の導入が必要になります (通常、数千から 1 万レベル)。その後、nosql を単一のマシンでホストすることはできなくなり、nosql を水平方向に (通常は 100,000 から 100 万 QPS) 拡張する必要があります。最後に、NoSQL を単純に水平方向に拡張することは困難です。たとえば、Weibo はマルチレベル キャッシュ アーキテクチャを導入しています。このアーキテクチャは通常、NoSQL への数百万から数千万の QPS アクセスを処理できます。もちろん、ユーザー向けインターフェイスのリクエストは通常​​、このレベルに達することはありませんが、QPS の増加は主に読み取り増幅による圧力によるものであり、これも高同時実行アーキテクチャによって考慮されます。

ビデオ コースの推奨事項 →: 「数千万のデータに対する同時実行ソリューション (理論と実践)」

PV と QPS

たとえば、1 日あたり 1 億 PV を超える Weibo のシステムは、通常 1500QPS しかなく、ピーク時でも 5000QPS です。

たとえば、誰かが次のように言いました:

2C4G マシンは通常、マシンあたり 1000QPS です。

8C8Gマシンは単独で7000QPSに耐えることができます。

最後に書かれています

特定の QPS はビジネスと密接に関連しています。読み取り専用インターフェイスはキャッシュを読み取り、キャッシュに圧力をかけます。マシンあたり 3000問題ありません。1000 件の書き込みリクエストも正常です。これはさらに複雑で、数百 QPS にすぎない場合もあります。

つまり、QPS はビジネス シナリオと設計に密接に関連しています。たとえば、QPS は、ブラウザーのローカル キャッシュ、キャッシュを使用したホットスポット データのクエリ、およびトランザクション MQ 非同期処理の作成を通じて改善できます。

詳細な FAQ については、PHP 中国語 Web サイトをご覧ください。

以上がどのくらいの QPS が高い同時実行性とみなされるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。