問題タブ [event-driven]

Tornado で単純なアプリケーションを作成しようとしています。Tornado はイベント ドリブンの Web サーバーです。Python 上にあるため、Multiprocessing を使用してみますが、何に使用しますか?

パスワードハッシュは線形操作ですよね? パスワードを1000回ハッシュすると、すべてnの操作で操作が必要になりn-1ますか?

画像処理についてはどうですか? フォームで使用されている場合、クライアントがフォームを検証するまで待たなければなりませんか?

マルチプロセッシングから得られる唯一の例は 3D レンダリングです。プロセスが増えるほど、時間が増えます。

次のワークフローでプロジェクトに取り組んでいます。

パート 1:

• イベントは非同期に到着し、ブロッキング キューに入れられます。これをQ1と呼びます
• スレッドは、そのキューから次に利用可能なアイテムを取得します
• アイテムは {N} 個のタスクを並行して実行することになります
• 各タスクはその結果を 2 番目のキューに入れます。これをQ2と呼びます。
• アイテムの処理が終了すると、次のアイテムがキューから読み取られます。

パート2：

• 別のスレッドがQ2から一度に 1 つのオブジェクトを読み取り、結果を処理します。

したがって、ここでの問題は、最初のキューのすべてのアイテムが多数のタスクを並行して実行することになり、各タスクがその結果をキューに入れることです。2 番目のキューは、一度に 1 アイテムずつ順次処理する必要があり、フラッディングされています。

私の質問

Q2の項目数が特定のしきい値を下回るまで、 Q1を処理するスレッドを待機させるメカニズムが必要です。これを達成するための最良の方法は何ですか？ポーリング ソリューションではなくイベント ドリブン ソリューションを使用する方法はありますか?

イベント ドリブンと nodejs に関するいくつかの投稿を読んだ後、イベント ドリブンがスレッドのメモリ割り当てを回避し、可能な場合はポーリングを通知に置き換えるという唯一の利点がわかりました。

他の利点はすべて議論の余地があります。

1. マルチスレッド プログラムは、シングル スレッドよりもミスを犯しやすいです。

   議論: Web アプリケーションの場合、ハンドラー関数に副作用がない限り、リクエストは互いに独立しています。すべての IO 部分がデータベース サーバーによって処理される場合、マルチスレッドについて心配する必要はありません。

2. イベント ドリブン アプローチは IO でブロックされないため、より多くのリクエストを処理できます。この利点は、イベント駆動型の最も重要な機能のようです。この例では診療所と比較していますが、これは適切ではないと思います。

   主張:診療所の例では、受付係は患者が用紙に記入するのを待たずに、前の患者が用紙に記入している間、他の患者にサービスを提供します。これは誤解を招く例です。

   a. 患者をサーバーにリクエストを送信するクライアントとして解釈する場合。もちろん、サーバーは、クライアントが独自のブラウザーでフォームに入力するのをブロックしません。そして、クライアントがフォームを完成させ、http POST をサーバーに送信すると、サーバーは動作を開始します。Web は、nodejs が存在する前からすでにイベント ドリブン システムでした。したがって、この例は、サーバー側のイベント ドリブン プログラミングを説明するのに有効ではありません。

   b. 患者がフォームに記入することは、サーバー側の IO 集中型操作であると解釈すべきだと言う人もいるでしょう。しかし違いは、患者がフォームに記入するのにお金を払うのではなく、IO 集中型の手術にお金を払うということです。

   だから私の主張は、時間のかかる操作が現在のスレッドをブロックしていなくても、他のスレッド、またはプロセスまたはデータベース サーバーがブロックされているということです。ブロッキングがないため、nodejsが10kの同時接続を提供できることを何度も目にします。時間のかかる部分を処理するのに十分な他のスレッド、プロセス、またはサーバーがなければ、それは不可能だと思います。

この場合、イベント ドリブンは nginx を使用したロード バランシング以外の何物でもありません。ただし、ロード バランシングはアプリケーションへのリクエストをバランスさせますが、イベント ドリブンはリクエストを時間のかかる操作にバランスさせ、ロード バランシング レイヤーを後方に移動します。そうすることの唯一の利点は、この質問の冒頭で述べた 2 つです。1. スレッドのメモリ割り当てを回避します。2. 可能であれば、ポーリングを通知に置き換えます。

ここまで読んでくれてありがとう、私の質問は: 私の理解は正しいですか? 私の議論で間違いはありましたか？

フォロワー/フォロー中のユーザーデータを保存するための最良の候補を見つけようとしています。最初は、ユーザー -> ユーザー ID のセットで Redis に保存することを考えていましたが、100 万を超えるシナリオについて考えました1 人のユーザーが 1,000 万人のフォロワーを持つ場合、Redis はどのようにそのような巨大なセットを処理するのでしょうか? また、redis のセットでページネーションを実行する方法はありません。セット全体を取得する必要があります。これは、ユーザーが自分の後に続くユーザーをブラウズしたい場合には機能しません。MySQL に保存すれば間違いなくページネーションを行うことができますが、ユーザー フィードを構築する必要があるたびに、データベースから 1000 万件のレコードを取得するのに長い時間がかかる可能性があります。私はこれを古いバッチ方式で行うことができますが、多くのフォロワーを持つユーザーが何かを投稿し、フォロワーを取得するためだけにこれらの 1,000 万件のレコードを処理するのは、かなり苦痛に思えます。ページネーション (主にフロントエンド) 用に MySQL に保存し、アクティビティ フィードを構築するイベント駆動型メッセージング用に Redis に保存する価値はありますか?

イベント駆動型プログラミングはどのように実装されていますか? アクティブ化された/必要な/可能性のあるすべてのイベントをチェックするのはwhileループですか?

これは私には本当に間違っているようです。イベント ドリブン プログラムは、イベントがアクティブ化されるまで何もするべきではありませんよね? これはループしてループするだけです..おそらくCPUはどんどん高くなります。

インターネット上で実装コードを見つけることができませんでした。