🙅🏽 👩🏼‍💻 🐻 「非同期イベントモデル」とは何か、なぜ「ファッション」になっているのか 👍🏿 👰🏼 🐋

テーマのあるインターネットでは、「Node.js」という言葉が流行しています。この短い記事では、このすべてがどこから来たのか（「指で」）、このアーキテクチャがアプリケーションコード（ PHP + MySQLの通常のWebサイト）で「同期」および「ブロッキング」I / Oを使用する通常のアーキテクチャとどのように異なるかを理解しようとします「リクエストごとのスレッド（またはプロセス）による」スキーム（従来のApache Webサーバー）に従って動作するアプリケーションサーバーで実行します。

記事の読みやすさについて

この記事は、ここに登場してから、記事の最後で言及した読者からのフィードバックのおかげで、多くの変更（概念的な変更を含む）と追加が行われました。何かを理解するのが難しいと感じたら、コメントでそれを説明してください。そして、私たちはそれをより理解しやすい言語で記事に書きます。

パフォーマンスについて

twitter 、 VKontakte 、 facebookなどの最新の負荷の高いサイトは、PHP + Apache + NoSQLまたはRuby on Rails + Unicorn + NoSQLの形式のバンドルで動作し、まったく遅くなりません。まず、SQLではなくNoSQLを使用します。次に、多くの同一の実稼働サーバーにリクエストを分散（「バランス」）します（これを「水平スケーリング」と呼びます）。第三に、可能なすべてをキャッシュします。ページ全体、ページの断片、 Ajaxリクエスト用のJson形式のデータなどです。キャッシュされたデータは「静的」であり、 NginXなどのサーバーから直ちに送信されます。アプリケーション。

個人的には、Apache + PHPからNode.jsに書き換えた場合にサイトが高速になるかどうかはわかりません。テーマインターネットでは、「非同期イベントモデル」よりもシステムフローが遅いと考える人と、反対の観点を守る人の両方に会うことができます。

次のプロジェクトを何に書くかを考えて、そのタスクから先に進み、プロジェクトのタスクによく重なるアーキテクチャを選択する必要があります。

たとえば、プログラムが多数の同時接続をサポートし、常にそれらへの書き込みと読み取りを行う場合、この場合は必ず「非同期イベントモデル」（Node.jsなど）を検討する必要があります。 Node.jsは、サブシステムをWebSocketプロトコルに切り替えたい場合に最適です。

「非同期イベントモデル」がうまくいくシステムの例：

各車の動きを監視し、乗客の流れを分配し、最適な経路を計算する、タクシー配車システムのシステム
散在する多くのセンサーからデータを絶えず収集し、化学組成、温度、湿度などを制御する生命維持システム
人体（脳 -制御ロジック、神経系 -データ伝送チャネル）
チャットルーム
MMORPG

ブロッキングおよびノンブロッキング入力/出力とは何ですか？

インターネットユーザーがサイトに接続し、アバターの画像をアップロードするネットワークソケット（「ソケット」-文字通り「接続ポイント」）の例を使用して、入力/出力のタイプを処理します。この記事では、アプリケーションコードのすべての入力/出力が「同期」および「ブロック」である「非同期イベントモデル」と「使い慣れた」アーキテクチャを比較します。「習慣」-以前は、誰もあらゆる種類の「ロック」に悩まされていなかったため、誰もがそのように書き、誰もが十分でした。「同期」および「ブロック」I / Oとは何ですか？これは、ほとんどのサイトが記述されている最も単純で最も一般的な入力/出力です。

ファイルを開く
読み始める
検討されるまで待つ
ファイルが考慮されました
ファイルを閉じる
画面に既読コンテンツを表示する

ソケットの場合、これは次のようになります。

ソケットのリッスンを開始します
画像データの最初の部分を読み取ります
画像データの2番目の部分が到着するまで待つ
画像データの2番目の部分を読み取ります
画像データの次のバッチを待つ
...
写真が考慮されました
ユーザーにアバターに写真を貼る

同時に、プログラムのコード内で「ブロッキング」が発生します。この間、スレッドはアイドル状態になりますが、何か有用なことができます。この問題を解決するために、「同期」および「非ブロッキング」I / Oが発明されました。

ソケットのリッスンを開始します
新しいデータがない場合、ソケットのリッスンを停止します
画像データの一部がすでに到着している場合-このデータを読み取ります
ソケットのリスニングを停止します

