面对每秒3万支付订单请求的高并发场景，解决方案包括数据库层面选择高性能SSD，保证至少3-9台高配置数据库服务器；业务层通过Java线程抗并发，设计无状态服务，预计需要6-20台业务机器；缓存层可选配或集成在业务机器上缓解数据库压力；接入层使用nginx或LVS，确保足够的网络带宽和backlog配置。监控和日志分析至关重要，同时考虑服务SOA化和JVM参数优化。
Q:现在有这样一个需求，在一秒中有3万的支付订单请求，有什么比较好的解决方案吗？
PS:我们数据库用的是oracle 进程是java spring mybatis dubbo mq等技术，现在有这样一个场景 高并发写 在一秒中有3万的支付订单请求有什么比较好的解决方案吗？ 主要优化哪方面
A1:
作者：李道兵
没做过支付，不考虑细节，随便聊聊首先要解决掉数据库的压力，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磁盘应该能抗住
业务逻辑这一层: Java 系，用线程来抗并发的，如果业务逻辑不太复杂，那么基本能做到 100ms 内响应，那么 30000qps, 对应的是 3000并发线程，这部分设计的时候记得保持无状态，单台支撑 300-1000 并发没问题，加上一倍的冗余，那么 6~20 台业务型机器可以抗住。
缓存层: 支付订单一般对缓存需求不高，但缓存层一般都会有，避免把查询压力压到数据库，简单两台缓存，或者缓存并行部署在业务型机器上都可以解决，具体看你的情况了。
接入层: nginx 做LVS就可以了，记得 backlog 配大点就可以了, 3万qps, 假设
最低0.47元/天 解锁文章
983
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
