併發是指一秒數據庫收到的4K數據個數。需要什麼樣的硬件和帶寬才能穩定達到1秒1000以上？
觀點1
首先，服務器硬件條件要達到要求。網卡帶寬是否夠；是否有寫磁盤，若有，讀寫速度是否超過磁盤IO帶寬；是否有耗時計算，CPU是否會稱為瓶頸。 其次，硬件都滿足的情況下。你需要使你的軟件系統充分利用硬件性能。這個時候就需要合理設計方案，實現。 然後，再你達到了預定的併發量後。再想想能否優化，在更少的資源下完成同樣的事情，或者現有資源下完成更多的事情。最後，還有一個重中之重就是，是否易運維，易擴展。這個是很值得你投入精力去做的。
觀點2
首先1秒1000併發並不高，題主沒說幾個關鍵點：數據量多大，單臺機器還是分佈式。
如果是分佈式有架構的話應該也不會問這種問題。如果是單臺機器沒有架構 直接裸奔的話最簡單做法就是分表分庫分機器加緩存。
另外不要用雲主機，目前的雲主機io性能都不好，還是直接自己弄服務器靠譜
如果數據量小的話就全部加載到內存中。重點是要知道性能瓶頸在哪。
觀點3
一般的提法是1000併發，指同時在線數，即1000個客戶和服務器保持著連接。可能一整天都能保持這個狀態，因此不帶上具體多久。
從題主前後文看，題主其實想指的是qps，即每秒的請求數。
如果每秒1K個請求，每個請求都是寫入操作，數據大小是4K，那麼這是典型的數據庫應用。每秒需要寫入的數據量是1K*4K=4M。單機下普通配置的mongodb可以應付這樣的壓力。可否找一下那些地方成為瓶頸了。看看磁盤忙不忙，mongo的CPU高不高。
觀點4
如果只是讀請求就簡單多了，MongoDB RS架構完全夠用。我們目前的業務場景，業務用MongoDB只讀，每分鐘幾百萬的請求完全跟服務器數量是線形增長的。
至於寫的話，假設你們很有錢，就買SSD吧，簡單粗暴。
通用的做法是：緩存+數據庫(redis+mongodb)，自己實現緩存中的任務隊列並用某個固定服務flush/merge這些隊列。這個隊列就複雜到業務邏輯了，緩存是永遠避免不了的。
此外，可以從業務邏輯方面考慮優化。（是的，我又一次提到了業務邏輯）或許你們可以將業務分離，解藕數據之間的關聯。
我們學到的一個教訓是分離數據庫，提高單臺服務器的處理能力。