沒做過支付，不考慮細節，隨便聊聊
1. 首先要解決掉數據庫的壓力，3萬qps對應的磁盤 iops 很大，不過現在好的 SSD 能提供很好的 iops, 比如這款： ARKIntel® SSD DC P3700 Series (800GB, 單盤 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
1. 首先要解決掉數據庫的壓力，3萬qps對應的磁盤 iops 很大，不過現在好的 SSD 能提供很好的 iops, 比如這款： ARKIntel® SSD DC P3700 Series (800GB, 單盤 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
施錦, 2015-01-16 22:10
假設你是搶購，只賣一種組合或單品，你就鎖定100w庫存。這個價格你已經算好了，然后生成100w訂單。把這些單號扔進mq，誰來支付，就消費一條消息，然后把這個訂單和用戶關聯。這個關聯操作，可以分庫分表來做。減輕庫壓力。
3萬？web不掛的話30w也行呀。mq要抗住，不能掛。熱點數據要分散開，檢查mq訂單隊列的長度，小於一個數量后，再生成新訂單。
-
如果你嫌用戶提交太密集的話，點了提交后，給用戶講個故事
張三有三個兒子，大明，二明和小明
問問他，小明的爸爸叫什么？
答對了ok，提交成功。答錯了？提示用戶你個笨蛋，當然叫張三了，然后用戶輸入張三，提交成功。
3萬？web不掛的話30w也行呀。mq要抗住，不能掛。熱點數據要分散開，檢查mq訂單隊列的長度，小於一個數量后，再生成新訂單。
-
如果你嫌用戶提交太密集的話，點了提交后，給用戶講個故事
張三有三個兒子，大明，二明和小明
問問他，小明的爸爸叫什么？
答對了ok，提交成功。答錯了？提示用戶你個笨蛋，當然叫張三了，然后用戶輸入張三，提交成功。
韓才峰, 2015-01-17 22:10
從交易角度來看，各種高並發系統可以粗略分為兩大類：交易驅動的系統，內容驅動的系統。其中：
交易驅動的系統：包括支付系統、電信計費系統、銀行核心交易系統等，此類系統強調數據庫事務的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、支付訂單是否涉及熱點賬戶問題，也即對同一賬戶會有多個並發請求對其屬性（例如賬戶余額）進行操作？
由此可以展開諸多優化策略，不在此處細述。
以前寫過一篇交易系統“熱點賬戶”處理 ，供參考
交易驅動的系統：包括支付系統、電信計費系統、銀行核心交易系統等，此類系統強調數據庫事務的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、支付訂單是否涉及熱點賬戶問題，也即對同一賬戶會有多個並發請求對其屬性（例如賬戶余額）進行操作？
由此可以展開諸多優化策略，不在此處細述。
以前寫過一篇交易系統“熱點賬戶”處理 ，供參考
張言啟, 2015-01-24 22:10
這么簡單的一句話，不要說清晰描述需求，連大致目標都講不清楚。
我不知道上頭那些長篇大論都是怎么推導出來的，還是簡單的copy/paste。
我不知道上頭那些長篇大論都是怎么推導出來的，還是簡單的copy/paste。
孔歡, 2015-07-06 22:10
我設計訂單的架構的時候，把下單～結算～支付～切分成三個系統，然后之間通過用mq做任務隊列，這樣的設計也算是最流行的方案，每個系統之類相互之間沒有耦合，同樣也可以用不同的實現，因為無論哪個部分成為性能瓶頸，我就加強哪一部分的處理能力，無論垂直的水平擴展都OK。同時因為有mq做緩沖，不會一下子就崩潰被沖死。
～～～～～
補充一下，數據庫的瓶頸是最大的，拿MySQL來說，同樣的機械硬盤，寫入性能的話，記不記錄操作日志相差會幾百寫入每秒到幾千每秒。。
同樣，互聯網是一個拼硬件的環境。。。我壓過pci-e接口的ssd卡。。。那個寫入速度快到我都想捏捏自己的臉。。。貌似16核cpu都跑滿了，iowait依然為0。。。。
～～～～～
補充一下，數據庫的瓶頸是最大的，拿MySQL來說，同樣的機械硬盤，寫入性能的話，記不記錄操作日志相差會幾百寫入每秒到幾千每秒。。
同樣，互聯網是一個拼硬件的環境。。。我壓過pci-e接口的ssd卡。。。那個寫入速度快到我都想捏捏自己的臉。。。貌似16核cpu都跑滿了，iowait依然為0。。。。
尤順, 2015-01-16 22:10
你的原題所描述的架構中，少了幾個最重要的手段：多域名、CDN、F5、NGINX、REDIS。
原題中，還少了幾個重要的內容。每秒3W個的支付請求，是電商訂單部分，還是自建賬戶系統支付部分，還是外聯各支付渠道支付？
3W的量，持續多久？最高幾分鍾？可以一直持續下去？
電商系統，是一個復雜的系統，3W每秒的訂單量，電商系統的壓力不僅僅會在訂單系統，整個系統的每個環節都會經受類似數據量級別的壓力，包括首頁、商品列表、商品詳情、用戶中心、歷史訂單等部分。
有必要使用多域名系統，將整個系統拆分為多個互相獨立的系統，再對每個子系統做單獨的優化工作。
3W的訂單，首先要考慮10倍，甚至更高的瀏覽量。那么前端頁面靜態化（包括圖片、css、js文件，甚至於整個前端頁面），緩存（業務數據），就必不可少。
如果涉及到秒殺，那就需要加入比較復雜的驗證碼功能。而驗證碼的生成，又必須要預先生成，靜態化，緩存等等。
后段部分，又分為兩大部分，交易系統和存儲系統。
單獨的TOMCAT可以做到100-500左右的並發量。這個數據量是基於http協議的情形。原題中提到了dubbo服務，是可以基於tcp協議進行子系統之間交互的, tcp協議可以達到1w以上的並發量。 但是往往實時交易系統的瓶頸並不存在於系統互聯,I/O連接、傳輸部分，而是在自身的業務部分。
實時交易部分的優化，技術部分的手段無非是：REDIS緩存、加載到內存。
但更重要的是做好業務模型的優化，包括預先、異步、先REDIS后DB等。改進業務模型，可以直接將業務系統的性能需求下降許多（如果可以改變12306的出票、退票策略，那基本不存在買不到票的情況：所有需要回家過春節的人基本都回家了，這是另外一個大的話題）。
3W每秒的系統，瓶頸更可能需要考慮數據存儲部分的需求。正因為前面的多域名、系統拆分，可以將各個系統的業務數據分開來存儲。單個子系統的數據，可以通過分庫/分表的方法，進行數據存儲。這里需要考慮關鍵字段的HASH策略，如何更好的滿足一些其他
需求（包括加表、表關聯）。
數據存儲部分，還有幾個可以做的事情：只讀庫、歷史庫、數據倉庫。
在這么一個復雜的系統里面，很多人都會忽略監控系統。
好的監控系統，可以幫你了解你系統的整個運行狀況（有次面試，有個技術總監問了個問題，現在線上系統掛了，有的人能打開網頁，大部分人都打不開，問：怎么定位問題。 我回答說：做好監控系統，監控系統可以直接回答這個問題，他說有這樣的系統。。。？？）。
一般的監控系統，能做到的無非這樣幾點：1）操作系統的cpu, memory，i/o 。 2）各個系統的log：訪問次數，warning, error log的條數。 3）dba對數據庫的監控。4）業務層面的監控：每分鍾各個子系統的交易量（DB查詢）。
但是多數監控系統沒有做的內容：單筆請求在交易系統中的流程，一筆實時交易，從接收到http請求，到各個子系統之間的互相訪問，到DB的讀寫。
這樣的監控的埋點包括：1）web 容器的filter 攔截器。 2)子系統互操作時的請求客戶端。 3）DB讀寫操作客戶端。通過這一套完整的客戶端重寫，去完成單筆交易業務的全流程的監控。 通過這樣的埋點，自然就可以解決前面提到的：某個系統忽然掛掉，怎么進行具體問題定位。
原題中，還少了幾個重要的內容。每秒3W個的支付請求，是電商訂單部分，還是自建賬戶系統支付部分，還是外聯各支付渠道支付？
3W的量，持續多久？最高幾分鍾？可以一直持續下去？
電商系統，是一個復雜的系統，3W每秒的訂單量，電商系統的壓力不僅僅會在訂單系統，整個系統的每個環節都會經受類似數據量級別的壓力，包括首頁、商品列表、商品詳情、用戶中心、歷史訂單等部分。
有必要使用多域名系統，將整個系統拆分為多個互相獨立的系統，再對每個子系統做單獨的優化工作。
3W的訂單，首先要考慮10倍，甚至更高的瀏覽量。那么前端頁面靜態化（包括圖片、css、js文件，甚至於整個前端頁面），緩存（業務數據），就必不可少。
如果涉及到秒殺，那就需要加入比較復雜的驗證碼功能。而驗證碼的生成，又必須要預先生成，靜態化，緩存等等。
后段部分，又分為兩大部分，交易系統和存儲系統。
單獨的TOMCAT可以做到100-500左右的並發量。這個數據量是基於http協議的情形。原題中提到了dubbo服務，是可以基於tcp協議進行子系統之間交互的, tcp協議可以達到1w以上的並發量。 但是往往實時交易系統的瓶頸並不存在於系統互聯,I/O連接、傳輸部分，而是在自身的業務部分。
實時交易部分的優化，技術部分的手段無非是：REDIS緩存、加載到內存。
但更重要的是做好業務模型的優化，包括預先、異步、先REDIS后DB等。改進業務模型，可以直接將業務系統的性能需求下降許多（如果可以改變12306的出票、退票策略，那基本不存在買不到票的情況：所有需要回家過春節的人基本都回家了，這是另外一個大的話題）。
3W每秒的系統，瓶頸更可能需要考慮數據存儲部分的需求。正因為前面的多域名、系統拆分，可以將各個系統的業務數據分開來存儲。單個子系統的數據，可以通過分庫/分表的方法，進行數據存儲。這里需要考慮關鍵字段的HASH策略，如何更好的滿足一些其他
需求（包括加表、表關聯）。
數據存儲部分，還有幾個可以做的事情：只讀庫、歷史庫、數據倉庫。
在這么一個復雜的系統里面，很多人都會忽略監控系統。
好的監控系統，可以幫你了解你系統的整個運行狀況（有次面試，有個技術總監問了個問題，現在線上系統掛了，有的人能打開網頁，大部分人都打不開，問：怎么定位問題。 我回答說：做好監控系統，監控系統可以直接回答這個問題，他說有這樣的系統。。。？？）。
一般的監控系統，能做到的無非這樣幾點：1）操作系統的cpu, memory，i/o 。 2）各個系統的log：訪問次數，warning, error log的條數。 3）dba對數據庫的監控。4）業務層面的監控：每分鍾各個子系統的交易量（DB查詢）。
但是多數監控系統沒有做的內容：單筆請求在交易系統中的流程，一筆實時交易，從接收到http請求，到各個子系統之間的互相訪問，到DB的讀寫。
這樣的監控的埋點包括：1）web 容器的filter 攔截器。 2)子系統互操作時的請求客戶端。 3）DB讀寫操作客戶端。通過這一套完整的客戶端重寫，去完成單筆交易業務的全流程的監控。 通過這樣的埋點，自然就可以解決前面提到的：某個系統忽然掛掉，怎么進行具體問題定位。
李元震, 2015-02-18 22:10
懂得不多，但想和題主討論下。
業務端接收訂單請求通過增加機器和升級硬件應該是可以解決的，上面幾位都說了這點。我也做過支付系統，按題主的意思就是交易系統的TPS得到3w級別，普通的交易系統是根本沒法做到這個級別的吧，因為一般的交易場景也沒必要啊，一般撐死幾百上千吧，又不是支付寶。
前面的請求調用什么的通過題主已有的那幾個方案也應該都沒問題，這個壓力主要是在數據庫這里，因為一般成熟一點的支付系統里面單個事務的sql應該是非常多的，賣家、買家等都可能涉及到鎖的問題，特別是記賬的時候，熱點商家必定耗時很長，單點的數據庫肯定達不到要求。這里主要有兩種方案，一個是分布式事務，另一個是使用消息隊列，達到最終一致性。分布式事務方案有很多，但是實現起來麻煩不小，主要是系統的可用性很難得到保證，mysql自己的XA都還有問題。可以嘗試最終一致性的方案，ebay和淘寶都沒有使用強一致性的方案，能異步的部分盡量異步，保證數據庫實時操作的sql最少，但是最后一定要用一致性的模塊來保證數據的正確，當然也要考慮業務方對時效性的容忍程度。
業務端接收訂單請求通過增加機器和升級硬件應該是可以解決的，上面幾位都說了這點。我也做過支付系統，按題主的意思就是交易系統的TPS得到3w級別，普通的交易系統是根本沒法做到這個級別的吧，因為一般的交易場景也沒必要啊，一般撐死幾百上千吧，又不是支付寶。
前面的請求調用什么的通過題主已有的那幾個方案也應該都沒問題，這個壓力主要是在數據庫這里，因為一般成熟一點的支付系統里面單個事務的sql應該是非常多的，賣家、買家等都可能涉及到鎖的問題，特別是記賬的時候，熱點商家必定耗時很長，單點的數據庫肯定達不到要求。這里主要有兩種方案，一個是分布式事務，另一個是使用消息隊列，達到最終一致性。分布式事務方案有很多，但是實現起來麻煩不小，主要是系統的可用性很難得到保證，mysql自己的XA都還有問題。可以嘗試最終一致性的方案，ebay和淘寶都沒有使用強一致性的方案，能異步的部分盡量異步，保證數據庫實時操作的sql最少，但是最后一定要用一致性的模塊來保證數據的正確，當然也要考慮業務方對時效性的容忍程度。
施敬伯, 2015-01-17 22:10
瓶頸多半是在數據庫。沒有預算壓力的話，數據庫可以上我大SAP HANA，主要數據直接在in memory，沒有IO瓶頸了oy。甚至業務邏輯也可以直接在數據庫中計算。緩存可能都不用自己搞了。
3萬qts我估計500GB RAM（你沒看錯，500GB內存不是硬盤）的中小型suite也就夠了。不過這個還得你自己判斷。
當然前台還是得自己想辦法，1樓已經有建議了。
3萬qts我估計500GB RAM（你沒看錯，500GB內存不是硬盤）的中小型suite也就夠了。不過這個還得你自己判斷。
當然前台還是得自己想辦法，1樓已經有建議了。
華紹, 2015-01-19 22:10
異步模型
施寧, 2015-02-17 22:10
程序和硬件，都有朋友做了論述。我公司支付清結算系統在解決高並發的時候，基本思路是盡可能不要增加太多的硬件負擔。
我們的解決思路是這樣：
1、單筆交易100毫秒肯定是要達到的速度
2、在極短時間內的超高並發，不一定需要每筆交易的數據流都獨立處理
3、我們的目標是讓C端的客戶感覺上沒有覺得慢，也就是客戶提交一個請求1-2秒得到回應是可以接受的。
那么，我們完全可以：
1、在1-2秒的時間內，先將交易數據進行歸集（比如多少筆歸集一次），因為是自己處理信息流，所以很快的
2、在數據歸集后，以批量處理的形式進入資金的處理程序，這塊需要有銀行及第三方支付的反應，相對受一些限制。
這樣實現了超高並發的處理，並且不會造成太大的硬件資源浪費。
PS：我公司系統曾經支持過小米的搶購，支持的還是比較完美的。
我們的解決思路是這樣：
1、單筆交易100毫秒肯定是要達到的速度
2、在極短時間內的超高並發，不一定需要每筆交易的數據流都獨立處理
3、我們的目標是讓C端的客戶感覺上沒有覺得慢，也就是客戶提交一個請求1-2秒得到回應是可以接受的。
那么，我們完全可以：
1、在1-2秒的時間內，先將交易數據進行歸集（比如多少筆歸集一次），因為是自己處理信息流，所以很快的
2、在數據歸集后，以批量處理的形式進入資金的處理程序，這塊需要有銀行及第三方支付的反應，相對受一些限制。
這樣實現了超高並發的處理，並且不會造成太大的硬件資源浪費。
PS：我公司系統曾經支持過小米的搶購，支持的還是比較完美的。
沈亞思, 2015-06-29 22:10
我倒是很好奇什么業務會有這么大的訂單量？12306和淘寶雙11？直接照抄他們的方案就行了。僅這個訂單系統就需要幾十人的研發/運維團隊。算是周邊功能，沒幾百人的隊伍搞不定。
吳莎香, 2015-01-17 22:10
可以試試lmax，LMAX架構 - Thinking In Jdon
華飛, 2015-01-16 22:10
內存數據庫除了hana還有Oracle TimesTen 和IBM solidDB為常見的選擇，數據庫這里可以分為兩部分，交易過程中用的，包括查詢和更新，放入內存數據庫中，自己計算下需要多少空間，公式可以參考，用戶數*字段數*字段大小*業務增長率*冗余系數，參照結果看下需要配多少內存，其他數據存入RDBMS中。
業務處理參數 sz lin的回答，把過程切分為若干個，過程使用多線程運行，線程中通過mq耦合。