有密集型（高頻） https api 請求的需求，該用什麼技術棧？

舉個例子，如果業務需求是對一個(https)api介面，進行密集型請求，例如每秒請求一次，該用什麼技術棧比較好？（Twisted? Nodejs? Go?）

好多人，評論說我說的是笑話，好吧。怪我沒把問題描述清楚。

業務的需求是：1秒鐘同時向100萬（後期有可能千萬個）個api發起請求。

嗯？不知道這種請求，算不算密集請求！

我想想，可能用「高頻」這個詞語，更準確吧。

---

嚯，這厲害了，跳過C10K，C100K了，直接上C1M了，我滴媽，問題里的這種場景，我摳破頭皮，覺得可能是想一秒鐘抓100萬個網頁，而且100萬（以及未來可能1000萬）這個數明顯就是拍腦袋想出來的，沒什麼實際依據。真正有這個能力的架構師，都不會脫離實際場景做設計的。

---

我覺得你對密集一定有什麼誤會……

所以現在還不是選擇什麼技術棧的時候，先招個有相關經驗的程序員比較好。

=================================================

根據你補充的說明，我們有充分的理由相信你掌握了一個龐大的殭屍網路，並且在籌劃一場大型的DDoS攻擊。否則你如何在單機發起100W的並發的？這至少需要數千台分布在各地的機器，如此龐大的殭屍網路同時發起請求，除了DDoS之外沒有什麼很好的解釋……

你不妨先摸一下你的錢包掐一下大腿，問問令尊大人家業幾何，再作此宏圖偉業，別出師未捷先被網警抓去。

---

每秒請求100w個不同的介面，你確定你的需求是正常的？確定不是系統的設計本身不合理？

如果這100w個介面在同一個伺服器上，你知道兩個單機（一個伺服器埠）之間同時最多只能建立65536個TCP連接嗎？而且這些連接不可能在1秒內全部建立完成。

如果是多機，你確定們公司有100w台伺服器？

最後，如果真是這樣，那麼我建議你別用線程模型，幾萬個線程不說佔CPU，怎麼也得占很多內存吧。

題主真的不是來釣魚的？

---

一秒鐘向一百萬個api發出請求，關鍵在於response.在你這裡，同步的表示你要維護一百萬個處理線程，不現實，一般做非同步處理。其實你們別笑樓主，他的技術術語不過關，如果我用古典術語就很容易解決這個問題：

廣播+MQ

---

我覺得題主的需求 應該沒有 100萬/S 級別，這只是一個虛指……

就像我們面試時經常會遇到：

有一個 100萬行的txt文本 ……呃 100萬太少，改成 100億行 好了……

——————————————————————————

目測看，題主要求的，是一個爬蟲？？？

對外發送 http請求？

一台機器不行就兩台，兩台不行就四台……

就這樣了……

和技術棧關係不大……

如果目標API可以支持回調模式，那就更好了……速度會更快一點兒

發送請求端，發出請求後不管……

然後等著API回調 接收端 就好了……

——————————————————————

---

歪個樓。

我在想100w不同api介面是要找多少人才能寫出來？

---

如果是作為server，被其它客戶端client調用，那很簡單，100w/s的調用還算不上密集，伺服器集群簡單介面每秒上億的調用次數實現都很輕鬆。

如果是作為客戶端，那很多回答都提到了，單機最多只能開6萬多個連接，因為系統埠上限只有65535個，系統本身服務還有些預留和佔用。每開一個外部網路連接，就需要佔用一個埠，和是否多線程無關。要超過這個限制，需要一個分散式的集群。

每秒並發去調用外部100萬個介面。。。我見過最豪邁的爬蟲系統也沒這麼高。這是奔著底層開始就設計一個百度 google之類的搜索引擎用巨型分散式爬蟲系統去的，只能感嘆，現在年輕人起點就是高。。。

---

同時發起大量請求,屬於網路IO密集操作.

一般這種場景需要用到非同步HTTP/HTTPS客戶端.

以PHP非同步引擎Swoole為例,代碼如下:

