私のサーバーの設計を批判してください

Question

私は、債券を取引するために使用されるJavaでサーバーを設計しています。このサーバーは、クライアントUIと分析サーバー間のメディエータとして機能します。分析サーバは脳であり、私のサーバは単に（TCPソケットを使用して）それと対話し、応答をクライアントに転送します。

サーバーは〜500のクライアントを同時に処理することが予想されます。また、1秒あたり〜500メッセージを処理するにはスケーラブルで効率的でなければなりません。

クライアントUIと分析サーバー間のメッセージの流れはこうです：

1. Client through the UI requests for price. 
2. My server accepts the message, formats it and then asynchronously 
    sends to the analytical server. 
3. When the response from the analytical server arrives, format and send 
    the response to the client UI. 
4. If the client likes the price, he/she will request to trade. 
5. Repeat steps 2 & 3. 

は私が認証を処理するために活用し、自分のサーバーとクライアントのUIの間 メッセージを送信するために、既存のフレームワークがあります。私はすでに私のサーバーと分析サーバーの間のメッセージビットをコーディングしています。

私のサーバーの残りの部分を設計する限り、私は4つのブロックキューを持つことを考えています。価格の要求が来たら、すぐに要求をキュー（Queue1）に挿入します。次に、Queue1からメッセージを取り出し、それをフォーマットして別のキュー（Queue2）に配置するプロセッサを用意しました。プロセッサクラスには内部的にスレッドプール（Executors.fixedThreadpool）が含まれており、各メッセージの書式設定は別のスレッドで行われます。

次に、別のスレッドプールを含むディスパッチャクラスがあります。このディスパッチャクラスは、Queue2からメッセージを取り出し、それをAnalyticalサーバーに書き込む役割を担います。

分析サーバーからメッセージを受け取ったら、別のキュー（Queue3）に挿入します。私は、メッセージをデキューしてフォーマットし、別のスレッドプールに入れて、別のスレッドプールに入れます（Queue4）。最後にQueue4からpopsメッセージを持つ別のスレッドプールがあり、クライアントにパブリッシュされます。

私が4つの異なるキューを選択したのは、私が望むなら、これらのキューのサイズを観測するためのツールを書くことができるからです。これらのキューのサイズに関する情報は、

1. Allow me to tune the size of the thread pools. 
2. Further, if needed, I can publish the messages contained in these queues 
    thus allowing me to monitor all the messages that flows through my server. 

だと思います。どんなアイデアやヒントも大歓迎です。

乾杯

Answer 1

まず、サーバーが1秒あたり〜500件のメッセージを「処理」する必要があると言うとき、「ハンドル」とはどういう意味ですか？同意する？何か他のことを意味するならば、分析サーバーが非同期でどのようにジブがどうなっているのか分かりません。

第2に、3つのキューが多すぎると思います:-)サーバーと分析サーバー間の同期/非同期バッファーとして動作するキューが必要です。それ以外には、何か他のものをキューイングすることはほとんどありません（分析サーバーからどのように応答が返ってくるかによって決まります;何らかの理由で通知される代わりにポーリングしている場合）そこにもキューがあります）。

Answer 2

あなたは500件のスレッドになってしまいますように、それはメッセージを処理するために1秒よりも長い時間がかかるのであれば、それは、聞こえますか？

Answer 3

アナリティクスサーバーからメインサーバーにメッセージを送り返すために利用できるさまざまな方法は何ですか（クライアントに転送します）。

• ポーリング？
• キュー？ （これは、メインサーバーのスレッドがキューをポーリングしてクライアントにメッセージを送信する必要があることを意味します）
• 他に何か？

Answer 4

この4つのキューを持つデザインは、私に少し工夫されています。これらのキューではなく、一連の責任設計パターンを使用する必要があります。エンコーダ/デコーダとハンドラでNettyを使用する場合、これらのキューはすべて必要ありません。 Nettyはまた、メモリのチェックを維持しながら別のスレッドでイベントを処理できるメモリ対応のスレッドプールエグゼキュータを提供します。

お客様の要件「キュー内のサイズを確認できます」は疑わしいです。キューのサイズが不足している場合、電子メールを自分宛に送信するために、単純なロギングメカニズムが機能するはずです。これは、主にアナリティクスサーバーがダウンしている状況を示しているため、とにかくアプリケーションの状態は悪くなります。耐久性のために、サーバーのクラッシュの場合に受信データをジャーナルに格納して、そこに格納することができます。