問答專欄Q & A COLUMN
1、這個題目問得不那么準確，你必須要精準計算出每秒查詢時間（QPS）和事務時間（TPS），好比你感冒了，你說要配什么藥，醫生只能憑經驗，你如果去抽象化驗，知道是病毒還是細菌感染，數量是多少后，才能進一步診斷和配置服務器硬件。
2、接下來，你要了解常用發中間件和數據庫的極限并發量。比如redis一般是11w左右（純粹內存讀寫）、mysql每秒寫8w左右，讀10來萬（單表，多表就不一定，得看SQL的寫法），一般單表的存儲極限是5千萬左右，如果超出范圍，那么配置再好也是慢。總的說來，要精確配置服務器，你需要盡可能地評估最復雜的業務每秒并發時間，同時要考慮最復雜的情況，比如數據庫的數據規模、代碼在最高并發下，所耗費的時間，同時對網絡I/O也要有一個預估，知道帶寬的大小，總之，需要具體問題具體分析。
3、如果以上情況不考慮，就是想知道一個簡單粗暴的大概結果，一般8核、16G、256SSD，同時跑DB和web服務器的話，足夠支持1w的并發量，而且還有很大的冗余。如果火力全開，滿血跑，大概跑個8-10w都是有可能的。邊壓測，邊優化，如果恰好旁邊有高手，榨干每一個環節，你的并發量超出你的想象……
評論0
加載中...
場景很重要，比如一萬并發的qps還是tps，這完全不同的概念。
服務器做做優化，現在通過epoll支撐百萬連接十萬并發沒什么瓶頸。但是，這只是網絡層，如果落到具體業務，那就另當別論了。比如redis可以幾十萬并發，因為只需要網絡io和訪問內存。但是如果有業務處理，掛上了數據庫，走了kafka，并且再走redis，那就要具體問題具體分析了。
數據庫單存qps，我們原來基準測試結果是可以支撐六萬到八萬左右，但是有事務的增刪改絕對不是這個量級。
其實你需要的是一個基準測試的結果，例如tcp，http基準測試；tomcat基準測試；應用框架基準測試；redis基準測試；mysql基準測試等。
我們做過應用框架基準測試，基于springboot，測試接口沒什么邏輯，就是直接查詢sql并返回結果。基準測試結果是八核16G內存，跑兩個實例，可以撐到8萬并發左右，應該還有優化空間吧。
評論0
加載中...
首先你要知道, 1w并發是什么. 1w就是QPS, 1w請求/秒. 所以不是只是和系統配置(容量)相關, 如果要達到, 反而更應該和時間相關.
舉個例子, 假設平均你的服務處理時間(RT)是1秒, 那么在這一秒鐘內, 意味著有1w個線程同時執行. 而實際即使是8核單機, 也是壓不上去的.
為什么? 因為你的服務太慢了, RT太長了. 那么把你的服務處理時間優化縮減到0.1秒, 即100ms, 那么達到1w并發(QPS=1w/秒), 同時只需1k個線程在并發執行就達到了.
以個人經驗.對于Java來說, 1K大小的線程池不是什么大問題. 為了避免占GC時間過長, 配置500左右大小的線程池, 啟動2個JVM實例就可以達到.
而以1秒RT為基礎的1w線程池大小, 以個人經驗, 在單機基本上壓不到的.
所以, 答案就是, 你應該先關注RT, 縮小到平均100ms的經驗值, 1w并發不是問題.
評論0
加載中...
可以了解一下serverless。函數計算就是其中的代表實現了免運維，自動伸縮。也就是說你只用專注業務 無需管理服務器配置管理 不管多大并發 都能抗住，無需擔心服務器宕機，等一系列運維問題。你只需在適當的時候升級數據庫即可。在解決業務問題之前沒必要解決技術問題。之前也和你一樣，開發之前總是擔心服務器性能不夠怎么辦，雖然大部分情況下用戶可能沒有那么多，并發根本沒有想象中的大。但是等到一些列問題出現的時候再去找解決方案，就會很被動，不管是對公司還是個人造成很大壓力。所以建議了解serverless 函數計算完美解決了這一問題。最后安利一下ucloud云的函數計算，技術成熟，支持語言多，遷移項目方便。
評論0
加載中...
您好，光網絡可能就不支持1w的并發了。
你說的這個配置是基礎配置，一來就是1w的高并發支持不了的。
由于各個功能模塊各個層次消耗不一樣，所以要具體看后期運營使用情況再來調整服務器配置。
評論0
加載中...
要看性能要求了，如果只討論并發數量，用異步網絡模型，并發一萬個鏈接沒啥問題吧，只是數據處理不過來，大多數鏈接都是在等待結果而已。服務器配置1核8g差不多夠了吧
評論0
加載中...
1m帶寬，1萬qps基本沒可能，就算平均包長128字節好了，撐死1000pps，假設一次交互完成，那頂了天500tps。那你這環境只可能是1萬活躍session了，應該隨便搞臺pc機都能頂住
評論0
加載中...0
回答0
回答5
回答5
回答9
回答0
回答10
回答0
回答0
回答0
回答
