现在有这样一个需求,在一秒中有3万的支付订单请求,有什么比较好的解决方案吗?

已邀请:

admin

赞同来自:

知乎网友:
作者:李道兵
链接:https://www.zhihu.com/question ... 32988
来源:知乎
著作权归作者所有,转载请联系作者获得授权。

没做过支付,不考虑细节,随便聊聊

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运行参数,等等,要做的事情还很多。

admin

赞同来自:

支付网友:
作者:梁川
链接:https://www.zhihu.com/question ... 25567
来源:知乎
著作权归作者所有,转载请联系作者获得授权。

从交易角度来看,各种高并发系统可以粗略分为两大类:交易驱动的系统,内容驱动的系统。其中:
交易驱动的系统:包括支付系统、电信计费系统、银行核心交易系统等,此类系统强调数据库事务的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、支付订单是否涉及热点账户问题,也即对同一账户会有多个并发请求对其属性(例如账户余额)进行操作?

admin

赞同来自:

知乎网友:

1.jpg

 

admin

赞同来自:

知乎网友:

作者:jeff
链接:https://www.zhihu.com/question ... 82901
来源:知乎
著作权归作者所有,转载请联系作者获得授权。

你的原题所描述的架构中,少了几个最重要的手段:多域名、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读写操作客户端。 通过这一套完整的客户端重写,去完成单笔交易业务的全流程的监控。 通过这样的埋点,自然就可以解决前面提到的:某个系统忽然挂掉,怎么进行具体问题定位。
 

admin

赞同来自:

知乎网友:

程序和硬件,都有朋友做了论述。我公司支付清结算系统在解决高并发的时候,基本思路是尽可能不要增加太多的硬件负担。
我们的解决思路是这样:
1、单笔交易100毫秒肯定是要达到的速度
2、在极短时间内的超高并发,不一定需要每笔交易的数据流都独立处理
3、我们的目标是让C端的客户感觉上没有觉得慢,也就是客户提交一个请求1-2秒得到回应是可以接受的。
那么,我们完全可以:
1、在1-2秒的时间内,先将交易数据进行归集(比如多少笔归集一次),因为是自己处理信息流,所以很快的
2、在数据归集后,以批量处理的形式进入资金的处理程序,这块需要有银行及第三方支付的反应,相对受一些限制。
这样实现了超高并发的处理,并且不会造成太大的硬件资源浪费。

作者:久中堂
链接:https://www.zhihu.com/question ... 81009
来源:知乎
著作权归作者所有,转载请联系作者获得授权。
 

要回复问题请先登录注册