画像データの最後の部分が読み取られるまでこれらのステップがサイクルで実行される場合、最後に再び、全体像を完全に取得します。唯一の違いは、このサイクルでは、ソケットからのデータの読み取りに加えて、「ロック」の下でアイドル状態にならないように、他の便利なことを実行できることです。たとえば、別のソケットからデータを読み取ることもできます。このような「非ブロッキング」I / Oサイクルは、記事の中央近くに再び現れます。

「非同期」I / Oもあります。この記事では考慮しませんが、一般的には、コードから「コールバック」関数を切断します。これは、画像データの別の部分がこのソケットに来るたびにオペレーティングシステムによって呼び出されます。そして、このソケットを一般的に聞いて、他のことをすることをすでに忘れています。「非同期」I / Oは、「同期」と同様に、「ブロック」と「非ブロック」に分けられます。しかし、この記事では、「ブロッキング」と「ノンブロッキング」という言葉の下で、正確に「同期」入出力を意味します。

しかし、この記事では、アプリケーションがシステムスレッドを使用してオペレーティングシステム上で直接実行される「馴染みのある」アーキテクチャのみを検討し、「グリーンスレッド」を備えた何らかの「仮想マシン」では検討しません。「グリーンスレッド」を備えた「仮想マシン」内では、「同期」と思われるI / Oを「非同期」に変えるなど、さまざまな奇跡を実行できます。これについては、「代替方法」セクションで詳しく説明します。

背景

新しいアプリケーションアーキテクチャでの実験の雪崩は、従来のアーキテクチャが開発の夜明けにインターネットのニーズを解決したという事実によって引き起こされました。もちろん、すべてが賑やかである「2ウェブ」ウェブの進化するニーズを満たすように設計されていませんでした。

長年にわたってテストされた一連のPHP + MySQL + Apacheは、 Internet 1.0でうまく機能しました。サーバーは、ユーザー要求ごとに新しいスレッド（またはプロセス、オペレーティングシステムの観点からはほぼ同じ）を開始しました。このストリームはそこからPHPに行き、データベースに行き、そこで何かを選択し、 HTTPを介してユーザーに送信した応答で戻り、その後、それ自体を破壊しました。

しかし、「リアルタイム」アプリケーションの場合、見逃され始めました。「ユーザーとの10,000の接続を同時にサポートする」というタスクがあるとします。このために10,000個のスレッドを作成できます。彼らはお互いにどうやって仲良くなりますか？それらは、システム「スケジューラ」によって互いに共存します。そのタスクは、各スレッドにプロセッサ時間のシェアを与え、同時に誰も奪わないことです。彼はそのように振る舞います。 1つのスレッドが少し動作すると、スケジューラーが開始し、このスレッドを一時的に停止し、「サイトを準備して」次のスレッド（キューで既に待機している）を開始します。

この「サイトの準備」は「コンテキストスイッチング」と呼ばれ、一時停止したストリームの「コンテキスト」の保存、および次に起動されるストリームのコンテキストの復元が含まれます。「コンテキスト」には、オペレーティングシステム自体のプロセッサレジスタおよびプロセスデータ（id'shniki、アクセス権、リソースとロック、割り当てられたメモリなど）が含まれます。

スケジューラの起動頻度は、オペレーティングシステムが決定します。たとえば、Linuxでは、デフォルトで、スケジューラーは100分の1秒のどこかで開始します。スケジューラは、プロセスが手動で（たとえば、スリープ機能によって）「ブロック」されたとき、または「同期」および「ブロック」（つまり、最も単純で最も一般的な）I / Oを見越して呼び出されます（たとえば、データベースがPHPストリームのユーザー要求を待機しているとき）データは彼に毎月の販売レポートを提供します）。

一般的なケースでは、システムスレッド間の「コンテキストスイッチング」はそれほど高価ではなく、マイクロ秒のオーダーであると考えられています。

スレッドがRAMのさまざまな領域をアクティブに読み取る（およびRAMのさまざまな領域に書き込む）場合、スレッドの数が増えると、プロセッサの「セカンドレベルキャッシュ」（L2）が失われます。これはメガバイト単位です。この場合、システムバス上のデータのRAMからプロセッサへの配信、およびシステムバス上のデータのプロセッサからRAMへの記録を毎回待機する必要があります。このようなRAMへのアクセスは、プロセッサキャッシュへのアクセスよりも桁違いに遅くなります。このキャッシュはこのために考案されました。これらの場合、「コンテキスト切り替え」時間は最大50マイクロ秒になります。

