創建一個應用伺服器，請大神提下建議？真實需求

01-08

1 每個項目10000感測器左右長連接到伺服器預計每秒1k位元組內容（可能更快或者更多位元組）如果說感測器的種類嘛，先假設100種吧／數據總存貯量先假設2年吧（這個需求可以降低見下文問題3）
2 大概預期100個項目總數量級因此是100萬的感測器計劃長鏈接，這100萬個設備肯定是
一個項目一個項目的加入連接到伺服器（這個需求可以降低見下文問題3）
3 計劃構建雲伺服器主要功能包括資料庫的保存（計劃mysql），客戶端（暫時決定是app ，所以不是做web伺服器）查詢數據和顯示圖表，簡單控制部分感測器
4 其他功能包括可能對數據進行大數據分析，可能將來加入攝像頭等價的感測器

本人對win平台 c++技術較為熟悉，打算在 asio ／ libuv／libenvent／libeV 等庫中選擇一個，資料庫計劃用mysql , 做一個 socket 通信的伺服器
所以想請問各位專家們
1 那請問忽略我個人技術領域，拿什麼技術或者語言或者架構實現最方便呢？這條最重要啦
2 我是計劃長連接，如果是短鏈接，是不是更費伺服器資源？只有選擇長的方案了吧？請問是不是還有其他方案可選？
3 我原來以為這種簡單業務邏輯的項目是小項目，聽了幾位專家的建議，我想是不是可以先把數量級別先降低到10萬甚至5W 數據發送量也可以進行降低，在這種情況下向各位請教解決方案，謝謝！！！！
本人在伺服器開發上還是個新人，所以問的比較菜，感謝各位大大們百忙中抽出時間解答，我願意學習一切新知識，但是人力精神有限，希望能找到一條相對簡單的解決方案的路徑

補充：感謝各位大拿們的回答，百萬設備和採集頻率是BOSS的願望，中期內不會有那麼多量，
所以就如我3中所說，降低數量級後，請教大家上面的三個問題，謝謝
我會認真考慮大家提議的每個點，謝謝！！！

根據題主的描述補充幾句。

如果你打算從小做起，那現在就不要糾結單機用什麼庫能支持多少並發連接這種事，你需要的是找到一個方便水平擴展的方案，比如讓感測器在本地把數據匯總一下再批量上傳，服務端再匯聚一下扔進HDFS，這樣接下來的數據分析就會比較方便，整個方案也有比較高的水平擴展能力，可以從一個單機服務做起。

但這種方案要求：

1、沒有實時性需求，要不然就不能批量上傳了。

2、對於數據完整性和順序之類的沒有強要求，批量上傳就意味著數據的順序可能會錯亂而且會丟。

3、設備端需要一定的處理和存儲能力，也就是說那些幾毛幾塊的單片機就不能用了，至少得用幾十幾百的ARM板。考慮到你要支持上百萬的設備，這可能是個大問題。

-------------------------以下是原答案-----------------------

看起來這像是一個IoT的項目，按照你的簡單描述，目前需要注意的地方大概有這麼幾個：

1、MySQL的負載能力，在一個中等雲主機上，對於一個沒有索引的表，撐死也就幾千tps，如果你加了索引會更低。

2、1M並髮長連接，按中等雲主機的估算，如果你的業務邏輯比較簡單，大概需要幾百個instance，還需要保留足夠的固定帶寬。如果業務邏輯複雜那就沒邊了……

3、你提到了攝像頭，那就是說未來有可能會在網路上實時傳遞視頻，這可是個IO大戶，帶寬存儲都是錢，還都不便宜，而且還可能涉及到視頻處理等CPU大戶。

簡單說，以你現在設定的scope，沒有哪家雲是合適的，即使一開始客戶少的時候上雲，你也會很快遇到需要自建機房的瓶頸，要麼設計好混合雲方案，要麼忍痛做一個大遷移。

如果你一定要上雲，你需要估算幾個數字，一開始可以簡單設定為qps、bandwidth、storage這幾個指標，也許還涉及到latency，隨著業務細化你還需要建立更詳細的指標，有了這些指標你就可以大概估算一下雲上的成本，同時對比一下自建機房的成本。

PS. 實話說這種項目我嚴重不建議你用C++，開發周期明顯比用其它方案長太多，尤其是你熟悉的只是Windows平台。

PPS. 如果這是個沒人投資沒有團隊的個人項目，我建議你棄坑吧，搞不出來的。

就拿一個項目來算，10000個長連接，每個連接每秒1k數據？

如果走公網，估計要100Mbit帶寬，這每個月是多少錢？

就算是內網，帶寬不要錢，一秒鐘存10MB數據，一天是864GB，兩年是631TB，你的數據可壓縮性如何？存這些數據要多少錢？保守估計小几十萬吧？