&setHeaders(array(
Host =&> "{$host}:{$port}",
User-Agent =&> Firefox/48.0,
Accept =&> text/html,application/xhtml+xml,application/xml,
Accept-Encoding =&> gzip,
));
$cli-&>get($path, function ($cli) {
$html = $cli-&>body;
$doc = new DOMDocument();
@$doc-&>loadHTML($html);
$nodes = $doc-&>getElementsByTagName(title);
echo $nodes-&>item(0)-&>nodeValue . "
";
});
});
}
// 得到
非同步毫秒定時器-Swoole-Swoole文檔中心
非同步Http2.0客戶端-Swoole-Swoole文檔中心
非同步Http/WebSocket客戶端-Swoole-Swoole文檔中心


Swoole非同步的澎湃動力,實在太強大了.

PHP內置的HTML解析器,也非常方便.

我有PHP,鼓瑟吹笙.契闊談宴,心念舊恩.

---

具體發送請求的技術棧用什麼都行。

重點是，每秒達到1M這個數量級的對外請求，絕對不是一台主機能搞定的，先別說發起請求消耗的資源了，光是連接數就超了上限。

所以你真正需要的是中等以上規模服務集群的調度、監控、負載均衡、彈性伸縮……這些技術才是真正有意義的，比起選擇最前端發起請求的語言重要多了。

--------吐槽分割線--------

看了一下題主更新的日誌，原來最早說的是每秒一次這種「密集」請求啊，被嘲諷了之後直接改為每秒一百萬個請求，還是不同API。

你真的清楚一百萬是什麼數量級么？這滿嘴跑火車的毛病還是改改吧，簡直跟小學生吹牛一樣：

——「我這包零食可貴了！五塊錢呢！」

——「哈哈哈五塊錢算什麼貴」

——「這個不貴怎麼了？我叔叔上次給我帶的進口零食，五十萬億一包呢！」

---

告訴你一個可能的做法。

首先，將100w請求壓縮打包，然後發起一個http request將打包的數據發給服務端，服務端解包後處理請求，將請求結果整理壓縮打包返回給客戶端。

這個流程可以有很多優化點......

---

這個問題太歡樂了，摺疊我吧

---

現在100萬，未來一千萬，取個均值500萬/秒

那一年下來：

5 000 000 * 86400 * 365 = 157,680,000,000,000

次請求

假如每個請求耗費1KB 流量

那至少需要帶寬

5 000 000 * 1024 * 8 / 1000^3 = 41 Gbps

如果每個請求要10KB流量，那就至少410 Gbps帶寬

假如題主要存一年的數據

157,680,000,000,000 / 1024^4 = 144 PB

再幫題主算下成本

41G帶寬，算點冗餘，突發什麼的，算你50G

一年大約1000萬費用

144 PB，節省一點，就弄個雙副本，硬碟利用率75%，全部買8T硬碟

144 * 2 * 1024 / 8 / 0.75 = 50000塊硬碟

每塊3000塊錢，大約是1.5個億

恭喜題主，你創造了一家獨角獸公司。IPO指日可待。

---

作為客戶端一秒要請求1M次，兩台單機間理論最大也就是65535個鏈接。

方便計算你的一個客戶機開5W個請求吧，20台機器大概可以滿足題主的要求。

但是考慮到題主未來是要干大事的人 建議把tcp協議改了頭部改了，把埠位元組長度改成20個位元組，這樣子兩台單機間就可以進行2**20 大概是100W的鏈接了。

建議題主把設計tcp的那個人請過來讓他給你搞。免得被人坑。。。100W也不多 是吧。

---

能不能透露下你這是啥業務，讓我開開眼界

我實在想不到啥場景需要一秒鐘發一百萬個請求，後面還要上千萬

---

你可能對技術有什麼誤解。

舉個例子，可能不太貼切。你想吃麵條，一開始的時候你說一秒就吃一根，你問別人怎麼吃。別人說你這都不會不理你了。

你很傷心，然後你想那就高端一點唄，怎麼在一秒鐘之內吃百萬甚至千萬根麵條。

怎麼辦，我們也很絕望啊。只有等進化了，電腦用四五十年的時間完成了到現在的進化。你要多等等，等幾年或者十幾年應該就可以了。

---

推薦閱讀：