多線程REST API客戶端的設計

我正在接收一個程序，該程序接收主題的搜索請求，使API調用紐約時報API來獲取與該主題相關的文章，然後到Twitter API獲取提及文章的推文，並最終處理結果並將其返回。多線程REST API客戶端的設計

我必須使這個多線程。我想過使用帶有固定大小線程池的ExecutorService。所以，每個傳入的搜索請求將由一個單獨的線程處理。我也使用Callable接口來提交任務。實現Callable的類執行API處理（使&接收API請求/響應）。最後，結果由Future提取並顯示爲輸出。這發生在每個傳入的請求中。

這是否有意義？還是有更好的方法來做到這一點？

編輯：我在我的本地機器上運行這個接受命令行界面的數據。

來源

2012-02-28 gofeddy

什麼服務器應用程序？ – 2012-02-28 15:09:53

如果這是一個Web應用程序，默認情況下它是多線程的。如果不是 - 你仍然可以將它部署在一個servlet容器上，這將是有益的。線程池由底層容器（例如tomcat）提供。每個請求都由一個單獨的線程提供服務。

唯一的東西去關心：

不使用
清理任何ThreadLocal您使用

來源

2012-02-28 15:05:56 Bozho

這不是一個Web應用程序。我在我的本地機器上運行它，接受來自CLI的數據。但我仍然想讓它成爲多線程的。 – gofeddy 2012-02-28 15:12:26

爲什麼不在servlet容器上運行它？ – Bozho 2012-02-28 15:28:51

我想我最終會考慮這個選項。在此之前，我試圖查看是否可以通過java.util.concurrent功能集實現某些功能。 – gofeddy 2012-02-28 15:43:22

變量我將專注於獲得工作流程正確，然後剖析見遇到瓶頸，然後試圖查看併發性（線程！=併發或異步執行）可能會對您有所幫助。使用多線程執行飽和CPU，網絡或磁盤I/O不會讓事情變得更快，並且通常會損害性能，特別是在超線程的英特爾CPU上。

然後我會擔心更多關於使它成爲多線程之前的非阻塞和異步。阻塞任務（序列化）完全否定了嘗試使用線程使事物併發的好處。

多線程並不奇蹟般地表示如果任務仍在工作流中序列化，它將運行得更快或更高效。相反，如果你事先沒有消息傳遞和異步事件，它甚至會讓事情變得更慢，效率更低。

另外，如果你在Core i7筆記本電腦的頂部運行這個，你只會得到4個真正的線程（4個超線程通常會讓CPU綁定應用程序變得更糟）以及試圖使事情發生在連續的順序之後，然後放回去可能不會給你帶來任何真正的收益和複雜性。在更多的核心服務器上，這可能不是這種情況，在筆記本電腦上，線程不會給你帶來太多。

「做併發很容易，做併發正確是非常困難！」 - 解釋我的合氣道老師

來源

2012-02-28 15:20:00

不知道是否使用[Node.JS]（http://nodejs.org/）是一個簡單的異步解決方案的想法... – beny23 2012-02-28 15:25:39

我想這並不重要。我嘗試每次發送10-15個請求，使用不同大小的線程池，但響應時間從未顯示任何改進/更改。此外，現在，我可以看到，在提交任務後使用Futures獲取結果確實會阻止此應用程序。我會仔細研究一下，看看我是否能夠實現無阻塞。 – gofeddy 2012-02-28 15:31:25

@Jarrod Roberson：* 4個超線程通常會讓CPU捆綁的應用程序變得更糟* [原文如此] ...並且*「在筆記本電腦線程上不會讓你感覺太多」* [原文如此] ...關於第一個報價，鏈接將非常受歡迎。關於第二個引用，我已經多次目睹了相反的情況：使用* producer/consumers *方案來壓縮數據，在將消費者線程的數量與CPU數量相匹配時，我獲得了更好的吞吐量（舊Core 2 Duo中已經引人注目例如Mac筆記本電腦）。您是否真的在多核CPU的當今時代倡導單線程生產者/消費者？ – TacticalCoder 2012-02-28 16:04:54

多線程REST API客戶端的設計

回答

相關問題