なぜ Redis の単一プロセスは速いのでしょうか?

(*-*)浩
リリース: 2019-11-22 09:06:08
オリジナル
2753 人が閲覧しました

なぜ Redis の単一プロセスは速いのでしょうか?

Redis は、単一プロセス、単一スレッド モデルを使用し、C 言語で記述されたメモリベースの KV データベースを使用します。提供されている公式データでは、100,000 qps に達する可能性があります。このデータは、単一プロセスとマルチスレッドを使用する同じメモリベースの KV データベースである Memcached よりも劣りません。

#Redis が高速である主な理由は次のとおりです: (推奨学習: Redis ビデオ チュートリアル )

完全にメモリに基づいています

データ構造 シンプルで操作しやすいデータ

多チャネルI/O多重化モデルを採用

1点目と2点目については詳しくは説明しませんが、主に3 番目のポイントは、マルチチャネル I/O 再利用技術を使用して拡張することに焦点を当てています。

マルチチャネル I/O 多重化モデルは、select、poll、および epoll を使用して、複数のストリームの I/O イベントを同時に監視します。アイドル状態の場合、現在のスレッドはブロックされます。 1 つ以上のストリームに I/O イベントがある場合、それらはブロッキング状態からウェイクアップするため、プログラムはすべてのストリームをポーリングします (epoll は、実際にイベントを発行したストリームのみをポーリングします)。処理準備ができているストリームを順番にのみポーリングします。このアプローチでは、無駄な操作が多い。

ここで、「複数」は複数のネットワーク接続を指し、「再利用」は同じスレッドを再利用することを指します。マルチチャネル I/O 多重化テクノロジの使用により、単一のスレッドで複数の接続リクエストを効率的に処理でき (ネットワーク IO の時間消費を最小限に抑えます)、Redis はメモリ内のデータを非常に高速に処理します (ここではメモリ内操作は問題になりません) ).パフォーマンスのボトルネック)、主に上記 2 点が Redis の高スループットに貢献します。

Memcached とは異なり、Redis は Libevent を直接使用しませんが、select、epoll、evport、kqueue などの一般的なインターフェイスの非常に軽量な実装を完了します。

さまざまなシステム コールに適切なインターフェイスを選択してください。Linux のデフォルトは epoll です。 Libevent は比較的重くて汎用的なため、コード量が非常に多く、Redis では使用できない機能も多くありますが、「軽さ」を追求し、依存関係を排除するために、Redis はそれ自体をカプセル化することを選択しました。

単一プロセスと単一スレッドの利点

コードがより明確になり、処理ロジックがより単純になります

さまざまなロックの問題を考慮する必要がありませんロックはありません。ロックの解放操作はありません。デッドロックの可能性によるパフォーマンスの消費はありません。

CPU パフォーマンスを消費するマルチプロセスまたはマルチスレッドによる切り替えはありません。

シングルプロセスとシングルスレッドの欠点

マルチコア CPU のパフォーマンスを活用できませんが、単一のマシン上で複数の Redis インスタンスを開くことで改善できます;

以上がなぜ Redis の単一プロセスは速いのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート