作者：李道兵
鏈接：https://www.zhihu.com/question/27590048/answer/37432988
來源：知乎
著作權歸作者所有，轉載請聯系作者獲得授權。
鏈接：https://www.zhihu.com/question/27590048/answer/37432988
來源：知乎
著作權歸作者所有，轉載請聯系作者獲得授權。
1. 首先要解決掉數據庫的壓力，3萬qps對應的磁盤 iops 很大，不過現在好的 SSD 能提供很好的 iops, 比如這款：
ARK | Intel® SSD DC P3700 Series (800GB, 2.5in PCIe 3.0, 20nm, MLC) 單盤 90000 IOPS，應該能撐住你的數據庫，考慮到主備，以及你的sharding需求，3-9 台數據庫機器，高內存，高CPU，SSD磁盤應該能抗住
2. 業務邏輯這一層: Java 系，用線程來抗並發的，如果業務邏輯不太復雜，那么基本能做到 100ms 內響應，那么 30000qps, 對應的是 3000並發線程，這部分設計的時候記得保持無狀態，單台支撐 300-1000 並發沒問題，加上一倍的冗余，那么 6~20 台業務型機器可以抗住。
3. 緩存層: 支付訂單一般對緩存需求不高，但緩存層一般都會有，避免把查詢壓力壓到數據庫，簡單兩台緩存，或者緩存平行部署在業務型機器上都可以解決，具體看你的情況了。
4. 接入層: nginx 做LVS就可以了，記得 backlog 配大點就可以了, 3萬qps, 假設單個請求的數據在 10KB 左右，那么是 300MB/s，如果是千兆機，每台4網卡，兩內兩外，加上冗余，我會部署4台入口機，如果是萬兆機，兩台做主備（心跳或者LVS)即可。
當然，魔鬼在細節，做好機器的監控，慢請求的監控，日志的匯聚與分析。然后逐步推進服務的 SOA 化來降低復雜度。留一台業務機打小流量來做線上測試。優化JVM運行參數，等等，要做的事情還很多。
2. 業務邏輯這一層: Java 系，用線程來抗並發的，如果業務邏輯不太復雜，那么基本能做到 100ms 內響應，那么 30000qps, 對應的是 3000並發線程，這部分設計的時候記得保持無狀態，單台支撐 300-1000 並發沒問題，加上一倍的冗余，那么 6~20 台業務型機器可以抗住。
3. 緩存層: 支付訂單一般對緩存需求不高，但緩存層一般都會有，避免把查詢壓力壓到數據庫，簡單兩台緩存，或者緩存平行部署在業務型機器上都可以解決，具體看你的情況了。
4. 接入層: nginx 做LVS就可以了，記得 backlog 配大點就可以了, 3萬qps, 假設單個請求的數據在 10KB 左右，那么是 300MB/s，如果是千兆機，每台4網卡，兩內兩外，加上冗余，我會部署4台入口機，如果是萬兆機，兩台做主備（心跳或者LVS)即可。
當然，魔鬼在細節，做好機器的監控，慢請求的監控，日志的匯聚與分析。然后逐步推進服務的 SOA 化來降低復雜度。留一台業務機打小流量來做線上測試。優化JVM運行參數，等等，要做的事情還很多。