インターネット上では、多数の同時ストリームにおける絶え間ない「コンテキストスイッチング」により、システム全体の速度が大幅に低下する場合があります。ただし、この仮説の明確で詳細な数値的証拠は見つかりませんでした。

また、マルチスレッドモデルがアプリケーションのメモリ消費に与える影響を検討してみましょう。「スタック」は、各システムスレッドに関連付けられています。スレッドが引数付きの特定の関数を呼び出すと、この関数の引数は「スタック」に置かれ、コード内の現在のアドレスは「戻りアドレス」と呼ばれます（呼び出された関数の実行が終了するとここに戻るため）。この関数がそれ自体の内部で別の関数を呼び出すと、対応するデータが再び「スタック」に書き込まれ、すでにそこに書き込まれているデータに加えて、もつれのように見えます。

システムスレッドを作成するとき、「スタック」はオペレーティングシステムによってRAM内で全体としてすぐに割り当てられるのではなく、使用時に「ピース」によって割り当てられます。これは「仮想メモリ」と呼ばれます。つまり、各スレッドはすぐに「スタック」の下の「仮想メモリ」の大きな部分に割り当てられますが、実際には、この「仮想メモリ」はすべて「メモリページ」と呼ばれる「部分」に分割され、すでにこれらの「メモリページ」は「実際の」 »RAMは、必要な場合にのみ使用します。スレッドが「実際の」RAMにまだ割り当てられていない「メモリページ」に触れると（たとえば、プロセッサに何かを書き込むようにプロセッサに指示しようとすると）、プロセッサの「メモリ管理ブロック」がこのアクションを検出し、オペレーティングシステムで「例外」を引き起こします「ページフォールト」。「実際の」RAMにこの「メモリページ」を割り当てることで応答します。

Linuxでは、デフォルトのスタックサイズは8メガバイトで、「メモリページ」のサイズは4キロバイトです（1つまたは2つの「メモリページ」がすぐに「スタック」に割り当てられます）。同時に起動される10,000のスレッドに関して、約80メガバイトの「実際の」RAMの要件があります。それは少しのように思われ、心配する理由はないようです。ただし、この場合に必要なメモリのサイズはO（n）になります。これは、負荷がさらに増加すると、「スケーラビリティ」に問題があることを示唆しています。明日、サイトがすでに100,000の同時ユーザーに対応し、100を維持する必要がある場合000同時接続？そして明後日-1,000,000？そして明後日の後-それはまだ不明です...

シングルスレッドのアプリケーションサーバーにはこの欠点はなく、同時接続数の増加に伴う新しいメモリは必要ありません（これはO（1）と呼ばれます）。 Apache Web ServerとNginXのメモリ使用量を比較するこのグラフを見てください：

最新のWebサーバー（最新のApacheを含む）は、完全に「要求時のフロー」のアーキテクチャではなく、より最適化されたアーキテクチャ上に構築されています。到着したすべての要求を処理する事前準備スレッドの「プール」があります。これは、10頭の馬と100人のライダーが乗るアトラクションと比較できます。列が形成され、最初の10人のライダーが「あちこち」に乗るまで、次の10人のライダーが並んで待機します。この場合、アトラクションはアプリケーションサーバーであり、馬はプールからのスレッドであり、ライダーはサイトのユーザーです。

このようなシステムフローの「プール」を使用する場合、同時に、ユーザー数、「プール内にあるスレッドの数」、つまり10,000だけではなく、サービスを提供できます。

このセクションで説明する困難は、非常に多数の同時接続を処理するためのマルチスレッドアーキテクチャの適合性の問題を常に念頭に置いており、まとめてThe C10K problemと呼ばれていました。

非同期イベントモデル

このクラスのアプリケーションには、新しいアーキテクチャが必要でした。そして、この状況では、念のため、「非同期イベントモデル」が登場しました。これは、「イベントサイクル」とテンプレート「リアクター」に基づいています（「反応する」という言葉から-応答する）。

