没做过支付，不考虑细节，随便聊聊
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耦合。