100個項目就是上面的數字乘以100？單是存儲就有上千萬的成本，我覺得你可以花點錢請個好的顧問了。

你有沒有測試過一台Windows伺服器能支持多少並髮長連接？

上次遇到一個有個絕妙app創意的

問我他這項目技術上有無風險

當我說出最大的風險不在技術在產品同質化

他說絕無同類產品

並問我在技術設計上如何避免大流量帶來的帶寬費用。。。如何降低數據中心的成本。。。

搞得毫無聊天興趣了

媽蛋，你的用戶在哪？

先別想這麼多，趕緊做出來一個10並發的demo搞到投資人的錢吧。沒錢的話，伺服器硬體你沒有，公網帶寬你沒有，充足的開發人力你沒有，布置感測器網路的苦力你請不起。

如果是研究生導師要求的任務的話，建議你趕緊混完文憑走人。

不請自來，手機答覆，簡單寫寫。

我正在做的項目跟這類似。全球領先的家電行業，目標是千萬級的設備，除了採集，還有即時通訊。雖然也在摸索階段，但是經驗可以分享給你。

寫寫我的經驗：

1.c++開發太慢，我現在用go。你這種io密集型採用nodejs也不錯

2.boost名頭響，用起來就不是那麼回事，都是非同步io，性能卻遠遠比不上nodejs和go。枉費c++的性能優點。如果要選cpp，建議用libevent，linux平台

3.拋棄windows

4.性能可先不考慮，先考慮擴展性。

5.如果是10萬左右的並發，在io不多的情況下，單台伺服器都能承擔（主流pc的配置）；如果io較多，可能io會成為瓶頸，這就需要採用分散式存儲，系統會比較大

6.先做好數據存儲採集的成本核算。根據能承受的經濟能力，合理制定業務目標。我們遇到要採用1g帶寬才能滿足的需求，被我罵回去了

7.感測器最好能做一部分數據預處理，這些分散式的計算單元雖然性能低，但是人多力量大。

8.數據存儲別想用mysql了，大數據時代，mysql可以用來存比較少的結構化數據，絕對不會是放你這種數據的。存進去了你也用不了。可以用hadoop

9.如果只是數據採集，對數據沒有實時要求，可以感測器預處理再集中上傳，採用短鏈接。

如果有實時要求，只能長鏈接了。長鏈接要注意空閑心跳問題。

暫時想到這麼多，有問題再補充

年輕人，

攬活兒之前，

先掂量下自己的手藝。

海量離散實時數據的場景，早就有標準解決方案：工業實時資料庫

但是，要達到你那個處理百萬點、秒級的實時數據的要求，實時資料庫只是解決方案的一部分。

這裡面有太多的坑、需要太多的經驗。不是選golang或者cpp或者libev或者算帶寬這麼表面的問題。

@陳碩大神幫你算了帶寬和伺服器成本，順帶說了一下操作系統的選擇

@徐辰提了一下資料庫瓶頸和cpp開發的周期問題

我也從業務邏輯問題和技術選型方面說兩句吧。

1.我覺得第一時間考慮性能未必就是好事。能從業務邏輯方便降低數據和通信量的話，應該是首要的。

（1）數據上傳能否進行預處理？

對於實時監控的感測器來說，一秒1KBytes的數量倒不算很大。當然了，原始的數據能有很多好處，包括後期的數據分析等很多方面。另外，採樣的頻率越高，對後期的分析也是越有好處。

但是我覺得你需要先考量一下是否有這個必要。如果能夠先做預處理，估計可以把數據量壓縮不少。

（2）另外，順帶提一句，採樣頻率應該可以動態設置。

前期可以採用低頻率看看是否能滿足需要。如果後期實在有需要提高採樣頻率了，那也可以遠程提高採樣頻率。這樣子在開發和迭代周期可以給你帶來足夠緩衝時間，等到數據量很大的時候，我相信你的伺服器性能必然也是優化了很多。

2.數據是否需要實時上報。

（1）數據的實時上報一般針對一些對實時性要求很高的監控項目。如果你只是簡單的採集一些數據，用作一些後期的分析。那我建議你可以把數據上報頻率降低一點。

（2）我所見過的數據的實時上報一般是一些工業設備監控會用得比較多，而且人家也不使用公網。如果你是一些類似於普通設備運行監控、wifi探針、溫度濕度監控、路由器監控、廣告屏監控之類的，我覺得數據上傳頻率可以低一點。

（3）順帶一句，因為你的設備走的是公網，大規模部署的時候，網路問題應該是必然會出現的。但是如果如果對數據完整性要求也有要求的話，估計也是需要把數據緩存在本地，等到網路恢復的時候再把緩存的數據上報上去。

3.數據上報和控制可以考慮分開處理，還可以分別採用不同的協議和通信格式。