「イベントループ」とは、「イベントのソース」（記述子）をポーリングして、その中にある種の「イベント」が出現するかどうかを調べる無限ループです。ポーリングは、「同期」 I / Oライブラリを使用して行われますが、これは同時に「非ブロッキング」になります（O_NONBLOCKフラグがシステムI / O関数に渡されます）。

つまり、「イベントサイクル」の次のラウンドで、システムはすべての記述子を順番に通過し、それらから「イベント」の読み取りを試みます。読み取り機能によってシステムに返されます。記述子に新しいイベントがない場合、「ブロック」して「イベント」が表示されるのを待機しませんが、すぐに「新しいイベントはありません」という回答を返します。

「イベント」とは、ネットワークソケット上の次のデータ部分の到着（「ソケット」-文字通り「接続の場所」）、またはハードディスクからのデータの新しい部分の読み取り（一般に、任意の入出力）のことです。たとえば、ホスティングに写真をアップロードすると、データが断片的になり、そのたびに「画像データの新しい部分が受信されました」というイベントがトリガーされます。

この場合、「イベントのソース」は、ネットワーク経由でサイトに接続したTCPソケットの「記述子」（データストリームへのポインター）になります。

既に述べたように、新しいアーキテクチャの2番目のコンポーネントは、リアクターテンプレートです。そして、ロシア人にとって、これは原子力発電所の原子炉ではありません。このテンプレートの本質は、サーバーコードが1つの大きな部分で書き込まれ、連続して実行されるのではなく、小さなブロックに書き込まれ、各ブロックが関連付けられたイベントの発生時に呼び出される（「反応する」）ことです。したがって、コードは多くのブロックのセットであり、そのタスクはいくつかのイベントに「応答する」ことです。

この新しいアーキテクチャは、Node.jsの登場後に主流になりました。 Node.jsはC ++で記述されており、そのイベントループはlibev C＃ライブラリに基づいています。ただし、ここでJavascriptは選択された言語ではありません。ライブラリの言語に「非ブロッキング」I / Oがある場合、同様の「フレームワーク」を記述することもできます。PythonにはTwisted 、 Tornado 、PearlにはPerl Object Environment 、RubyにはEventMachine （すでに5歳です）。これらの「フレームワーク」では、Node.jsに似た独自のサーバーを作成できます。たとえば、Java（java.nioベース）ではNettyとMINAが、Ruby（EventMachineベース）-Goliath（ Fibersも利用）が記述されています。

長所と短所

「非同期イベントモデル」は、多くの多くのユーザーがプロセッサをロードしないアクションを同時に実行する場合に適しています。たとえば、「現在時刻」モードのセンサーから温度を取得し、ビデオカメラから画像を取得し、接続された温度計から取得した温度をサーバーに転送し、チャットに新しいメッセージを書き込み、チャットから新しいメッセージを受信します。

プロセッサをロードしないアクションの要件は、この無限ループ全体が1つのスレッドで実行されることを思い出すと、このループに重い計算を押し込んだ場合（たとえば、微分方程式の解法を開始した場合）、他のすべてのユーザーは、この計算が完了するまで順番に待機します。

したがって、Node.jsのようなサーバーは、プロセッサをロードしないタスクに適しているか、重いバックエンドのフロントエンドとしてのみ適しています。また、「遅い」リクエスト（狭い通信チャネル、遅いリターン/データの送信、内部のどこかでの長い応答時間など）を処理するためのサーバーとしても適しています。 Node.jsのようなサーバーに「入出力」仲介の場所を与えます。たとえば、「クライアント」と「サーバー」の間の仲介：視覚的表現全体が作成され、インターネットユーザーのブラウザーで直接レンダリングされ、必要なすべてのデータがリポジトリのサーバーに保存され、Node.jsが仲介のタスクを実行し、要求に応じて「クライアント」に必要なデータを提供します、「クライアント」から来たときに新しいデータをリポジトリに書き込む。

