1秒1000並發 高並發需要什麼樣的伺服器？
01-13
1，目前是用的MongoDB資料庫，用了四台天互的豪華雲主機才勉強達到一秒八九百並發。
2，並發是指一秒資料庫收到的4K數據個數。需要什麼樣的硬體和帶寬才能穩定達到1秒1000以上
分享下我最近的經驗，希望對你有用。
我這邊一分鐘產生40萬條數據，大概是400MB，期間要有其它程序處理這些數據。最初採用了Redis和MySQL，因為有讀有寫，發現寫庫根本來不及。最後採用的方式是：先緩存數據在內存，將每10萬條數據進行序列化，寫文件（7200轉的硬碟，每秒寫100MB），另外一程序解析文件，處理數據（處理完數據沒那麼多了），之後存庫。
以上，希望對你有所幫助。首先，伺服器硬體條件要達到要求。網卡帶寬是否夠；是否有寫磁碟，若有，讀寫速度是否超過磁碟IO帶寬；是否有耗時計算，CPU是否會稱為瓶頸。
其次，硬體都滿足的情況下。你需要使你的軟體系統充分利用硬體性能。這個時候就需要合理設計方案，實現。
然後，再你達到了預定的並發量後。再想想能否優化，在更少的資源下完成同樣的事情，或者現有資源下完成更多的事情。
最後，還有一個重中之重就是，是否易運維，易擴展。這個是很值得你投入精力去做的。
首先1秒1000並發並不高，題主沒說幾個關鍵點：數據量多大，單台機器還是分散式。
如果是分散式有架構的話應該也不會問這種問題。
如果是單台機器沒有架構 直接裸奔的話最簡單做法就是分表分庫分機器加緩存。另外不要用雲主機，目前的雲主機io性能都不好，還是直接自己弄伺服器靠譜如果數據量小的話就全部載入到內存中。重點是要知道性能瓶頸在哪。如果數據要立即處理的話：（並發數*單個連接的平均傳輸的數據大小=關口帶寬）+(減少IO頻率+低延時+緩存並發情況下的數據=做個緩存)+高性能伺服器
一般的提法是1000並發，指同時在線數，即1000個客戶和伺服器保持著連接。可能一整天都能保持這個狀態，因此不帶上具體多久。
從題主前後文看，題主其實想指的是qps，即每秒的請求數。
如果每秒1K個請求，每個請求都是寫入操作，數據大小是4K，那麼這是典型的資料庫應用。每秒需要寫入的數據量是1K*4K=4M。單機下普通配置的mongodb可以應付這樣的壓力。可否找一下那些地方成為瓶頸了。看看磁碟忙不忙，mongo的CPU高不高。
如果只是讀請求就簡單多了，MongoDB RS架構完全夠用。我們目前的業務場景，業務用MongoDB只讀，每分鐘幾百萬的請求完全跟伺服器數量是線形增長的。至於寫的話，假設你們很有錢，就買SSD吧，簡單粗暴。通用的做法是：緩存+資料庫(redis+mongodb)，自己實現緩存中的任務隊列並用某個固定服務flush/merge這些隊列。這個隊列就複雜到業務邏輯了，緩存是永遠避免不了的。此外，可以從業務邏輯方面考慮優化。（是的，我又一次提到了業務邏輯）或許你們可以將業務分離，解藕數據之間的關聯。
我們學到的一個教訓是分離資料庫，提高單台伺服器的處理能力。
.看上去你們的瓶頸在資料庫。mongdb我不太了解，但是四台機器才能勉強達到九百ops太低了。
同為文檔資料庫，我們正在做的產品的目標是支持2000op/s/core.
建議你先熟悉下mongdb的配置。比如你們的replication是非同步的還是同步的，一致性是不是配置過高，有沒有充分利用內存。滿足1000並發，每個文件緩存30KB，帶寬大概37.5Mb。至於伺服器主流dellr420和dell720各一台，一台web一台資料庫，具體配置就不說了。
建立合理的索引吧。
第一名的回答比較靠譜。雖然我也不懂，但我也來插兩句：1、資料庫操作本身不快，不像只是http訪問。所以1秒4K資料庫訪問還是挺可怕的。2、緩存應該是比較好的解決辦法。所以改進程序吧，不要去想資料庫啦。
這個與架構有關係，目前我所用過的框架基本是採用事件輪詢解決接入的數量，至於說處理，要看你的業務邏輯，C10k說的應該也是接入.
推薦閱讀：