Q:現在有這樣一個需求，在一秒中有3萬的支付訂單請求，有什麼比較好的解決方案嗎？ PS:我們資料庫用的是oracle 程式是java spring mybatis dubbo mq等技術，現在有這樣一個場景 高併發寫 在一秒中有3萬的支付訂單請求有什麼比較好的解決方案嗎？ 主要優化哪方面 A1: 作 ...
Q:現在有這樣一個需求，在一秒中有3萬的支付訂單請求，有什麼比較好的解決方案嗎？
PS:我們資料庫用的是oracle 程式是java spring mybatis dubbo mq等技術，現在有這樣一個場景 高併發寫 在一秒中有3萬的支付訂單請求有什麼比較好的解決方案嗎？ 主要優化哪方面
A1:
作者：李道兵
沒做過支付，不考慮細節，隨便聊聊
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運行參數，等等，要做的事情還很多。
Good Luck A2: 作者：梁川
從交易角度來看，各種高併發系統可以粗略分為兩大類：交易驅動的系統，內容驅動的系統。其中：
交易驅動的系統：包括支付系統、電信計費系統、銀行核心交易系統等，此類系統強調資料庫事務的ACID原則。
內容驅動的系統：包括SNS、微博、門戶、視頻、搜索引擎等系統，此類系統對資料庫事務ACID的關註不是第一位的，更強調CAP原則：Consistency（一致性）， Availability（可用性），Partition tolerance（分區容錯性）。
與此對應，交易驅動的系統與內容驅動的系統在系統優化方法最大的差異在於：
交易驅動的系統：強調事務的ACID，按照CAP原則做選擇，更強調CA（Consistency（一致性）和Availability（可用性）；因此交易驅動的系統一般在核心交易上選擇關係型資料庫（包括採用記憶體資料庫、緩存等涉及事務問題），當然這就導致交易系統最大的瓶頸一般都在關係資料庫上。
內容驅動的系統：可以在CAP之間根據業務需要做選擇三選二，因此一般選擇NOSQL為主、RDBMS為輔的方案。
在優化策略上，內容驅動的系統採用的諸多優化手段交易驅動的系統也可以採用，上面各位回答都有所提及，這裡重點說一下因事務導致的業務複雜性的處理。
3萬筆/每秒這個級別的交易訂單這個量級說實話挺大，但即便如此，也有諸多可優化的空間。由於題主未對具體場景說明，只能假定是典型的交易驅動系統，一些思考點：
1、3萬筆/每秒是峰值最大交易量還是持續交易量？
2、3萬筆/每秒是同一類型的訂單還是諸多種類型的訂單？
3、業務能否做拆分，例如從功能、從區域、從優先順序等角度？
4、支付訂單是實時交易還是非實時交易，能否延時入庫？
5、支付訂單能否延時批量處理？
6、支付訂單是否涉及熱點賬戶問題，也即對同一賬戶會有多個併發請求對其屬性（例如賬戶餘額）進行操作？
由此可以展開諸多優化策略，不在此處細述。