「非同期イベントモデル」によるサーバーが同じシステムスレッドで実行されているという事実により、実際にはさらに2つの障害が発生します。 1つはメモリリークです。 Apacheが新しいリクエストごとにシステムスレッドを作成する場合、ユーザーに応答を送信した後、このシステムスレッドは自己破壊し、それに割り当てられたすべてのメモリは単に解放されます。たとえば、Node.jsの場合、開発者は次のユーザーリクエストを処理するときにトレースを残さないように注意する必要があります（そのようなリクエストが到着したすべての証拠をRAMから削除する）。そうしないと、プロセスはますます貪食します新しいリクエストごとのメモリ。 2番目は、プログラムのエラー処理です。繰り返しますが、通常のApacheが別のシステムスレッドを作成して着信リクエストを処理し、PHP処理コードが何らかの「例外」をスローすると、このシステムスレッドは静かに「死に」、ユーザーは「500」のようなページを受け取ります。内部サーバーエラー。」同じNode.jsの場合、単一のリクエストの処理中に発生した唯一のエラーはサーバー全体を「プット」します。そのため、手動で監視および再起動する必要があります。

「非同期イベントモデル」のもう1つの潜在的な欠点は、「コールバック」が織り交ぜられているために、アプリケーションコードが理解しにくくなる場合があることです（常にではありませんが、特に、意図しない目的で「非同期イベントモデル」を使用する場合に起こります）。これは「スパゲッティコード」問題と呼ばれ、「コールバック時のコールバック、コールバックチェイス」と説明されています。彼らはこれと戦おうとしており、例えば、 SeqライブラリはNode.js用に書かれています。

一般に「コールバック」を排除する別の方法は、いわゆる継続（コルーチン）です。たとえば、 Scalaではバージョン2.8（コルーチン）から、Rubyではバージョン1.9（ファイバー）から導入されています。 RubyでFibersを使用して、コールバックを完全に排除し、すべてが同期的に発生しているようにコードを記述する方法の例を次に示します。

同様のノードファイバーライブラリがNode.js用に作成されました。パフォーマンスの観点から（実際のアプリケーションではなく、人工的なテストで）、ノードファイバーは、「コールバック」を使用した通常のスタイルよりも約3〜4倍遅く動作します。ライブラリの作成者は、Javascript がV8エンジンの C ++コード（Node.js自体に基づいている）に適合する場合にこのパフォーマンスの違いが生じると主張し、パフォーマンス測定は「ノードファイバーが3〜4倍遅い」と解釈されるべきではないコールバック ''ですが、コード内の他の低レベルアクション（バイト配列の操作、データベースまたはインターネット上のサービスへの接続）と比較すると、ノードファイバーのパフォーマンスフットプリントはまったく目立ちません。

通常のプログラミングスタイルに加えて、ノードファイバーはtry / catchエラーを処理するための使い慣れた便利な方法も提供します。ただし、このライブラリはNode.jsのコアには埋め込まれません。RyanDahlは、作成の目的を低レベルに保ち、開発者に何も隠さないように考えているためです。

この記事の主要部分は終わりました。最後に、別の方法と、「イベントサイクル」が「イベントのソース」をポーリングして、新しいデータが表示される方法を簡単に検討します。

別の方法

この記事では、「同期」および「ブロック」I / Oを使用するアプリケーションが多数の同時接続に耐えられない理由を説明しました。ソリューションの1つとして、このアプリケーションを「非同期イベントモデル」に変換することを提案しました（つまり、Node.jsでアプリケーションを書き換えます）。このようにして、実際に（バックステージで）「同期」および「ブロック」I / Oから「同期」および「非ブロック」I / Oに切り替えることで問題を解決します。しかし、これが唯一の解決策ではありません。「非同期」I / Oに頼ることもできます。

つまり、システムフローの古き良き「プール」（この記事の前半で説明）を使用できます。これは、開発の新しい段階に進化しました。この開発段階は「グリーンプロセス」と呼ばれます（したがって、「グリーンストリーム」もあります）。これらはプロセスですが、システムのプロセスではありませんが、コードが記述されている言語の仮想マシンによって作成されます。仮想マシンは、システムスレッドの通常の「プール」を内部で起動し（たとえば、プロセッサのコア数によって）、これらのシステムスレッドに内部の「グリーンプロセス」を既に表示します（これを開発者から完全に隠します）。

「グリーンプロセス」は正確には「プロセス」であり、「フロー」ではありません。これらは互いに共通の変数を持たず、制御「メッセージ」を相互に送信することによってのみ通信するためです。このモデルは、さまざまな「デッドロック」に対する保護を提供し、データ共有の問題を回避します。これは、「グリーンプロセス」を持つのは内部状態と「メッセージ」だけだからです。

