每秒1000條數據處理，每條記錄處理需要10秒鐘，請問需要部署伺服器？
有一個原有系統，每秒鐘生成1000條訂單記錄；
現在需要開發一個新系統，需要將每條記錄取出並推送給其它系統；系統使用http請求將記錄通知給其他系統（注意：一條記錄，需要按順序發送3次http請求，每個請求處理需要3秒鐘，按順序執行，則該方法共需要9秒鐘才能執行結束）；
請問？
問題一: 如此高的數據量， 一臺4核的cpu伺服器，通常最大開啟多少個線程用於http發送？問題二: 按上面的數據，可以開啟多線程發送請求，那麼一臺機器每秒可以處理多少條記錄？問題三: 部署多少臺伺服器，可以應對每秒新增1000條記錄的需求； 應該按什麼思路計算？
問題四：如果是4核CPU，那麼開100個線程和開5個線程的執行效果是不是一樣，線程多了反而會造成頻繁切換線程問題，反而更慢，對不？
如果沒介紹清楚，請看圖片！！
一個函數進行3次同步請求……每次請求等3秒。這個問題好大。
你想啊，你的負責分發請求的伺服器不做具體工作，就只是乾等在那。真正解決任務的伺服器還是一樣該算多少算多少。你的分發請求伺服器的意義在哪裡？
本來是我忙三秒；現在我忙三秒，你等我三秒。人越多等待的人就越多。
你先別問那些複雜的問題，首先把任務派發做成非同步的，請求之後就去忙別的，之後再處理回應，才能邁出正確的第一步……
你把http的io處理模式從同步 阻塞換成非同步非阻塞方式應該可以搞定
補充回答一下
針對後段的業務系統如果是CPU密集型的，支持超線程技術的4核可以開8到16個線程，具體看有沒有CPU空閑
如果是io密集型，換成非同步io非阻塞模式，線程數量可以開到50+，如果是java的，換成jvm自己管理線程可以開更高，如果是交由系統切換線程，linux下總進程+線程數量小於200可以忽略進程線程切換開銷
問題1、每臺機器所能支持的線程數需要根據具體的業務情況來進行實際測試，使用4核8G的伺服器做過測試，大約線程數1000時效果比較好，線程數達到1w時，伺服器出現無法響應的情況。具體的最優線程數，業務不同可能相差比較大，最好實際測試一下
問題2、每秒1000個訂單，單個機器假設開啟1000個線程，每個線程每次同步處理1個訂單的3個請求，處理完畢需要10秒，則單個機器所能處理的訂單速度為100/秒。
問題3、按照上面的邏輯，需要10臺機器
問題4、線程過多確實會導致性能降低，但100個線程並不多，具體取多少線程數可以採用加倍折半測試的方式。先啟動100線程，再啟動200個看性能是提升或下降。若200線程性能提升了，那下次測試400個線程的性能，若200線程時性能反而下降了，那下次測試150線程的性能。依次測試，直到獲取最優的線程數
我覺得問題應該是在於你的處理模式就有問題。對於這種操作，訂閱發布或者任務隊列模式可能會更適合一些。
你目前的設計完全沒考慮到一條http請求失敗怎麼辦，這麼高的請求你的請求服務端受不受的了。你的http請求越高頻，你的服務端越可能處理不了。
簡單一點就用redis來實現，這樣實現非同步處理會大量減少你伺服器的負荷。複雜一點像kafka這種。
先別管幾個核的CPU，就按單核CPU處理的情況來分析。
首先，平均處理一個訂單的平均時間週期（從請求到處理完，處理時延）是多少？要明確地表達出來。」每條記錄處理需要10秒鐘「，這是什麼意思？是一個訂單的整個處理時間週期，還是CPU處理時間？
其次，在一個訂單的平均處理時間週期（處理時延）由幾部分組成？假設是連續的不間斷的依次的逐條處理。把操作系統的單道批處理拿出來看看。再把資料庫的存儲引擎和數據表的優化部分拿出來推一下，看看I/O次數能優化多少。
我們就不說什麼請求到達率了。假設請求已經堆起來了，burst。
第三，線程的切換，你是指用戶程序還是指內核？如果是用戶程序，那麼開銷存在哪個地方？對於單核CPU來說，線程切換開銷怎麼評估。對於多核CPU來說，對於不同的操作系統來說，線程切換開銷和用戶程序又有所不同。
如果自己還搞不定，建議看論文，或者花錢。
你的系統瓶頸在http請求那裡處理一條花9秒，堆開多少核開多少線程都救不了你。
要不真試試9000個並發。。。。你確定http的服務端受得了？
需要多少個線程纔可以實現這個同時同步，計算並不困難，每秒1000，每條記錄需要處理10秒，1000*10=10000個線程。
同時10000個線程在執行即可以實現對應你每秒產的訂單數量
如何配置伺服器內存？
每個線程大概佔2M的大小，10000*2=20000M，你大概需要購買24-32G內存的伺服器
如何配置CPU？
這個實話實說，不好計算你得自己去摸索，根據內存的大小你應該選配24-32G的內存服力器，可以嘗試先選擇16U的伺服器，如果在本地壓力測試顯示CPU指數過高，再進行升級即可。
那麼開100個線程和開5個線程的執行效果是不是一樣，線程多了反而會造成頻繁切換線程問題，反而更慢，對不？
理論是這樣的，但是這個數量級幾乎可以忽略不計算，因操作系統本身就有幾百個線程進執行，一臺高性能WEB網站，假設是4U的每秒可以承受上千的並發是可以的，也就意味同時會有上千個線程。
線程過多的確會引起CPU的上下文切換，進行資源浪費，但是本身操作系統就是多道批的，是按時間分片進行線程切換的，也就是說CPU本身就是需要不斷的切換線程，過多的線程只是增多的CPU的輪詢的消耗。
並不需要提心性能的，因為即使16U，32G的內存也不過是1.8萬/年的費用，比不上一個高級碼農一個月的工資。推薦閱讀：
