批評我的服務器設計請

Question

我正在設計一個java服務器，用於交易債券。該服務器將充當客戶端UI和分析服務器之間的中介。分析服務器是大腦，我的服務器將簡單地與它交互（使用tcp套接字）並將響應轉發給客戶端。

服務器預計可同時處理約500個客戶端。它必須具有可擴展性和高效率才能處理大約每秒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個阻塞隊列。當價格請求到來時，我立即將請求插入隊列（隊列1）。然後我有一個處理器，它將消息從隊列1中取出，格式化並放入另一個隊列（隊列2）。處理器類內部包含一個線程池（Executors.fixedThreadpool），並且每個消息的格式都在一個單獨的線程中進行。

然後我有一個調度程序類，其中包含另一個線程池。此調度程序類負責從Queue2中獲取消息並將其寫入分析服務器。

當我從分析服務器收到消息時，將其插入另一個隊列（Queue3）。我有另一個線程池，將郵件出隊並格式化，並將其放入另一個隊列（隊列4）。最後，我有另一個帶有Queue4彈出消息的線程池，併發布到客戶端。

我之所以選擇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

首先，當你說你的服務器必須「處理」〜每秒500條消息時，你的意思是「處理」是什麼意思？接受？因爲如果你的意思是其他任何東西，我不確定在分析服務器是異步的情況下如何解決這個問題。

其次，我認爲你有3個隊列太多:-)你需要一個隊列來充當你的服務器和分析服務器之間的同步到異步緩衝區。除此之外，排隊還有點意義（呃，這取決於你是如何從分析服務器獲得響應的;如果由於某種原因你在輪詢它而不是被通知，那麼你可能需要在那裏排隊）。

Answer 2

所以，它聽起來就像你將與500個線程結束了，如果它需要更長的時間超過1秒來處理消息？

Answer 3

將消息從分析服務器發送回主服務器（然後將其轉發給客戶端）的方法有哪些？

• Polling？
• 隊列？ （這將意味着在主服務器上的一個線程需要對隊列的查詢和發送信息到客戶端？）
• 還有別的嗎？

Answer 4

這種設計4個隊列看起來有點過度設計給我。您應該使用責任鏈設計模式，而不是這些隊列。如果您將Netty與其編碼器/解碼器和處理程序一起使用，則不需要所有這些隊列。 Netty還提供了一種內存感知線程池執行器，它可以在保持內存檢查的同時在另一個線程中處理事件。

你的要求：「我可以在隊列檢查大小」的嫌疑。一個簡單的日誌記錄機制應該可以工作，以便在隊列大小失控的情況下使其複雜的發送郵件給自己。這主要表示分析服務器關閉等情況，所以無論如何，您的應用程序將處於不良狀態。對於耐久性，您可以記錄/和或在數據庫中存儲傳入數據並在服務器崩潰的情況下重播。