各「オブジェクト」には「メッセージ」の順番があります（このために「グリーンプロセス」が作成されます）。そして、「オブジェクト」のコードへの呼び出しは、「メッセージ」を彼に送信することです。ある「オブジェクト」から別の「オブジェクト」への「メッセージ」の送信は非同期的に行われます。

これに加えて、仮想マシンは独自のI / Oサブシステムを作成します。これは、非ブロッキングシステムI / Oにマップします（開発者は何も疑っていません）。

そして、もちろん、仮想マシンには独自の内部スケジューラも含まれています。

その結果、開発者は、通常の入力/出力を使用して通常のコードを記述すると考えていますが、実際には非常に高性能なシステムが登場します。例： Erlang 、 Scalaのアクター。

「イベントサイクル」で「イベントのソース」をポーリングして、新しいデータを表示する方法

最も簡単な解決策は、すべての「記述子」（ネットワークソケットを開く、ファイルの読み取りまたは書き込みなど）でクエリを実行して、新しいデータを取得することです。このようなアルゴリズムは「ポーリング」と呼ばれます。次のようになります。

あなたは2つの開いたソケットを持っています
これらのソケットを記述する2つの構造の配列を作成します
この配列の各要素に何とどのソケットを書き込むかを記述します
次に、この配列をポーリングシステム関数に渡します。ポーリングシステム関数は、これらのソケットの現在の状態の説明をそこに書き込みます
その後、再びこの配列を調べて、これらのソケットに新しいデータがあるかどうかを判断します
もしあれば、それらを読んで、彼らと何かをしてください
これはすべて、無限の「イベントサイクル」の新しいラウンドで繰り返されます。

さらに、オペレーティングシステムが「カーネルスペース」と「ユーザースペース」で構成されているため、言及されたデータ配列は参照によって送信されず、コピーされます。

RAMからプロセッサレジスタへのデータの配信、およびプロセッサレジスタからRAMへのデータの送信は高速な操作ではないため、アレイの前後へのコピーなどはシステムパフォーマンスに影響します（システムバス上のデータがRAMに移動し、それから来ます）。

さらに、大半（約95％）対応するソケットには新しいデータがないため、結果の配列（約10,000個のオープンソケットの場合）は役に立ちません。

また、この配列のサイズは記述子の数に比例して大きくなるため、ソケットが開いているほどこのアルゴリズムが機能することがわかります。つまり、サイトへの同時訪問者が多いほど、「イベントサイクル」の速度が低下し始めます。この場合、彼らは言う：「アルゴリズムに複雑性O（n）があります。」

より最適なアルゴリズムを書くことは可能ですか？それは可能であり、これらは、主要なサーバーオペレーティングシステムで書かれています：ファイルディスクリプタ LINUXとし、kqueueの FreeBSD上では。 WindowsにはIO Completion Portsもあります。これは、epollの近縁の一種です。Node.js開発者がWindowsに移植する際に使用し、libevライブラリとIO完了ポートの両方に単一のインターフェースを提供するlibuvライブラリを作成しました。epollを

検討してください。両側の単純な投票とは異なります。

プログラムは、すべての記述子（およびすべてのタイプのイベント）をまったくチェックしませんが、必要な記述子（およびイベントのタイプ）のみをサブスクライブします。
カーネルは、/ dev / epollファイルを作成することにより、記述子データを含むメモリ領域をプログラムから見えるようにします（実際にはこれは「デバイス」ですが、Linuxの哲学の観点からは「すべてがファイル」です）。プログラムは、mmap関数を使用して、まったくコピーせずにこのファイルを読み取る（および書き込む）ことができます。新しいメッセージの存在は、ioctlシステム関数によってチェックされます。

記述子の通常の列挙にO（n）時間かかった場合、これらの最適化されたアルゴリズムはO（1）時間を必要とします。つまり、サイトへの同時訪問者の数が増えても遅くなりません。

記事の編集に参加したユーザー

この記事には、ユーザーが提案したセマンティック編集が含まれています：akzhan、erlyvideo、eyeofhell、MagaSoft、Mox、nuit、olegich、reddot、splav_asv、tanenn、Throwable。

ユーザーが気付く構文およびスタイルの変更：Goder、@ theelephant。

「非同期イベントモデル」とは何か、なぜ「ファッション」になっているのか