セットアップとは？
ルーティンという言葉は蔑称ではなく、世の中のすべてのものには法則があり、その法則という言葉をルーティンとしてポピュラーに表現したものであり、物事を発見してまとめるという体験がルーティンなのです。
ネットワークIOのセットを理解する意味
ネットワークIOは、ネットワーク通信の重要な部分として、自己研究またはオープンソースのマイクロサービスフレームワークの様々な種類のコンテキストでは、その原理を理解するために、より深くRPCフレームワークの様々な種類の基礎となる実装を理解するのに役立ちます同時に、セット内のネットワークIOを理解するだけでなく、ネットワーク媒介ミドルウェアの様々な種類の研究では、そのようなredis、nginx、mqなどの前提の前提に。
ネットワークIOの分類
IOは現在、BIO、NIO（no/no block io）、AIO（async io）の3つの主要なカテゴリに分かれています。
BIOの策略について話してください。
BIOは、同期ブロッキングIOとして、サーバーの観点から、そのネットワークのブロッキングは、主に受信フェーズに反映され、読み取りと書き込み（ライトバック）フェーズは、クライアントがサーバーに要求していない場合、サーバーがacceptメソッドのために呼び出され、ブロッキング状態にされている、クライアントが接続されるまで、それは次のロジックの実装にダウンし、いつ来るでしょう。クライアントがサーバーにデータを送信する準備ができていないときに、サーバーがクライアントのデータを読み取るためにメソッドを読み取る呼び出すと、サーバーが再びブロッキング状態に入るにつながる、同様に、呼び出しでは、データを書き戻す書き込みも同じです。BIOは、その受信と読み取りと書き込みのため、同時実行シナリオのパフォーマンス問題につながる、ブロッキングにつながるだけでなく、NIOでは、前に表示されなかったため、同時実行シナリオをサポートするために、マルチスレッド技術の使用は、接続があるときに来て、サーバーは、クライアントのソケットを受信し、各ソケットは、スレッドを開くには、サブスレッドがあるクライアントに読み取り、操作に書き戻すが、どのようなシステムのために、クライアントは、データを送信する準備ができていない、サーバーが再びブロッキング状態に入るにつながるでしょう。クライアントに書き戻すが、どのようなシステムのために、スレッドの数が無限に成長することはできません、あまりにも多くのスレッドが頻繁にCPUのスケジューリングとコンテキストスイッチングにつながる、システムが過負荷になり、その結果、パフォーマンスの急激な低下、あるいはクライアントの固有の欠点への接続数のサポートでBIOです利用できなくなります。現在、BIOの最大の使用は、データベースでは、しかし、これはJDBC標準の開発の一部によるものですIOはまだ唯一のBIOは、標準に基づいて、現在の主要なデータベースは、データベース接続プーリングの出現の理由の1つであるように、BIOです。
NIOのセットアップについて話してください。
NIOの2種類があり、1つはブロックioなし、すなわち、同期ioをノンブロッキングです、1つはioなし、すなわち、ioではありません。 NIOは、BIOの高コストによってもたらさノンブロッキングの実装を排除し、BIOと比較すると、ノンブロッキングを実現する必要がある場合は、各クライアントのためのスレッドを割り当てる必要がある、リソースとサーバーのパフォーマンスの占有率は膨大です。サーバーの原則は、イベントのサーバー側が送信または読み取るために利用できない場合、次のポーリングを開始するために継続される、操作をブロックされません受け入れるか、または読み取りを呼び出します、オペレーティングシステムは、モデルの3つのタイプは、それぞれ、選択、ポーリングとepollをNIOを実装するために、Javaでは、そのNIOは、セレクタのJDKの実装に基づいています。Javaでは、NIOはSelectorのJDKの実装に基づいて、Selectorが対応するイベントに耳を傾けるとき、それは処理する対応する方法を使用します。Selectorの基礎となる実装から、JDKは異なるシステムでサポートされるNIOモデルに適応します。例えば、Linuxはepollを使用し、Windows OSはselectを使用します。selectモデルの場合、ユーザーの状態のメカニズムは、サーバーが受信したソケットのリストを維持し、ポーリングのたびに、システムのカーネルの状態にユーザーの状態のリストを渡す必要があります、オペレーティングシステムは、すでにイベントを処理することができますソケットのリストをフィルタリングするために、その後、話すことができるソケットのリストを埋めるために対処し、ユーザーの状態に戻ります。そして、オペレーティングシステムは、リスト内のどのソケットがすでに処理可能なイベントを持っているかをフィルタリングし、処理可能なソケットをユーザステートにリストを埋めた後にカーネルに返し、ユーザステートは、周期的にアクセプト操作かリード操作かを判断し、対応するロジックを呼び出して順番に処理します。selectには2つの欠点があります。一方では、イベントが発生しているかどうかをポーリングするたびに、ユーザステートからカーネルステートにソケットをコピーする必要があり、これは比較的非効率的です。もう一方では、selectはソケットを格納するために配列を使用します。一方、selectはソケットを格納するために配列を使用し、クライアントの接続が多くなると、オペレーティングシステムのデフォルトで配列の容量が1024に設定されている、つまり、デフォルトでは、最大1024ソケットを管理することができ、これもクライアントへの接続数の制限につながる;ポールの場合は、主にselectとポールを組み合わせることで、一般的にselectの実装と同じ、selectの改良の一種と言うことができます。同じの実装は、主に元の配列のストレージを選択するように、それは理論的にはより多くの接続をサポートできるように、リンクリストストレージに変更されましたが、それでも各ポーリング操作は、ユーザー状態からカーネル状態のコピーに実施する必要が変更されません。まず、select and pollモデルの各ソケットがユーザステートからカーネルステートへのフルコピーを必要とするのに比べて、epollではインクリメンタルな挿入になります。 サーバは新しいソケットを受け取った後、ソケットのfdを直接カーネルに渡します。カーネルはこれらのソケットのメンテナンスを担当し、イベントがあると、カーネルは対応するデータをユーザステートに返し、カーネルはイベントを処理します。エポールモデルでは、カーネルのストレージソケットモデルも変更され、赤黒木＋双方向リンクリストの組み合わせが使用され、新しいソケットが生成されると、ソケットは赤黒木のノードに挿入され、ソケットが閉じられると、ソケットは赤黒木のノードから削除され、オペレーティングシステムがイベントをリスンすると、ソケットはイベントソケットの双方向リンクリストに配置されます。オペレーティングシステムがイベントをリッスンするとき、それは双方向チェーンテーブルにイベントをソケットに配置されます。 双方向チェーンテーブルにデータがある場合、Javaを例にして、ユーザー状態のこの層は、チェーンテーブルがすでにデータを持っているため、ブロッキングで連絡されます、それは双方向チェーンテーブルのイベントに応じて対応するユーザーコードロジックを実行します。現在、Javaの多くのNIOボックスがあり、例えば、nettyのように、nettyは、Javaの伝統的なnioは、ユーザーが独自のアンパッキングとスティッキーパケットを実装する必要があります解決し、nettyはまた、空のポーリングの問題についてJavaのnioを解決します。
AIOのセットアップについて
AIOは一種の非同期ノンブロッキングIOで、BIOやNIOに関係なく、カーネルバッファが準備完了になると、対応するスレッドがデータを処理するためにreadメソッドやwriteメソッドを呼び出す必要があり、この種のイニシアチブは一種の同期操作です。データの準備が整うと、サーバから能動的に呼び出されることはなく、最初にサーバから渡されたコールバック関数を使用してシステムから直接呼び出され、データが処理されたことをサーバに通知します。現在、AIOの実装は、Windowsシステムでより成熟している、WindowsはIOCPと呼ばれるI/O完了ポートと呼ばれるスキームを提供し、そのパフォーマンスが優れているので、JDKのWindows版では直接JavaのAIOサポートとしてIOCPを採用しています。Linuxの場合は、カーネルベースのAIOの実装がありますが、LinuxのAIOは、主にディスクファイルIOではなく、ネットワークソケットレベルのIOのため、より多くの制限の使用から、パフォーマンスも一般的ですが、JDKのLinux版では、AIOのカーネルカーネルの実装を使用していませんが、自作のスレッドプールの使用。自作のスレッドプールは、実際には、最後のエポールの底部、擬似AIO。
人生のシナリオにおける3つのセットについて話しましょう。
肉を買うために市場に行く、肉の屋台は、販売と肉のカットを担当している同じ人であり、この時間は、屋台の所有者が唯一の顧客にサービスを提供することができ、顧客が屋台に行く、あなたが順番にキューにする必要があり、顧客の待ち時間が長くなるの大きい数を購入する人の数、および一部の顧客は、どのような肉を買うために良いの先頭ではないため、屋台の前にピックして考える必要があり、それはさらに人々の待ち時間の背面の行を悪化させることは容易です！顧客の待ち時間を短縮するために、屋台の所有者は、労働力の分業のこのプロセスの肉を販売するために、屋台の所有者は、顧客にサービスを提供するスタッフによって、別の従業員に分かれて、顧客のトリアージを担当していますが、肉屋の所有者は、同じ環境の労働者が成長することはできません経済コストとスペースの場所を考慮する必要があり、最終的に多くの人々が前の場合と同じになります、シーンはBIOモデルに対応しています。このシナリオは、BIOモデルに対応しています。この時点で、屋台の所有者は、いや、顧客の背後にある野菜のピッキングの顧客を受信することはできません、顧客が長すぎる列に待機し、残して簡単に、または改善するために、さらに顧客体験を最適化するために、屋台の所有者は、レンタル店の外の市場で直接アップグレードすることを決定し、今、顧客が食品を買いに来て、唯一のガイダンスを受信するためにドアの店員を持っている必要があり、顧客が店に、あなたは最初から並んで待つことなく、ゆっくりと自分の肉を選ぶことができ、肉のピッキングが完了するまで待つ、などなど。お客さんは最初から並ばずに自分でお肉を選んで、選び終わったら店員さんに声をかけてレジに行き、店員さんが仕事の状況に合わせて適切なタイミングでレジを進めてくれる、それがNIOのモードです。しかし、ビジネスが良すぎるため、結局のところ、店はまだ人々を収容することができます限られている、より多くの人々が、受付も圧倒され、顧客が店に入って、チェックアウトを待つ必要がある場合、ボスは、この経験をさらに最適化することができると感じた、ボスは明るいアイデアを持っていた、持ち帰りプラットフォームへのアクセスは、顧客は今、唯一の指を移動する必要があり、アプリで料理を選択し、住所を記入し、注文し、準備ができて注文に応じて店内！良い後、直接自宅への配送を手配する注文のアドレスに応じて、これはAIOのモデルです。
概要
限られたスペースのため、上記の内容を網羅することはできませんし、プログラミング言語から最終的なカーネルの実装にIOシステムは、複雑なプロセスであり、私はまた、学び続けている、上記はまた、3つのネットワークIOセットの下で大まかに言えば、入門書であると考えられ、より詳細な議論のための各IO実装の詳細については、以降の記事になります、公式より多くのサポートを見てください。