（1）控制不單單是控制設備的一些運行參數，同時也可以包括控制設備的採樣頻率、數據上報頻率、數據通信格式等等。

（2）說白了就是通信協議的設計，我覺得在你考慮架構的時候，通信協議是很關鍵的一步。擴展性強的協議可以避免後期很多的改動。畢竟物聯網設備的固件更新、軟體更新、數據上報格式更新等等n多問題，都是靠通信協議來提前規範好。

（3）另外，我覺得你可以了解一下protobuf和thrift。

4.至於服務端的技術選型，要考慮操作系統和網路庫。

（1）windows server我不熟，不敢隨便評價。但是我覺得選linux也不是很大難度。畢竟一個項目一萬個感測器，開發、測試、運維不可能你一個人做完吧？就算是你一個人做了，找個linux的人幫忙搭個伺服器也是可以的吧？反正linux上面搭個java環境，杠杠的。

（2）你熟悉cpp的話，選擇 libuv／libenvent的庫也是挺好的，我之前做這類項目的話，偷懶選了個Netty。有個朋友用了golang來做過類似的項目，我不熟也就不發表評價了。畢竟不是每個人都能寫個muduo出來碾壓碾壓。

（3）之前也用過http上報一些網路設備的數據，也算是偷懶吧，不過開發進度杠杠的。

5.另外，如果真有需要，後端的伺服器和資料庫也是可以切分和均衡的。幹嘛把所有設備都連到同一個設備上呢？

當然了，太早的優化、過度的架構設計，都是不可取的。一切取決於你的實際情況。如果1w個設備部署要一年多，和1w個設備要很短時間部署完，那麼適用的方案可能不一樣了。前者可以慢慢優化，後者可能要提前就設計好。一個項目最多1w個設備和一個項目可能最多10w個設備，也是會有不同的選擇。

總結一下吧：

（1）考慮清楚項目的實際情況，包括不僅限於項目的規模、未來的增長趨勢、技術團隊的規模和實力等等。在滿足這些要求的前提下，能簡單就盡量簡單吧。能開源就不要自己寫，能用雲服務就不要自己搭建，能選快速開發方案就選快速開發方案，能參考別人就先參考一下別人，能滿足最近半年的需要就先滿足最近半年需要（說不定哪一天項目就爛尾了呢）。

（2）通信協議是關鍵。動態的、可擴展的、高效的、成熟穩定的通信協議或者通信框架，會大大地減少需求變更、日後運維、項目迭代帶來的工作量。（個人經驗，僅供參考）

孩紙，高並發伺服器不是那麼容易的！我以前做過wifi智能插座的app！我沒來公司前已經有2-3個外包公司主動退款！最後一個有個公司居然用Python給我們寫高並發伺服器，那個伺服器速度慢不說，還非常不穩定！伺服器不行，app做好了，嵌入式設備做好了都沒用！（沒有鄙視Python的意思，我覺得最好的方案應該是用java/c++，並且是非阻塞的非同步io）！最後我老闆燒了幾百萬，這個項目流產了！

為啥像推送這類高並髮長連接的服務，在中國可以賺大錢，你就懂了！

祝你好運！嘿嘿

這種東西應該是和利時通用西門子羅克韋爾橫河這樣的企業做的吧？

這種場景一定需要長連接嗎？

問題還是描述不清楚

如果數據僅僅是上傳存儲的話，一台伺服器1w並發和10w並發是沒太大區別的，在巨大的帶寬成本下，可以不同的感測器在不同的伺服器上註冊啊，數據保存到不同的資料庫裡面，那麼答案：問題1 無所謂，問題2 無所謂，問題3 小項目

如果數據實時，時序，完整性都有要求，那就是大項目

答案：問題1 哪個熟悉用哪個，問題2 哪個熟悉用哪個，問題3 大項目

每秒1K, 採樣頻率這麼高，難道是WAMS ，不過怎麼沒有數據查詢需求，那才是難點吧？

資料庫可能得用時間序列資料庫，壓縮比做的好的話可以到達30倍以上。不需要考慮這麼多連接，反正這麼高的寫入量同步歸檔數據是不可能的，可靠的持久化還需要數據接入系統保障。

資料庫和介面機都要做大規模集群：

資料庫負載可以考慮根據不同來源導到不同資料庫實例。

一個介面機對應若干個項目，介面機上運行數據接入程序，起到數據預壓縮、寫入的緩衝和錯誤處理作用。

一萬個感測器為什麼前端聚合一下？100萬長鏈接萬吃死內存了。起碼20g內存，cpu和帶寬自己估吧，看計算量和通信量。用你說的幾個非同步事件框架貌似都沒mysql的實現，用官方的mysql c client是個同步操作，要麼自己實現一個非同步client要麼做好線程同步吧。

通信推薦http吧，比你用裸socket方便擴展，將來出api手冊也簡單，需要加密時可以升https。