Q:现在有这样一个需求，在一秒中有3万的支付订单请求，有什么比较好的解决方案吗？PS:我们数据库用的是oracle 程序是java spring mybatis dubbo mq等技术，现在有这样一个场景 高并发写 在一秒中有3万的支付订单请求有什么比较好的解决方案吗？ 主要优化 ...
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 系，用
get='_blank'>线程来抗并发的，如果业务逻辑不太复杂，那么基本能做到 100ms 内响应，那么 30000qps, 对应的是 3000并发线程，这部分设计的时候记得保持无状态，单台支撑 300-1000 并发没问题，加上一倍的冗余，那么 6~20 台业务型机器可以抗住。3. 缓存层: 支付订单一般对缓存需求不高，但缓存层一般都会有，避免把查询压力压到数据库，简单两台缓存，或者缓存平行部署在业务型机器上都可以解决，具体看你的情况了。4. 接入层:
nginx 做LVS就可以了，记得 backlog 配大点就可以了, 3万qps, 假设单个请求的数据在 10KB 左右，那么是 300MB/s，如果是千兆机，每台4网卡，两内两外，加上冗余，我会部署4台入口机，如果是万兆机，两台做主备（心跳或者LVS)即可。当然，魔鬼在细节，做好机器的监控，慢请求的监控，日志的汇聚与分析。然后逐步推进服务的 SOA 化来降低复杂度。留一台业务机打小流量来做线上测试。优化JVM运行参数，等等，要做的事情还很多。Good Luck从交易角度来看，各种高并发系统可以粗略分为两大类：交易驱动的系统，内容驱动的系统。其中：与此对应，交易驱动的系统与内容驱动的系统在系统优化方法最大的差异在于：在优化策略上，内容驱动的系统采用的诸多优化手段交易驱动的系统也可以采用，上面各位回答都有所提及，这里重点说一下因事务导致的业务复杂性的处理。
海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com
原标题：1秒30000QPS，前后端设计思路
关键词：
*特别声明：以上内容来自于网络收集，著作权属原作者所有，如有侵权，请联系我们：
admin#shaoqun.com
（#换成@）。
