私は次のような問題を抱えています：
サーバープロセス1
サーバープロセス2
重要なのは、プロセス1とプロセス2がクライアントに送り返す結果はまったく異なり、無関係です。
これをどのように分解しますか？常にデータを送信するプロセスが1つだけあり、リターンタイプが1か2かに対応するビットを持つようにプロトコルを定義していますか？
2つのプロセスがありますか？では、どのようにしてデータストアを共有するのでしょうか（データベースではなく単なる構造です）。
ありがとう！
Twistedに制限できる場合は、PerspectiveBrokerを使用することをお勧めします。これは本質的にRPCシステムであり、「クライアント」と「サーバー」の概念についてはあまり気にしません。TCP接続のイニシエーターまたはレスポンダーのいずれかがPBでRPC呼び出しを開始できます。
したがって、サーバー1は、コールバックオブジェクトを使用した登録呼び出しを受け入れ、新しいデータが利用可能になるたびにコールバックを呼び出します。サーバー2は、クライアントが必要とするさまざまなRPC操作を提供します。それらがまったく同じデータで動作する場合、両方のサーバーを1つのプロセスに配置します。
一連のintを「どこか」でストリーミングし、データストアに収集したいようです。私のシステムでは、センサーの読み取り値をデータベースにストリーミングし、センサーの読み取り値をWebクライアントに直接送信して、ライブの電力読み取り値を提供しています。データベースがライブデータに適していない理由についてブログエントリを作成しましたが、後で分析するためにデータを保存するのに最適です。
最初のサーバープロセスは、txampを使用してintをRabbitMQにストリーミングするツイストサーバーにします。ライブデータが必要なクライアントは、Txampを使用してRabbitMQのストリームにサブスクライブできます。WebブラウザクライアントがOrbitedを使用できる のは、実際の例です。
デザインサーバーでは、1がデータベースに保存されます。代わりに、server3にRabbitMQからデータを収集させ、それをデータベースにストリーミングさせることができます。データのチャンクを収集し、グラフをレンダリングして中央のファイル共有に保存するサーバーを計画しています。
独自のメッセージングシステムを作成しないでください。RabbitMQは十分にテストされ、スケーラブルであり、問題が発生した場合でも「メッセージ」（生データ）を保持できます。
「単なる構造」の代わりにデータベースを使ってみませんか？リレーショナルDBと非リレーショナルDBはどちらも、多くの実用的な利点を提供します（それらを使用する個別のプロセス、レプリケーションの処理[[および/またはスナップショット、バックアップ、...]]、「クエリ」に必要な場合の豊富な機能など。など）。
最悪の場合、「単なる構造」は、完全に専用の3番目のプロセスで処理できます（基本的に、DBエンジンが提供するものを模倣しますが、エンジンはおそらくより良く、より速く実行します;-)。少なくとも適切な分解を維持します（2つのサーバープロセスが両方とも「データストアプロセス」と相互作用します）。