併發是指一秒資料庫收到的4k資料個數。需要什麼樣的硬體和頻寬才能穩定達到1秒1000以上？
首先，伺服器硬體條件要達到要求。網絡卡頻寬是否夠；是否有寫磁碟，若有，讀寫速度是否超過磁碟io頻寬；是否有耗時計算，cpu是否會稱為瓶頸。 其次，硬體都滿足的情況下。你需要使你的軟體系統充分利用硬體效能。這個時候就需要合理設計方案，實現。 然後，再你達到了預定的併發量後。再想想能否優化，在更少的資源下完成同樣的事情，或者現有資源下完成更多的事情。最後，還有乙個重中之重就是，是否易運維，易擴充套件。這個是很值得你投入精力去做的。
首先1秒1000併發並不高，題主沒說幾個關鍵點：資料量多大，單台機器還是分布式。
如果是分布式有架構的話應該也不會問這種問題。如果是單台機器沒有架構 直接裸奔的話最簡單做法就是分表分庫分機器加快取。
另外不要用雲主機，目前的雲主機io效能都不好，還是直接自己弄伺服器靠譜
如果資料量小的話就全部載入到記憶體中。重點是要知道效能瓶頸在哪。
從題主前後文看，題主其實想指的是qps，即每秒的請求數。
如果每秒1k個請求，每個請求都是寫入操作，資料大小是4k，那麼這是典型的資料庫應用。每秒需要寫入的資料量是1k*4k=4m。單機下普通配置的mongodb可以應付這樣的壓力。可否找一下那些地方成為瓶頸了。看看磁碟忙不忙，mongo的cpu高不高。
如果只是讀請求就簡單多了，mongodb rs架構完全夠用。我們目前的業務場景，業務用mongodb唯讀，每分鐘幾百萬的請求完全跟伺服器數量是線形增長的。
至於寫的話，假設你們很有錢，就買ssd吧，簡單粗暴。
通用的做法是：快取+資料庫(redis+mongodb)，自己實現快取中的任務佇列並用某個固定服務flush/merge這些佇列。這個佇列就複雜到業務邏輯了，快取是永遠避免不了的。
此外，可以從業務邏輯方面考慮優化。（是的，我又一次提到了業務邏輯）或許你們可以將業務分離，解藕資料之間的關聯。
我們學到的乙個教訓是分離資料庫，提高單台伺服器的處理能力。
在MongoDB中實現樂觀併發控制
說起來，自從接觸了mongodb以後，我在大小專案中就再也沒有接觸過關係型資料庫了。效能倒不是什麼主要問題，主要是方便，例如我可以在mongodb中直接儲存陣列，然後把其中的元素當作查詢條件，而在關係型資料庫中，則需要使用額外的 然後再join等等。當然，在mongodb中很難進行join，於是對於...
為什麼需要鎖（併發控制）？
在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。典型的衝突有 l 丟失更新 乙個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如 使用者a把值從6改為2，使用者b把值從2改為6，則使用者a丟失了他的更新。l 髒讀 當乙個事務讀取其它完成...
瞎想 如果需要更高併發
問 假想乙個場景。gps打點，很頻繁。打點之後會立即上傳到後端。後端需要立即展示給前端。兩個系統ab。乙個系統a，專門負責存入redis集群。乙個系統b，專門負責隔一段時間讀取redis集群，然後轉存入mysql持久。20s間隔，或者，容忍丟失的更多間隔。b系統只是為了持久而持久。a系統負責 展示 ...